idnits 2.17.1 draft-peterson-modern-teri-02.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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 31, 2016) is 2733 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: 'Syntax TBD' is mentioned on line 508, but not defined == Missing Reference: 'TBD' is mentioned on line 914, but not defined == Unused Reference: 'RFC3324' is defined on line 944, but no explicit reference was found in the text == Unused Reference: 'RFC3325' is defined on line 948, but no explicit reference was found in the text == Unused Reference: 'RFC4474' is defined on line 967, but no explicit reference was found in the text == Unused Reference: 'RFC4916' is defined on line 978, but no explicit reference was found in the text == Unused Reference: 'RFC5039' is defined on line 982, but no explicit reference was found in the text == Unused Reference: 'RFC5727' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'RFC6698' is defined on line 1017, but no explicit reference was found in the text == Unused Reference: 'RFC6950' is defined on line 1022, but no explicit reference was found in the text == Unused Reference: 'RFC7340' is defined on line 1031, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-modern-problem-framework-01 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 0 errors (**), 0 flaws (~~), 14 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 October 31, 2016 5 Expires: May 4, 2017 7 An Architecture and Information Model for Telephone-Related Information 8 (TeRI) 9 draft-peterson-modern-teri-02 11 Abstract 13 As telephone services migrate to the Internet, Internet applications 14 require tools to access and manage information about telephone 15 numbers. This document specifies a protocol-independent framework 16 and information model for managing service and administration data 17 related to telephone numbers. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 4, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Overview of Operations . . . . . . . . . . . . . . . . . . . 5 68 3.1. Relationship to the MODERN Framework . . . . . . . . . . 6 69 4. The Information Model . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Record Elements . . . . . . . . . . . . . . . . . . . . . 8 71 4.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 8 72 4.1.2. Authority . . . . . . . . . . . . . . . . . . . . . . 8 73 4.1.3. Contact . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1.4. Subject . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1.5. Service . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.1.6. Signature . . . . . . . . . . . . . . . . . . . . . . 9 77 4.2. Element Value Types . . . . . . . . . . . . . . . . . . . 9 78 4.2.1. Service Types . . . . . . . . . . . . . . . . . . . . 9 79 4.2.2. Public Key Type . . . . . . . . . . . . . . . . . . . 10 80 4.2.3. Contact Type . . . . . . . . . . . . . . . . . . . . 11 81 4.2.4. Expiry Type . . . . . . . . . . . . . . . . . . . . . 11 82 4.2.5. Priority Type . . . . . . . . . . . . . . . . . . . . 11 83 4.2.6. Record Identifier Type . . . . . . . . . . . . . . . 11 84 4.2.7. Signature . . . . . . . . . . . . . . . . . . . . . . 11 85 4.2.8. Extension Type . . . . . . . . . . . . . . . . . . . 11 86 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 5.1. Common to All Operations . . . . . . . . . . . . . . . . 12 88 5.1.1. Requests . . . . . . . . . . . . . . . . . . . . . . 12 89 5.1.2. Responses . . . . . . . . . . . . . . . . . . . . . . 13 90 5.2. The Acquisition Operation . . . . . . . . . . . . . . . . 14 91 5.3. The Management Operation . . . . . . . . . . . . . . . . 14 92 5.4. The Retrieval Operation . . . . . . . . . . . . . . . . . 15 93 5.5. Common Attributes . . . . . . . . . . . . . . . . . . . . 15 94 5.5.1. Administrative Attributes . . . . . . . . . . . . . . 15 95 5.5.2. Service Attributes . . . . . . . . . . . . . . . . . 15 97 6. Implementing Operations . . . . . . . . . . . . . . . . . . . 16 98 6.1. Transport Independence . . . . . . . . . . . . . . . . . 16 99 6.2. Bindings . . . . . . . . . . . . . . . . . . . . . . . . 17 100 6.3. Encodings . . . . . . . . . . . . . . . . . . . . . . . . 18 101 6.4. Profiles . . . . . . . . . . . . . . . . . . . . . . . . 19 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 104 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 105 10. Informative References . . . . . . . . . . . . . . . . . . . 20 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 108 1. Terminology 110 In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 111 and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 112 This document also incorporates the terminology of the MODERN 113 Framework [I-D.ietf-modern-problem-framework]. 115 2. Motivation 117 Telephone numbers remain the worldwide standard identifier for 118 routing calls and text messages over the Public Switched Telephone 119 Network (PSTN). Increasingly, real-time communications is migrating 120 to the Internet, and bringing telephone numbers with it. As 121 identifiers, however, telephone numbers differ fundamentally from 122 those commonly used by Internet applications. Email, the web and 123 native Voice over IP (VoIP) systems such as SIP ([RFC3261]) use 124 identifiers that rely on the Domain Name System (DNS) to resolve a 125 domain portion of the identifier to a particular IP address; 126 commonly, Uniform Resource Indicators (URIs) with a user and host 127 component serve this purpose. To help telephone numbers work 128 similarly on the Internet, a number of efforts have specified 129 mechanisms to manage and retrieve information about telephone numbers 130 via network services. SIP, for example, quickly developed a 131 convention for using a TEL URI in the user part of its URIs. 133 The ENUM ([RFC6116]) effort originally specified a public DNS profile 134 for translating telephone numbers into URIs. Due to the difficulty 135 of coordinating the public administration of telephone numbers in the 136 DNS, this work transitioned to "infrastructure" ENUM ([RFC5067]), 137 which assumed private DNS implementations, each of which could give a 138 different answer to the same request to translate a telephone number 139 depending on who asked, or other internal factors. The framework of 140 the SPEERMINT working group ([RFC6406]), expanding on these 141 requirements, differentiated the mapping of a telephone number to a 142 target network (the "Look-up Function") from the mapping made by the 143 originating network to the proper next-hop to reach such a target 144 network (the "Location Routing Function"). To provision the data 145 associated with telephone numbers, the DRINKS working group 146 ([RFC6461]) designed systems for uploading back-end data to the 147 services that would answer ENUM queries. 149 None of the preceding efforts, however, encompassed the entire 150 lifecycle of a telephone number as an Internet identifier. They 151 focused largely on service data, on how to "resolve" a telephone 152 number to a location on the Internet, rather than on administrative 153 questions of how numbers are acquired, how the entities associated 154 with telephone numbers are authorized to provision data, and what 155 kinds of systems need to be in place to allow a diverse community of 156 devices, applications and users to rely on telephone numbers. Early 157 considerations were moreover based on overlapping, but not entirely 158 consistent, information models: intrinsic limitations in the DNS kept 159 the queries and responses of ENUM relatively simple, whereas the 160 DRINKS provisioning system considered a much richer syntax. 162 The need for solutions in this space is pressing, as many carriers 163 worldwide contemplate migrating their entire PSTN infrastructure onto 164 the Internet within the next decade. Further pressures come from 165 emerging Internet communications providers who never invested in PSTN 166 infrastructure in the first place, but want access to services 167 related to telephone numbers. This includes devices, services, and 168 applications on the Internet that make use of telephone numbers and 169 need to distribute and manage numbering inventory: for example, an 170 Internet-enabled PBX that might want to automate the process for 171 allowing new connected phones to acquire numbers and provision 172 contact information for their users. Ultimately, the resources 173 identified by telephone numbers must also be reachable on the 174 Internet, and different applications might want to use different 175 protocols to retrieve information about numbers. In some 176 environments, there are performance constraints that would require a 177 very lightweight binary protocol; in others, applications might 178 prefer human-readable markup languages suitable for interfacing with 179 existing APIs. The use cases associated with these functions are 180 detailed in [I-D.ietf-modern-problem-framework]. 182 Therefore, this document proposes a reconsideration of telephone 183 service and administration data on the Internet, based on an 184 information model that allows records associated with telephone 185 number to be created, modified and accessed through network 186 interfaces. This document specifies no particular syntax or encoding 187 for queries or responses, but instead describes an extensible 188 information model for the semantics of provisioning and querying 189 operations associated with a telephone number. 191 3. Overview of Operations 193 In TeRI, Clients use Operations to acquire, manage, or retrieve 194 Records, which are typically stored at Services. Every Operation 195 consists of a Request and a Response. Requests may pass directly 196 from a Client to a Service, or they may pass through one or more 197 Request Intermediaries; Request Intermediaries can modify Requests 198 and Responses in transit. A Response will contain a Response Code 199 indicating the status of the requested Operation. Both Requests and 200 Responses can, in certain Operations, carry Records. TeRI does not 201 specify any specific data format or underlying protocol to 202 instantiate Requests, Responses, or Records: TeRI is an abstract 203 architecture that must be implemented with concrete bindings and 204 encodings (see Section 6). 206 The TeRI information model (see Section 4) specifies the baseline 207 contents of Records, though Records are designed to be extended by 208 future specifications for particular use cases or environments. 209 Records provide information related to telephone numbers; a Record 210 may apply to one telephone number, a block of numbers, or several 211 discrete blocks of numbers. There may be multiple Records stored at 212 a Service which cover a single telephone number: this may include 213 multiple Records that apply only to that one telephone number, which 214 probably have been provisioned by different Authorities, as well as 215 Records applying to a telephone number range which contains that one 216 telephone number. Authorities sign Records, and Clients typically 217 have a trust relationship with those Authorities. 219 The three TeRI Operations are as follows: 221 The Acquisition Operation enables a Client to request the 222 allocation of unallocated telephone numbers that are held by a 223 Service on behalf of an Authority. A Service makes an 224 authorization decision before allocating the telephone number(s) 225 in accordance with the policy of the Authority. One or more new 226 Records may be created as a result of a successful Acquisition 227 Operation, and the Service will pass any such Record(s) to the 228 acquiring Client as well as retaining them locally at the Service. 229 As a result of a successful Acquisition Operation, the 230 administrative entity operating the Client will typically become a 231 new Authority for the allocated telephone numbers. 233 The Management Operation enables a Client to push new values for a 234 Record to a Service. In the baseline Operation described in this 235 document, the Client pushes the entire value of the Record to the 236 Service. The Service then makes an authorization decision to 237 determine whether or not the Client is permitted to upload the 238 Record in question. The policy behind those authorization 239 decisions is outside the scope of this document, though at a high- 240 level, the Client must be an Authority for a telephone number in 241 order to publish and modify Records associated with that number. 242 However, outside of hierarchical Authorities, Clients will not be 243 able to modify or delete Records related to that number that have 244 been provisioned by other Authorities. 246 The Retrieval Operation enables a Client to request one or more 247 Records that are stored at a Service. Some Records may contain 248 public information, and some may contain information that requires 249 an authorization decision to be made before it is shared with a 250 Client. Note that Services may have trust relationships with 251 Request Intermediaries, and that the Response may depend on that 252 trust relationship rather than on the Service's trust relationship 253 with the Client. Although a Client acquires Records from a 254 Service, a Client need not have a trust relationship with it - 255 typically, the Client trusts the Record because it trusts the 256 Authority which signed the Record rather than the Service that 257 holds or delivers the Record. 259 All entities that act as TeRI Services will offer at least the 260 Management and Retrieval interfaces, and some will also offer the 261 Acquisition interface. All entities that act as TeRI Clients will 262 implement at least the Retrieval Operation; others may implement the 263 client side of one or both of the Management and Acquisition 264 Interfaces. 266 3.1. Relationship to the MODERN Framework 268 The MODERN Framework [I-D.ietf-modern-problem-framework] enumerates a 269 series of actors and use cases related to telephone number 270 administration on the Internet. In terms of actors, it details 271 interactions between Users, Communications Service Providers (CSPs), 272 Registries, Registrars, and Government Entities. These actors 273 implement the interfaces and Operations of TeRI Clients or Services 274 in support of various use cases. Typically, Users, CSPs, and 275 Government Entities act as TeRI Clients, and CSPs, Registries, and 276 Registrars act as TeRI Services. 278 In the MODERN framework, the lifecycle of a number begins with a 279 Registry. Registrars acquire telephone numbers from Registries, and 280 make those numbers available for allocation. Thus, an Acquisition 281 Operation is used by a Registrar that acquires numbers from a 282 Registry, and this Request, if successful, will result in the 283 creation of a Record that is returned in the Response. That Record 284 renders the Registrar an Authority for the telephone numbers in 285 question, but that Record will contain exclusively Administrative 286 Data, with no Service Data. 288 In some cases, that Registrar will also fulfil the role of a CSP, and 289 as a CSP, it will allocate those numbers to Users and generate any 290 associated Records itself. Alternatively, a Registrar that does not 291 act as a CSP may in turn act as a TeRI Service to which CSPs, and 292 potentially Users, will send Acquisition Requests to acquire number 293 blocks or individual numbers. Through that process, CSPs and Users 294 can also become Authorities for telephone numbers. New Records 295 containing Administrative Data indicating the contact information and 296 so forth of the CSP or the User will be generated when that 297 allocation occurs; those Records will be stored at the Registrar. 298 The Registrar may also house a "glue" Record of Service Data that 299 indicates the servicing CSP for the telephone number, and in 300 particular the Retrieval interface of that CSP where Records with 301 further Service Data can be found. 303 The Authorities who create and propagate Records of Service Data are 304 typically CSPs and Users. Most commonly, CSPs will store these 305 Service Data Records, and make them accessible through a Retrieval 306 interface. CSPs may also propagate these Records to various external 307 directories; the signature of the CSP and expiry data in the Record 308 will prove its integrity and freshness to any relying party. It is 309 envisioned that multiple Authorities may create Records for different 310 services that are associated with a given telephone number. 312 Finally, CSPs and Users may query a Retrieval interface at a CSP to 313 acquire Records containing Service Data that will enable them to 314 route communications. The Retrieval interface will enable Clients to 315 ask for Records associated with particular services, though Retrieval 316 can present Clients with a number of service options. Entities may 317 also query the Retrieval Interface of Registrars to acquire 318 Administrative Data about a telephone number, though it is likely 319 that authorization policies will restrict access to that data. 320 Government Entities may have legal relationships with Registrars that 321 grant them authorization privileges with regard to Administrative 322 Data. 324 4. The Information Model 326 The fundamental building block of the TeRI model is the Record. A 327 Record is created by an Authority who has authority over a particular 328 telephone number or a set of numbers. There may be more than one 329 Authority who is authorized to create Records for a particular 330 telephone number, and a TeRI service may have multiple Records 331 corresponding to a single telephone number, including potentially 332 Records associated with a range of numbers that encompasses a 333 particular telephone number. Under various circumstances detailed in 334 Section 5, participants in the numbering ecosystem may create, read, 335 update, and modify Records. 337 Records contain Elements that hold data about the telephone number. 338 Elements in this information model have a Name, which may optionally 339 be associated with a Type and Value. Elements are grouped into 340 Service Elements and Administrative Elements. 342 4.1. Record Elements 344 A Record is made up of Elements, which may be either Service Data 345 Elements or Administrative Data Elements. 347 4.1.1. Identifier 349 Every Record has an Identifier, which is a globally unique identifier 350 of the Record. The Identifier will typically be created at the same 351 time as the Record itself, at a time when an assignment or delegation 352 has occurred (as described in [I-D.ietf-modern-problem-framework]). 354 4.1.2. Authority 356 Every Record contains an Authority element the source of the data: 357 either the entity that provisioned the data with the Service, or the 358 external source from which the Service collected the data. The 359 Authority element ideally gives a logical identity of the source of 360 the data. A public key value may also be designated by the Authority 361 element. 363 4.1.3. Contact 365 Every Record has at least one Contact. The Contact contains 366 administrative data about the assignee of the telephone number, 367 though additional Contacts may contain information about delegates 368 (as defined in [I-D.ietf-modern-problem-framework]). 370 4.1.4. Subject 372 Every Record has a Subject. As TeRI Records concern telephone 373 numbers, the Subject of a Record is either a telephone number type or 374 a telephone number range type. 376 4.1.5. Service 378 Records optionally have one or more Service entries. A Service may 379 be of any Service Type, as given in Section 4.2.1. 381 4.1.5.1. Priority 383 Optionally, a Service may specify a weighted Priority associated with 384 a Record. Priorities are between 0 and 1, with a value of 1 having 385 the highest priority. 387 4.1.5.2. Expiration 389 Optionally, a Service may specify an absolute time at which a Record 390 will no longer be valid, should a client or intermediary wish to 391 cache a Record. In the absence of an Expiration element, Records may 392 be cached for a maximum of twenty-four hours. 394 4.1.6. Signature 396 Optionally, a Record contains a Signature element. The Signature 397 element contains a signature over the concatenation of the other 398 elements given the Record. Signatures are provided by the Authority 399 responsible for the Record. 401 [Syntax TBD] 403 4.2. Element Value Types 405 The remainder of a Record is made up of Elements. Elements types are 406 specified in this section. Every Element Type has a Type Code. A 407 Type Code is used as a short form for the Element in a Record. 409 4.2.1. Service Types 411 4.2.1.1. Telephone Number Type 413 The telephone number type conforms to the telephone number syntax 414 given in [RFC3966] Section 3, in the ABNF for "telephone-subscriber." 416 Type Code: T 418 [TBD - need for subtying? E.164, Service Code, Short Code, Prefix, 419 Nationally-Specific and Unknown. ] 421 4.2.1.1.1. TN Range Type 423 The TN range type consists of a prefix of a telephone number (per 424 [RFC3966] "telephone-subscriber"), and is semantically equivalent to 425 all syntactically-valid telephone numbers below that prefix. For 426 example, in the North American Numbering plan, the prefix 157143454 427 would be equivalent to all numbers ranging from 15714345400 to 428 15714345499. 430 [TBD - identify alternative ways of specifying ranges, potentially as 431 separate element types] 433 Type Code: R 435 4.2.1.2. Domain Name Type 437 The domain name type conforms to the syntax of RFC1034 Section 3.5 438 and Section 2.1 of [RFC1123]. 440 Type Code: D 442 4.2.1.3. Uniform Resource Indicator (URI) Type 444 The Uniform Resource Indicator (URI) type conforms to the syntax for 445 URIs given in [RFC3986] (see Section 3). 447 Type Code: U 449 4.2.1.4. Internet Protocol (IP) Address Type 451 The IP Address type conforms to the ABNF syntax of either the 452 IPv4address given in RFC3986 (Appendix A) or the IPv6reference of 453 [RFC5954]. 455 Type Code: I 457 4.2.1.5. Trunk Group Type 459 The trunk group type conforms to the "trunk-group-label" ABNF given 460 in [RFC4904] (Section 5). 462 Type Code: G 464 4.2.1.6. Service Provider Identifier (SPID) Type 466 The SPID type consists of a four-digit number. 468 [TBD - introduce other elements for alternative SPID syntaxes] 470 Type Code: ? 472 4.2.2. Public Key Type 474 The Credential type consists of a public key [encoding TBD]. 476 Type Code: C 478 4.2.3. Contact Type 480 The contact type follows the conventions of jCard [RFC7095]. 482 Type Code: C 484 4.2.4. Expiry Type 486 The Expiry type is an absolute time conformant to the syntax of 487 [RFC3339]. 489 Type Code: E 491 4.2.5. Priority Type 493 The Priority type contains a number between 0 and 1, conforming to 494 the specification of the "q" parameter of the Contact header field in 495 [RFC3261]. 497 Type Code: P 499 4.2.6. Record Identifier Type 501 The Record Identifier Type consists of a unique identifier for a 502 record [format TBD]. 504 Type Code: U 506 4.2.7. Signature 508 [Syntax TBD] 510 Type Code: S 512 4.2.8. Extension Type 514 This code is reserved for future use. 516 Type Code: X 518 5. Operations 520 In this section are detailed the three TeRI Operations: Acquisition, 521 Management, and Retrieval Operations. 523 5.1. Common to All Operations 525 All Operations in the TeRI model consist of Requests and Responses. 526 A Request from a TeRI Client to a Service may attempt to create, 527 read, update, or delete TeRI Records. Requests may focus only on 528 particular parts of a TeRI record. A Response gives the result of 529 the Operation back to the Client, which may indicate success of 530 failure. 532 5.1.1. Requests 534 All TeRI Requests have a Source, a Subject, and optionally a set of 535 Attributes which further specify the nature of the Request. Some 536 Requests will contain the Identifier of the Record they concern, and 537 may convey that in an Attribute; others will query for all Records 538 matching a given Subject. 540 5.1.1.1. Source 542 The Source is a required element in all Requests. In this 543 specification, two categories of Sources are defined: Request Source 544 and Request Intermediary. At least one of these Sources must be 545 present in a Retrieval Request, and multiple Sources are permitted. 546 Responses do not contain a Source. 548 Future specifications may extend the set of Source types. 550 5.1.1.1.1. Request Source 552 Every Request generated by a Client has a Request Source, which 553 identifies the originator of the Request. This represents the 554 logical identity of the user or service provider who first sent the 555 Request, rather than the identity of any Intermediate entity. This 556 field is provided in the Source to authenticate the poser of the 557 Request, so that the Service can make any necessary authorization 558 decisions as it formulates a Response. 560 In some service deployments, an Intermediary may wish to mask the 561 Request's Source from a Service. The removal of the Request's Source 562 by an Intermediary is permitted by TeRI, but any Intermediary that 563 removes the Request Source must provide a Request Intermediary for 564 the Source element. 566 A Request Source element has a Type, which indicates how the logical 567 identity of the originator of the Request has been represented. The 568 Type field of the Request Source is extensible. Initial values 569 include a domain name, a URI and a telephone number. 571 The Type element of the Request Source is followed by a Value, which 572 contains the identity. The format of the identity is determined by 573 the Type. 575 5.1.1.1.2. Request Intermediary 577 Optionally, Requests may contain one or more Request Intermediary 578 elements in the Source. A Request Intermediary resides between the 579 originator of the Request (the Client) and the Service, where it may 580 aggregate queries, proxy them, transcode them, or provide any related 581 relay function to assist the delivery of Requests to the Service. 583 The Request Intermediary element, like the Request Source, contains 584 the logical identity of the service that relayed the Request. This 585 field is provided in the Source for those deployments in which the 586 Service makes an authorization decision based on the identity of the 587 Intermediary rather than a Request Source. 589 A Request Intermediary element has a Type, which indicates how the 590 logical identity of the Intermediary has been represented. The Type 591 element of the Request Intermediary is extensible. Initial values 592 include a domain name, an X.509 certificate subject, or a URI. 594 The Type of the Request Intermediary element is followed by a Value, 595 which contains the identity. The format of the identity is 596 determined by the Type. 598 5.1.1.2. Subject 600 All Requests have a Subject. The Subject identifies the resource 601 that the Request concerns. Responses only contain a Subject if the 602 Subject of the Response differs from that of the original Request, 603 which may occur when (for example) the Subject contains a broad 604 range, and the Service replies with a more narrow Subject. Future 605 specifications, including Profiles, may define alternative Subject 606 elements. 608 5.1.1.2.1. Attributes 610 TeRI Attributes consist of a Name with an optional Type and an 611 Optional Value. Most Attributes are specific to the Operation. 613 5.1.2. Responses 615 All TeRI responses consist of a Response Code and optionally a set of 616 Attributes which convey further information about the Operation. 617 Most Attributes are specific to the Operation. 619 5.1.2.1. Response Code 621 All Responses contain a Response Code. 623 Response Codes defined by this document include: Success, Subject 624 Does Not Exist, Subject Conflict, No Suitable Records Exist for 625 Subject, Subject Syntax Error, Unknown Attribute, Unauthorized 626 Source, Route Source Topology Unavailable. 628 [TBD] 630 5.2. The Acquisition Operation 632 An Acquisition Request has a Source and a Subject, and may have one 633 or more Attributes. An Acquisition Response has a Response Code, and 634 will contain one Record if it is successful. 636 The Subject of an Acquisition Request always specifies a Telephone 637 Number Type or a Telephone Number Range Type. If the Subject 638 contains a particular telephone number, then the Acquisition Request 639 is a Request to acquire that particular telephone number. If it is a 640 range, the Acquisition Request should be considered to be for the 641 entire range, but Attributes of the Request may limit the scope of 642 the resources requested. The Service will determine whether or not 643 the Client is authorized to acquire the resources in question based 644 on the Source of the Acquisition Request. 646 The Response to an Acquisition Request will contain a Success 647 Response Code if the resource can be allocated. The Subject of a 648 Success Response will always contain the Telephone Number Type or 649 Telephone Number Range that has been allocated. A successful 650 Acquisition Response must contain a Record with a Identifier Element; 651 that Record may also contain a Public Key attribute. By default, 652 this Record will contain only Administrative Elements, without 653 Service Elements. If a requested telephone number (or range) is 654 already allocated, or a telephone number in the specified range is 655 not available, then a Subject Conflict Response Code is returned. 657 5.3. The Management Operation 659 A Management Request comprises a Source, a Subject, and one or more 660 Records; it also may contain one or more Attributes. A Management 661 Response contains a Response Code, and optionally may contain a 662 Record. 664 The Subject of a Management Request always specifies a Telephone 665 Number Type or a Telephone Number Range Type. In almost all 666 circumstances, however, the Service will locate that Record(s) that a 667 Management Request modifies through the Identifier attribute of each 668 Record in the Management Request. 670 A Management Request contains at least one Record; it may contain 671 multiple Records. Each Record in the Management Request must contain 672 a Record Identifier Element which designates the Record that the 673 Client is requesting that the Service replace with the Record 674 included in the Management Request. The Service will authorize 675 whether or not the Client is authorized to modify the Record in 676 question via the Source of the Management Request. 678 5.4. The Retrieval Operation 680 Every Retrieval Request comprises a Source and a Subject, and may 681 have one or more Attributes. A Retrieval Response has a Response 682 Code, optionally one or more Records, and optionally a Subject, if 683 the Subject differs from that of the Request. 685 Retrieval Requests optionally contain Attributes; a Request with no 686 specified Attributes requests that the Service return any Attributes 687 associated with the Subject. In a Request, the presence of one or 688 more Attributes limits the scope of the Request to Records about the 689 Subject containing those Attributes, or the Attributes otherwise 690 qualify the Request. Typically an Attribute will specify a Service 691 or Service Type that the Client seeks Records for. 693 Successful Retrieval Responses always contain one or more Records; 694 unsuccessful Responses never contain Records. 696 5.5. Common Attributes 698 Attributes are broadly divided between Service Attributes and 699 Administrative Attributes. Service Attributes provide information 700 required to route communications, including URIs. The format of the 701 elements contained in the Attributes is given in Section 4.2. 703 5.5.1. Administrative Attributes 705 Administrative Attributes defined by this document include: CNAM 706 (Type Display Name), SPID (Type SPID), dialplan (Type ?) [TBD] 708 5.5.2. Service Attributes 710 Service Attributes defined by this document include: voip (Type URI), 711 sms (Type URI) [TBD] 713 5.5.2.1. Route Source 715 Optionally, Retrieval Requests may contain a Route Source Attribute 716 which identifies a reference point in the network from which any 717 Service Attributes in the response should be calculated. It 718 therefore always designates a network element, though depending on 719 the circumstances, it may be an endpoint, a gateway, a border device, 720 or any other agent that makes forwarding decisions for telephone 721 calls and related services. 723 A Route Source element has a Type, which indicates how the network 724 element has been represented. The Type field of the Request Source 725 is extensible. Initial values include a domain name, an IP address 726 or a trunk group. 728 The Type of the Route Source element is followed by a Value, which 729 designates the network element. The format of the identity is 730 determined by the Type. 732 6. Implementing Operations 734 This framework specifies an abstract Request/Response protocol that 735 enables a Client to send Requests to a Service about telephone 736 numbers or related telephone services. Requests may pass through one 737 or more Intermediaries on their way from a Client to a Service; for 738 example, through aggregators or service bureaus. A Client 739 establishes the Subject of a Request, and optionally includes one or 740 more Attributes to focus the scope of the Request. When a Service 741 receives a Request, it performs any necessary authorization and 742 policy decisions based on the Source. If policy permits, the Service 743 generates a Response, which will consist of a Response Code and one 744 or more Records associated with the Subject. The Service then sends 745 the Response through the same path that the Request followed; 746 transactional identifiers set by the Client and Service correlate the 747 Request to the Response and assist any intermediary routing. 749 6.1. Transport Independence 751 The information model provided for Requests and Responses in this 752 framework is independent of any underlying transport or encoding. 753 Future specifications will define Bindings that specify particular 754 transports and Encodings for Requests and Responses. In some 755 deployment environments, for example, a binary encoding and 756 lightweight transport might be more appropriate than the use of a web 757 protocol. This specification provides a template of requirements 758 that must be addressed by any encoding scheme. 760 It is a design goal of this work that the semantics of Requests and 761 Responses survive interworking through translations from one encoding 762 to another; for example, when an Intermediary receives a binary 763 Request from a Client, it should be able to transcode it to an XML 764 format to send to a Service without discarding any of the original 765 semantics. 767 6.2. Bindings 769 A TeRI Binding is an underlying protocol that carries Requests and 770 Responses. Future specifications may define Bindings in accordance 771 with the procedures in the IANA Considerations sections of this 772 document. 774 By underlying protocol, this specification means both transport-layer 775 protocols as well as any application-layer protocols that the Binding 776 requires. Thus an example Binding might specify a combination of 777 TCP, TLS, HTTP and SOAP as the underlying transport for TeRI. 778 Alternatively, it might only specify a very lightweight underlying 779 protocol like UDP. A Binding may be specific to a particular 780 Encoding, or it may be independent of any Encoding. 782 Bindings must specify whether they are continuous, transactional or 783 non-transactional. A continuous Binding creates a persistent 784 connection between two TeRI entities over which many, potentially 785 unrelated, Requests and Responses might flow. Many Bindings defined 786 for use between an Intermediary and a Service will have this 787 property, as Intermediaries may aggregate on behalf of many Clients, 788 and opening a separate transport-layer connection for each new 789 Request would be inefficient. A transactional Binding creates a 790 temporary connection between two TeRI entities for the purpose of 791 fulfilling a single Request; any Responses to the Request will use 792 the same connection to return to the sender of the Request. Finally, 793 a non-transactional Binding does not rely on any sort of connection 794 semantics: the senders of Requests and Responses will always initiate 795 a new instance of the Binding to send a message. 797 This document makes no provision for discovering the Bindings 798 supported by a TeRI Client, Intermediary or Service. Intermediaries 799 may transcode between Bindings if necessary when acting to connect a 800 Client and a Service, especially if the Client and Service support no 801 Bindings in common. 803 A Binding specification must enumerate all categories of metadata 804 required to establish a connection using a Binding. For some 805 Bindings, this might comprise solely an IP address and a port; for 806 other Bindings, this might instead require higher-layer application 807 identifiers like a URI. This metadata includes any identifiers 808 necessary for correlating Requests to Responses in a continuous or 809 non-transactional Binding; any Encoding making use of these Bindings 810 must specify how it carries those elements. 812 Bindings must also describe the security services they make 813 available. Bindings must have a means of providing mutual 814 authentication, integrity and confidentiality between Clients, 815 Intermediaries and Services. If a Binding supports TLS, for example, 816 these features can be provided by using TLS in an appropriate 817 deployment environment. 819 6.3. Encodings 821 A TeRI Encoding specifies how the Request and Response are 822 constructed syntactically. An Encoding may be specific to a 823 particular Binding, or it may be specified independently of any 824 Binding. 826 An Encoding may define an object format; for example, an XML or JSON 827 object, described with any appropriate schemas, or an ABNF 828 description. An Encoding might alternatively specify a mapping of 829 the semantic elements of Requests and Responses on to the existing 830 fields of headers of a protocol, especially when that protocol has 831 been defined as an underlying protocol Binding. Encodings must also 832 define whether or not they provide a bundling feature that allows 833 multiple Requests to be carried within particular objects or 834 mappings. 836 Every Encoding must specify how each semantic Element Type of a 837 Request and Response will be represented. For all baseline TeRI 838 Attributes and Element Types, the Encoding specifies whether values 839 will be text or binary, how they will be encoded. Many baseline 840 Element Types (such as telephone numbers) can appear in different 841 places in a TeRI message; Encodings need only specify these common 842 element types once. Due to the extensibility of TeRI, however, 843 future specifications might define Element Types that an Encoding 844 does not address. Profiles using those extensions and Encodings must 845 explain their interaction. 847 Encodings must also describe the security services they make 848 available. In particular, encodings must describe a means of 849 providing authentication of the Sources and Authorities of Requests 850 and Responses respectively, as well as an integrity check over 851 critical elements including the Subject of Requests and the Record of 852 Responses. 854 [TBD - we may define more about the computation of this signature, 855 including canonicalization of elements, in this framework, and make 856 it a requirement for encodings to support this mechanism] 858 6.4. Profiles 860 For particular deployment environments, only one Binding, Encoding 861 and set of Attributes or other extended elements may be meaningful. 862 Future specifications may therefore define TeRI Profiles, which 863 describe a particular deployment environment and the Binding, 864 Encoding and set of Attributes or elements it requires. 866 Profiles may be extensible, but any Attributes or elements required 867 to negotiate support for extensions must be defined within the 868 Profile. 870 7. Security Considerations 872 The framework of this document differs from previous efforts to 873 manage telephone numbers on the Internet largely by offering a much 874 richer set of security services. In particular, it requires that 875 three entities be capable of authenticating themselves to one another 876 at the layer of a binding: Clients, Intermediaries and Services. It 877 furthermore requires object security at the encoding layer so that 878 Sources and Authorities can sign data in order to authenticate 879 Requests and Responses that may pass through Intermediaries, and 880 moreover so that Authorities can prove to Clients that their Records 881 are authoritative even when the Authority does not operate the 882 Service. The requirements that bindings and encodings must satisfy 883 to meet these security needs are specified in Section 6.1. 885 [TBD - more] 887 8. IANA Considerations 889 This specification defines several registries: A registry of 890 Elements, a registry of Element Types, a registry of Attributes, and 891 a registry of Response Codes. 893 This document creates a registry of Elements for use with this 894 framework. This registry is extensible, with an IANA Registration 895 policy of Specification Required. Any new Element registered must 896 supply the name of the Element, the name of the parent Element in the 897 information model, and a code point. [TBD] 899 This specification pre-provisions the Element Types registry with the 900 entries given in Section 6. These elements are indexed by their Type 901 Code. This registry is extensible, with an IANA Registration policy 902 of Specification Required. Any new Element Type registered must 903 supply the name of the Element Type, the name of the parent element 904 in the information model, and a Type Code. 906 This specification creates an Attribute registry which is indexed by 907 Attribute names. This registry is extensible, with an IANA 908 Registration policy of Specification Required. Any new element 909 registered must supply the name of Attribute, and list all Element 910 Types that may be associated with Values of the Attribute. 912 This document furthermore creates a registry of Response Codes. This 913 registry is pre-provisioned with the values given in Section 5.5. 914 [TBD] 916 9. Acknowledgements 918 The authors would like to thank Paul Kyzviat and Dale Worley for 919 their input into this specification. 921 10. Informative References 923 [I-D.ietf-modern-problem-framework] 924 Peterson, J. and T. McGarry, "Modern Problem Statement, 925 Use Cases, and Framework", draft-ietf-modern-problem- 926 framework-01 (work in progress), July 2016. 928 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 929 Application and Support", STD 3, RFC 1123, 930 DOI 10.17487/RFC1123, October 1989, 931 . 933 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 934 Requirement Levels", BCP 14, RFC 2119, 935 DOI 10.17487/RFC2119, March 1997, 936 . 938 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 939 A., Peterson, J., Sparks, R., Handley, M., and E. 940 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 941 DOI 10.17487/RFC3261, June 2002, 942 . 944 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 945 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 946 . 948 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 949 Extensions to the Session Initiation Protocol (SIP) for 950 Asserted Identity within Trusted Networks", RFC 3325, 951 DOI 10.17487/RFC3325, November 2002, 952 . 954 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 955 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 956 . 958 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 959 RFC 3966, DOI 10.17487/RFC3966, December 2004, 960 . 962 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 963 Resource Identifier (URI): Generic Syntax", STD 66, 964 RFC 3986, DOI 10.17487/RFC3986, January 2005, 965 . 967 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 968 Authenticated Identity Management in the Session 969 Initiation Protocol (SIP)", RFC 4474, 970 DOI 10.17487/RFC4474, August 2006, 971 . 973 [RFC4904] Gurbani, V. and C. Jennings, "Representing Trunk Groups in 974 tel/sip Uniform Resource Identifiers (URIs)", RFC 4904, 975 DOI 10.17487/RFC4904, June 2007, 976 . 978 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 979 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 980 2007, . 982 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 983 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 984 January 2008, . 986 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 987 Requirements", RFC 5067, DOI 10.17487/RFC5067, November 988 2007, . 990 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 991 for the Session Initiation Protocol (SIP) and the Real- 992 time Applications and Infrastructure Area", BCP 67, 993 RFC 5727, DOI 10.17487/RFC5727, March 2010, 994 . 996 [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., 997 "Essential Correction for IPv6 ABNF and URI Comparison in 998 RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, 999 . 1001 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1002 Uniform Resource Identifiers (URI) Dynamic Delegation 1003 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1004 DOI 10.17487/RFC6116, March 2011, 1005 . 1007 [RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for 1008 Multimedia INTerconnect (SPEERMINT) Architecture", 1009 RFC 6406, DOI 10.17487/RFC6406, November 2011, 1010 . 1012 [RFC6461] Channabasappa, S., Ed., "Data for Reachability of Inter- 1013 /Intra-NetworK SIP (DRINKS) Use Cases and Protocol 1014 Requirements", RFC 6461, DOI 10.17487/RFC6461, January 1015 2012, . 1017 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1018 of Named Entities (DANE) Transport Layer Security (TLS) 1019 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1020 2012, . 1022 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 1023 "Architectural Considerations on Application Features in 1024 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 1025 . 1027 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 1028 DOI 10.17487/RFC7095, January 2014, 1029 . 1031 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1032 Telephone Identity Problem Statement and Requirements", 1033 RFC 7340, DOI 10.17487/RFC7340, September 2014, 1034 . 1036 Author's Address 1038 Jon Peterson 1039 Neustar, Inc. 1041 Email: jon.peterson@neustar.biz