idnits 2.17.1 draft-peterson-modern-teri-00.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 (October 19, 2015) is 3112 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 366, but not defined == Missing Reference: 'TBD' is mentioned on line 772, but not defined == Unused Reference: 'RFC3324' is defined on line 802, but no explicit reference was found in the text == Unused Reference: 'RFC3325' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'RFC4474' is defined on line 825, but no explicit reference was found in the text == Unused Reference: 'RFC4916' is defined on line 836, but no explicit reference was found in the text == Unused Reference: 'RFC5039' is defined on line 840, but no explicit reference was found in the text == Unused Reference: 'RFC5727' is defined on line 848, but no explicit reference was found in the text == Unused Reference: 'RFC6698' is defined on line 875, but no explicit reference was found in the text == Unused Reference: 'RFC6950' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'RFC7340' is defined on line 889, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-peterson-modern-problems-01 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 1 error (**), 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 19, 2015 5 Expires: April 21, 2016 7 A Framework and Information Model for Telephone-Related Information 8 (TeRI) 9 draft-peterson-modern-teri-00 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 adminsitration data 17 associated with 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 April 21, 2016. 36 Copyright Notice 38 Copyright (c) 2015 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. The Information Model . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Record Elements . . . . . . . . . . . . . . . . . . . . . 5 69 3.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 5 70 3.1.2. Authority . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1.3. Contact . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1.4. Subject . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1.5. Service . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.1.6. Signature . . . . . . . . . . . . . . . . . . . . . . 6 75 3.2. Element Value Types . . . . . . . . . . . . . . . . . . . 6 76 3.2.1. Service Types . . . . . . . . . . . . . . . . . . . . 6 77 3.2.2. Public Key Type . . . . . . . . . . . . . . . . . . . 8 78 3.2.3. Contact Type . . . . . . . . . . . . . . . . . . . . 8 79 3.2.4. Expiry Type . . . . . . . . . . . . . . . . . . . . . 8 80 3.2.5. Priority Type . . . . . . . . . . . . . . . . . . . . 8 81 3.2.6. Record Identifier Type . . . . . . . . . . . . . . . 8 82 3.2.7. Signature . . . . . . . . . . . . . . . . . . . . . . 8 83 3.2.8. Extension Type . . . . . . . . . . . . . . . . . . . 8 84 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4.1. Common to All Operations . . . . . . . . . . . . . . . . 9 86 4.1.1. Requests . . . . . . . . . . . . . . . . . . . . . . 9 87 4.1.2. Responses . . . . . . . . . . . . . . . . . . . . . . 11 88 4.2. The Acquisition Operation . . . . . . . . . . . . . . . . 11 89 4.3. The Management Operation . . . . . . . . . . . . . . . . 12 90 4.4. The Retrieval Operation . . . . . . . . . . . . . . . . . 12 91 4.5. Common Attributes . . . . . . . . . . . . . . . . . . . . 12 92 4.5.1. Administrative Attributes . . . . . . . . . . . . . . 13 93 4.5.2. Service Attributes . . . . . . . . . . . . . . . . . 13 94 5. Implementing Opertions . . . . . . . . . . . . . . . . . . . 13 95 5.1. Transport Independence . . . . . . . . . . . . . . . . . 14 96 5.2. Bindings . . . . . . . . . . . . . . . . . . . . . . . . 14 97 5.3. Encodings . . . . . . . . . . . . . . . . . . . . . . . . 15 98 5.4. Profiles . . . . . . . . . . . . . . . . . . . . . . . . 16 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 102 9. Informative References . . . . . . . . . . . . . . . . . . . 17 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 105 1. Terminology 107 In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 108 and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 110 2. Motivation 112 Telephone numbers remain the worldwide standard identifier for 113 routing calls and text messages over the Public Switched Telephone 114 Network (PSTN). Increasingly, real-time communications is migrating 115 to the Internet, and bringing telephone numbers with it. As 116 identifiers, however, telephone numbers differ fundamentally from 117 those commonly used by Internet applications. Email, the web and 118 native Voice over IP (VoIP) systems such as SIP ([RFC3261]) typically 119 use identifiers that rely on the Domain Name System (DNS) to resolve 120 a domain portion of the identifier to a particular IP address; 121 commonly, Uniform Resource Indicators (URIs) with a user and host 122 component serve this purpose. To help telephone numbers work 123 similarly on the Internet, a number of efforts have specified 124 mechanisms to manage and retrieve information about telephone numbers 125 via network services. 127 For example, the ENUM ([RFC6116]) effort specified a public DNS 128 profile for translating telephone numbers into URIs. Due to the 129 difficulty of coordinating the public administration of telephone 130 numbers in the DNS, this work transitioned to "infrastructure" ENUM 131 ([RFC5067]), which assumed private DNS implementations, each of which 132 could give a different answer to the same request to translate a 133 telephone number depending on who asked, or other internal factors. 134 The framework of the SPEERMINT working group ([RFC6406]), expanding 135 on these requirements, differentiated the mapping of a telephone 136 number to a target network (the "Look-up Function") from the mapping 137 made by the originating network to the proper next-hop to reach such 138 a target network (the "Location Routing Function"). To provision the 139 data associated with telephone numbers, the DRINKS working group 140 ([RFC6461]) designed systems for uploading back-end data to the 141 services that would answer ENUM queries. 143 None of the preceding efforts, however, encompassed the entire 144 lifecycle of a telephone number as an Internet identifier. They 145 focused largely on service data, on how to "resolve" a telephone 146 number to a location on the Internet, rather than on administrative 147 questions of how numbers are acquired, how the entities associated 148 with telephone numbers are authorized to provision data, and how what 149 kinds of systems need to be in place to allow a diverse community of 150 devices, applications and uses to manage numbers. Early 151 considerations were moreover based on overlapping, but not entirely 152 consistent, information models: intrinsic limitations in the DNS kept 153 the queries and responses of ENUM relatively simple, whereas the 154 DRINKS provisioning system considered a much richer syntax. 156 The need for solutions in this space is pressing, as many carriers 157 worldwide contemplate migrating their entire PSTN infrastructure onto 158 the Internet within the next decade. Further pressures come from 159 emerging Internet communications providers who never invested in PSTN 160 infrastructure in the first place, but want access to services 161 related to telephone numbers. This includes devices, services, and 162 applications on the Internet that make use of telephone numbers and 163 need to distribute and manage numbering inventory: for example, an 164 Internet-enabled PBX that might want to automate the process for 165 allowing new connected phones to acquire numbers and provision 166 contact information for their users. These different communities 167 have diverse requirements. In some environments, there are 168 performance constraints that would require a very lightweight binary 169 protocol; in others, applications might prefer human-readable markup 170 languages suitable for interfacing with existing APIs. The use cases 171 associated with these functions are detailed in 172 [I-D.peterson-modern-problems]. 174 Therefore, this document proposes a reconsideration of telephone 175 service and administration data on the Internet, based on an 176 information model that allows records associated with telephone 177 number to be created, modified and accessed through network 178 interfaces. This document specifies no particular syntax or encoding 179 for queries or responses, but instead describes an extensible 180 information model for the semantics of provisioning and querying 181 operations associated with a telephone number. 183 3. The Information Model 185 The fundamental building block of the TeRI model is the Record. A 186 Record is created by an Authority who has authority over a particular 187 telephone number or a set of numbers. There may be more than one 188 Authority who is authorized to create Records for a particular 189 telephone number, and a TeRI service may have multiple Records 190 corresponding to a single telephone number, including potentially 191 Records associated with a range of numbers including a particular 192 telephone number. Under various circumstances detailed in Section 4, 193 participants in the numbering ecosystem may create, read, update, and 194 modify Records. 196 Records contain Elements that hold data about the telephone number. 197 Elements in this information model have a Name, which may optionally 198 be associated with a Type and Value. Elements are grouped into 199 Service Elements and Administrative Elements. 201 3.1. Record Elements 203 A Record is made up of Elements, which may be either Service Data 204 Elements or Administrative Data Elements. 206 3.1.1. Identifier 208 Every Record has an Identifier, which is a globally unique identifier 209 of the Record. The Identifier will typically be created at the same 210 time as the Record itself, at a time when an assignment or delegation 211 has occurred (as described in [I-D.peterson-modern-problems]). 213 3.1.2. Authority 215 Every Record contains an Authority element the source of the data: 216 either the entity that provisioned the data with the Service, or the 217 external source from which the Service collected the data. The 218 Authority element ideally gives a logical identity of the source of 219 the data. A public key value may also be designated by the Authority 220 element. 222 3.1.3. Contact 224 Every Record has at least one Contact. The Contact contains 225 administrative data about the assignee of the telephone number, 226 though additional Contacts may contain information about delegates 227 (as defined in [I-D.peterson-modern-problems]). 229 3.1.4. Subject 231 Every Record has a Subject. As the TeRI record concerns telephone 232 numbers, the Subject of a Record is either a telephone number type or 233 a telephone number range type. 235 3.1.5. Service 237 Records optionally have one or more Service entries. A Service may 238 be of any Service Type, as given in Section 3.2.1. 240 3.1.5.1. Priority 242 Optionally, a Service may specify a weighted Priority associated with 243 a Record. Priorities are between 0 and 1, with a value of 1 having 244 the highest priority. 246 3.1.5.2. Expiration 248 Optionally, a Service may specify an absolute time at which a Record 249 will no longer be valid, should a client or intermediary wish to 250 cache a Record. In the absence of an Expiration element, Records may 251 be cached for a maximum of twenty-four hours. 253 3.1.6. Signature 255 Optionaly, a Record contains a Signature element. The Signature 256 element contains a signature over the concatenation of the other 257 elements given the Record. Signatures are provided by the Authority 258 responsible for the Record. 260 [Syntax TBD] 262 3.2. Element Value Types 264 The remainder of a Record is made up of Elements. Elements types ae 265 specified in this section. Every Element Type has a Type Code. A 266 Type Code is used as a short form for the Element in a Record. 268 3.2.1. Service Types 270 3.2.1.1. Telephone Number Type 272 The telephone number type conforms to the telephone number syntax 273 given in [RFC3966] Section 3, in the ABNF for "telephone-subscriber." 275 Type Code: T 277 [TBD - need for subtying? E.164, Service Code, Short Code, Prefix, 278 Nationally-Specific and Unknown. ] 280 3.2.1.1.1. TN Range Type 282 The TN range type consists of a prefix of a telephone number (per 283 [RFC3966] "telephone-subscriber"), and is semantically equivalent to 284 all syntactically-valid telephone numbers below that prefix. For 285 example, in the North American Numbering plan, the prefix 157143454 286 would be equivalent to all numbers ranging from 15714345400 to 287 15714345499. 289 [TBD - identify alternative ways of specifying ranges, potentially as 290 separate element types] 292 Type Code: R 294 3.2.1.2. Domain Name Type 296 The domain name type conforms to the syntax of RFC1034 Section 3.5 297 and Section 2.1 of [RFC1123]. 299 Type Code: D 301 3.2.1.3. Uniform Resource Indicator (URI) Type 303 The Uniform Resource Indicator (URI) type conforms to the syntax for 304 URIs given in [RFC3986] (see Section 3). 306 Type Code: U 308 3.2.1.4. Internet Protocol (IP) Address Type 310 The IP Address type conforms to the ABNF syntax of either the 311 IPv4address given in RFC3986 (Appendix A) or the IPv6reference of 312 [RFC5954]. 314 Type Code: I 316 3.2.1.5. Trunk Group Type 318 The trunk group type conforms to the "trunk-group-label" ABNF given 319 in [RFC4904] (Section 5). 321 Type Code: G 323 3.2.1.6. Service Provider Identifier (SPID) Type 325 The SPID type consists of a four-digit number. 327 [TBD - introduce other elements for alternative SPID syntaxes] 328 Type Code: ? 330 3.2.2. Public Key Type 332 The Credential type consists of a public key [encoding TBD]. 334 Type Code: C 336 3.2.3. Contact Type 338 The contact type follows the conventions of jCard [RFC7095]. 340 Type Code: C 342 3.2.4. Expiry Type 344 The Expiry type is an absolute time conformant to the syntax of 345 [RFC3339]. 347 Type Code: E 349 3.2.5. Priority Type 351 The Priority type contains a number between 0 and 1, conforming to 352 the specification of the "q" parameter of the Contact header field in 353 [RFC3261]. 355 Type Code: P 357 3.2.6. Record Identifier Type 359 The Record Identifier Type consists of a unique identifier for a 360 record [format TBD]. 362 Type Code: U 364 3.2.7. Signature 366 [Syntax TBD] 368 Type Code: S 370 3.2.8. Extension Type 372 This code is reserved for future use. 374 Type Code: X 376 4. Operations 378 In this section are detailed the three TeRI Operations: Acquisition, 379 Management, and Retrieval Operations. 381 4.1. Common to All Operations 383 All Operations in the TeRI model consist of Requests and Responses. 384 A Request from a TeRI client to a service may attempt to create, 385 read, update, or delete TeRI Records. Requests may focus only on 386 particular parts of a TeRI record. A Response gives the result of 387 the Operation back to the client, which may indicate success of 388 failure. 390 4.1.1. Requests 392 All TeRI Requests have a Source, a Subject, and optionally a set of 393 Attributes which further specify the nature of the Request. Some 394 Requests will know the Identifier of the Record they concern, and may 395 convey that in an Attribute; others will query for all Records 396 matching a given Subject. 398 4.1.1.1. Source 400 The Source is a required element in all Requests. In this 401 specification, two categories of Sources are defined: Request Source 402 and Request Intermediary. At least one of these Sources must be 403 present in a Retrieval Request, and multiple Sources are permitted. 404 Responses do not contain a Source. 406 Future specifications may extend the set of Source types. 408 4.1.1.1.1. Request Source 410 Every Request generated by a Client has a Request Source, which 411 identifies the originator of the Request. This represents the 412 logical identity of the user or service provider who first sent the 413 Request, rather than the identity of any Intermediate entity. This 414 field is provided in the Source to authenticate the poser of the 415 Request, so that the Service can make any necessary authorization 416 decisions as it formulates a Response. 418 In some service deployments, an Intermediary may wish to mask the 419 Request's Source from a Service. The removal of the Request's Source 420 by an intermediary is permitted by TeRI, but any Intermediary that 421 removes the Request Source must provide a Request Intermediary for 422 the Source element. 424 A Request Source element has a Type, which indicates how the logical 425 identity of the originator of the Request has been represented. The 426 Type field of the Request Source is extensible. Initial values 427 include a domain name, a URI and a telephone number. 429 The Type element of the Request Source is followed by a Value, which 430 contains the identity. The format of the identity is determined by 431 the Type. 433 4.1.1.1.2. Request Intermediary 435 Optionally, Requests may contain one or more Request Intermediary 436 elements in the Source. A Request Intermediary resides between the 437 originator of the Request (the Client) and the Service, where it may 438 aggregate queries, proxy them, transcode them, or provide any related 439 relay function to assist the delivery of Requests to the Service. 441 The Request Intermediary element, like the Request Source, contains 442 the logical identity of the service that relayed the Request. This 443 field is provided in the Source for those deployments in which the 444 Service makes an authorization decision based on the identity of the 445 Intermediary rather than a Request Source. 447 A Request Intermediary element has a Type, which indicates how the 448 logical identity of the Intermediary has been represented. The Type 449 element of the Request Intermediary is extensible. Initial values 450 include a domain name, an X.509 certificate subject, or a URI. 452 The Type of the Request Intermediary element is followed by a Value, 453 which contains the identity. The format of the identity is 454 determined by the Type. 456 4.1.1.2. Subject 458 All Requests have a Subject. The Subject identifies the resource 459 that the Request concerns. Responses only contain a Subject if the 460 Subject of the Response differs from that of the original Request, 461 which may occur when (for example) the Subject contains a broad 462 range, and the Service replies with a more narrow Subject. Future 463 specifications, including Profiles, may define alternative Subject 464 elements. 466 4.1.1.2.1. Attributes 468 TeRI Attributes consist of a Name with an optional Type and an 469 Optional Value. Most Attributes are specific to the Operation. 471 4.1.2. Responses 473 All TeRI responses consist of a Response Code and optionally a set of 474 Attributes which convey further information about the Operation. 475 Most Attributes are specific to the Operation. 477 4.1.2.1. Response Code 479 All Responses contain a Response Code. 481 Response Codes defined by this document include: Success, Subject 482 Does Not Exist, Subject Conflict, No Suitable Records Exist for 483 Subject, Subject Syntax Error, Unknown Attribute, Unauthorized 484 Source, Route Source Topology Unavailable. 486 [TBD] 488 4.2. The Acquisition Operation 490 An Acquisition Request has a Source and a Subject, and may have one 491 or more Attributes. An Acquisition Response has a Response Code, and 492 will contain one Record if it is succesful. 494 The Subject of an Acquisition Request always specifies a Telephone 495 Number Type or a Telephone Number Range Type. If the Subject 496 contains a particular telephone number, then the Acquisition Request 497 is a Request to acquire that particular telephone number. If it is a 498 range, the Acquisition Request should be considered to be for the 499 entire range, but Attributes of the Request may limit the scope of 500 the resources requested. The Service will determine whether or not 501 the Client is authorized to acquire the resources in question based 502 on the Source of the Acqusition Request. 504 The Response to an Acquisition Request will contain a Success 505 Response Code if the resource can be allocated. The Subject of a 506 Success Response will always contain the Telephone Number Type or 507 Telephone Number Range that has been allocated. A successful 508 Acqusition Response must contain a Record with a Identifier Element; 509 that Record may also contain a Public Key attribute. By default, 510 this Record will contain only Administrative Elements, without 511 Service Elements. If a requested telephone number (or range) is 512 already allocated, or a telephone number in the specified range is 513 not available, then a Subject Conflict Response Code is returned. 515 4.3. The Management Operation 517 A Management Request comprises a Source, a Subject, and one or more 518 Records; it also may contain one or more Attributes. A Management 519 Request contains a Response Code, and optionally may contain a 520 Record. 522 The Subject of a Management Request always specifies a Telephone 523 Number Type or a Telephone Number Range Type. If the Subject 524 contains a particular telephone number, then the Acquisition Request 525 is a Request to acquire that particular telephone number. If it is a 526 range, the Acquisition Request should be considered to be for the 527 entire range. 529 A Management Request contains at least one Record; it may contain 530 multiple Records. Each Record in the Management Request must contain 531 a Record Identifier Element which designates the Record that the 532 Client is requesting that the Service replace with the Record 533 included in the Management Request. The Service will determine 534 whether or not the Client is authorized to modify the Record in 535 question via the Source of the Management Request. 537 4.4. The Retrieval Operation 539 Every Retrieval Request comprises a Source and a Subject, and may 540 have one or more Attributes. A Retrieval Response has a Response 541 Code, optionally one or more Records, and optionally a Subject, if 542 the Subject differs from that of the Request. 544 Retrieval Requests optionally contain Attributes; a Request with no 545 specified Attributes requests that the Service return any Attributes 546 associated with the Subject. In a Request, the presence of one or 547 more Attributes limits the scope of the Request to Records about the 548 Subject containing those Attributes. Typically an Attribute will 549 specify a Service or Service Type that the Client seeks Records for. 551 Retrieval Responses contain one or more Records. At least one Record 552 will always be present in a successful Response. 554 4.5. Common Attributes 556 Attributes are broadly divided between Service Attributes and 557 Administrative Attributes. Service Attributes provide information 558 required to route communications, including URIs. The format of the 559 elements contained in the Attributes is given in Section 3.2. 561 4.5.1. Administrative Attributes 563 Administrative Attributes defined by this document include: CNAM 564 (Type Display Name), SPID (Type SPID), dialplan (Type ?) [TBD] 566 4.5.2. Service Attributes 568 Service Attributes defined by this document include: voip (Type URI), 569 sms (Type URI) [TBD] 571 4.5.2.1. Route Source 573 Optionally, Retrieval Requests may contain a Route Source Attribute 574 which identifies a reference point in the network from which any 575 Service Attributes in the response should be calculated. It 576 therefore always designates a network element, though depending on 577 the circumstances, it may be an endpoint, a gateway, a border device, 578 or any other agent that makes forwarding decisions for telephone 579 calls and related services. 581 A Route Source element has a Type, which indicates how the network 582 element has been represented. The Type field of the Request Source 583 is extensible. Initial values include a domain name, an IP address 584 or a trunk group. 586 The Type of the Route Source element is followed by a Value, which 587 designates the network element. The format of the identity is 588 determined by the Type. 590 5. Implementing Opertions 592 This framework specifies an abstract Request/Response protocol that 593 enables a Client to send Requests to a Service about telephone 594 numbers or related telephone services. Requests may pass through one 595 or more Intermediaries on their way from a Client to a Service; for 596 example, through aggregators or service bureaus. A Client 597 establishes the Subject of a Request, and optionally includes one or 598 more Attributes to focus the scope of the Request. When a Service 599 receives a Request, it performs any necessary authorization and 600 policy decisions based on the Source. If policy permits, the Service 601 generates a Response, which will consist of a Response Code and one 602 or more Records associated with the Subject. The Service then sends 603 the Response through the same path that the Request followed; 604 transactional identifiers set by the Client and Service correlate the 605 Request to the Response and assist any intermediary routing. 607 5.1. Transport Independence 609 The information model provided for Requests and Responses in this 610 framework is independent of any underlying transport or encoding. 611 Future specifications will define Bindings that specify particular 612 transports and Encodings for Requests and Responses. In some 613 deployment environments, for example, a binary encoding and 614 lightweight transport might be more appropriate than the use of a web 615 protocol. This specification provides a template of requirements 616 that must be addressed by any encoding scheme. 618 It is a design goal of this work that the semantics of Requests and 619 Responses survive interworking through translations from one encoding 620 to another; for example, when an Intermediary receives a binary 621 Request from a Client, it should be able to transcode it to an XML 622 format to send to a Service without discarding any of the original 623 semantics. 625 5.2. Bindings 627 A TeRI Binding is an underlying protocol that carries Requests and 628 Responses. Future specifications may define Bindings in accordance 629 with the procedures in the IANA Considerations sections of this 630 document. 632 By underlying protocol, this specification means both transport-layer 633 protocols as well as any application-layer protocols that the Binding 634 requires. Thus an example Binding might specify a combination of 635 TCP, TLS, HTTP and SOAP as the underlying transport for TeRI. 636 Alternatively, it might only specify a very lightweight underlying 637 protocol like UDP. A Binding may be specific to a particular 638 Encoding, or it may be independent of any Encoding. 640 Bindings must specify whether they are continuous, transactional or 641 non-transactional. A continuous Binding creates a persistent 642 connection between two TeRI entities over which many, potentially 643 unrelated, Requests and Responses might flow. Many Bindings defined 644 for use between an Intermediary and a Service will have this 645 property, as Intermediaries may aggregate on behalf of many Clients, 646 and opening a separate transport-layer connection for each new 647 Request would be inefficient. A transactional Binding creates a 648 temporary connection between two TeRI entities for the purpose of 649 fulfilling a single Request; any Responses to the Request will use 650 the same connection to return to the sender of the Request. Finally, 651 a non-transactional Binding does not rely on any sort of connection 652 semantics: the senders of Requests and Responses will always initiate 653 a new instance of the Binding to send a message. 655 This document makes no provision for discovering the Bindings 656 supported by a TeRI Client, Intermediary or Service. Intermediaries 657 may transcode between Bindings if necessary when acting to connect a 658 Client and a Service, especially if the Client and Service support no 659 Bindings in common. 661 A Binding specification must enumerate all categories of metadata 662 required to establish a connection using a Binding. For some 663 Bindings, this might comprise solely an IP address and a port; for 664 other Bindings, this might instead require higher-layer application 665 identifiers like a URI. This metadata includes any identifiers 666 necessary for correlating Requests to Responses in a continuous or 667 non-transactional Binding; any Encoding making use of these Bindings 668 must specify how it carries those elements. 670 Bindings must also describe the security services they make 671 available. Bindings must have a means of providing mutual 672 authentication, integrity and confidentiality between Clients, 673 Intermediaries and Services. If a Binding supports TLS, for example, 674 these features can be provided by using TLS in an appropriate 675 deployment environment. 677 5.3. Encodings 679 A TeRI Encoding specifies how the Request and Response are 680 constructed syntactically. An Encoding may be specific to a 681 particular Binding, or it may be specified independently of any 682 Binding. 684 An Encoding may define an object format; for example, an XML or JSON 685 object, described with any appropriate schemas, or an ABNF 686 description. An Encoding might alternatively specify a mapping of 687 the semantic elements of Requests and Responses on to the existing 688 fields of headers of a protocol, especially when that protocol has 689 been defined as an underlying protocol Binding. Encodings must also 690 define whether or not they provide a bundling feature that allows 691 multiple Requests to be carried within particular objects or 692 mappings. 694 Every Encoding must specify how each semantic Element Type of a 695 Request and Response will be represented. For all baseline TeRI 696 Attributes and Element Types, the Encoding specifies whether values 697 will be text or binary, how they will be encoded. Many baseline 698 Element Types (such as telephone numbers) can appear in different 699 places in a TeRI message; Encodings need only specify these common 700 element types once. Due to the extensibility of TeRI, however, 701 future specifications might define Element Types that an Encoding 702 does not address. Profiles using those extensions and Encodings must 703 explain their interaction. 705 Encodings must also describe the security services they make 706 available. In particular, encodings must describe a means of 707 providing authentication of the Sources and Authorities of Requests 708 and Responses respectively, as well as an integrity check over 709 critical elements including the Subject of Requests and the Record of 710 Responses. 712 [TBD - we may define more about the computation of this signature, 713 including canonicalization of elements, in this framework, and make 714 it a requirement for encodings to support this mechanism] 716 5.4. Profiles 718 For particular deployment environments, only one Binding, Encoding 719 and set of Attributes or other extended elements may be meaningful. 720 Future specifications may therefore define TeRI Profiles, which 721 describe a particular deployment environment and the Binding, 722 Encoding and set of Attributes or elements it requires. 724 Profiles may be extensible, but any Attributes or elements required 725 to negotiate support for extensions must be defined within the 726 Profile. 728 6. Security Considerations 730 The framework of this document differs from previous efforts to 731 manage telephone numbers on the Internet largely by offering a much 732 richer set of security services. In particular, it requires that 733 three entities be capable of authenticating themselves to one another 734 at the layer of a binding: Clients, Intermediaries and Services. It 735 furthermore requires object security at the encoding layer so that 736 Sources and Authorities can sign data in order to authenticate 737 Requests and Responses that may pass through Intermediaries, and 738 moreover so that Authorities can prove to Clients that their Records 739 are authoritative even when the Authority does not operate the 740 Service. The requirements that bindings and encodings must satisfy 741 to meet these security needs are specified in Section 5.1. 743 [TBD - more] 745 7. IANA Considerations 747 This specification defines several registries: A registry of 748 Elements, a registry of Element Types, a registry of Attributes, and 749 a registry of Response Codes. 751 This document creates a registry of Elements for use with this 752 framework. This registry is extensible, with an IANA Registration 753 policy of Specification Required. Any new Element registered must 754 supply the name of the Element, the name of the parent Element in the 755 information model, and a code point. [TBD] 757 This specification pre-provisions the Element Types registry with the 758 entries given in Section 6. These elements are indexed by their Type 759 Code. This registry is extensible, with an IANA Registration policy 760 of Specification Required. Any new Element Type registered must 761 supply the name of the Element Type, the name of the parent element 762 in the information model, and a Type Code. 764 This specification creates an Attribute registry which is indexed by 765 Attribute names. This registry is extensible, with an IANA 766 Registration policy of Specification Required. Any new element 767 registered must supply the name of Attribute, and list all Element 768 Types that may be associated with Values of the Attribute. 770 This document furthermore creates a registry of Response Codes. This 771 registry is pre-provisioned with the values given in Section 5.5. 772 [TBD] 774 8. Acknowledgements 776 The authors would like to thank Paul Kyzviat and Dale Worley for 777 their input into this specification. 779 9. Informative References 781 [I-D.peterson-modern-problems] 782 Peterson, J. and T. McGarry, "Modern Problem Statement, 783 Use Cases, and Framework", draft-peterson-modern- 784 problems-01 (work in progress), July 2015. 786 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 787 Application and Support", STD 3, RFC 1123, 788 DOI 10.17487/RFC1123, October 1989, 789 . 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, 793 DOI 10.17487/RFC2119, March 1997, 794 . 796 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 797 A., Peterson, J., Sparks, R., Handley, M., and E. 798 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 799 DOI 10.17487/RFC3261, June 2002, 800 . 802 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 803 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 804 . 806 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 807 Extensions to the Session Initiation Protocol (SIP) for 808 Asserted Identity within Trusted Networks", RFC 3325, 809 DOI 10.17487/RFC3325, November 2002, 810 . 812 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 813 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 814 . 816 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 817 RFC 3966, DOI 10.17487/RFC3966, December 2004, 818 . 820 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 821 Resource Identifier (URI): Generic Syntax", STD 66, 822 RFC 3986, DOI 10.17487/RFC3986, January 2005, 823 . 825 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 826 Authenticated Identity Management in the Session 827 Initiation Protocol (SIP)", RFC 4474, 828 DOI 10.17487/RFC4474, August 2006, 829 . 831 [RFC4904] Gurbani, V. and C. Jennings, "Representing Trunk Groups in 832 tel/sip Uniform Resource Identifiers (URIs)", RFC 4904, 833 DOI 10.17487/RFC4904, June 2007, 834 . 836 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 837 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 838 2007, . 840 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 841 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 842 January 2008, . 844 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 845 Requirements", RFC 5067, DOI 10.17487/RFC5067, November 846 2007, . 848 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 849 for the Session Initiation Protocol (SIP) and the Real- 850 time Applications and Infrastructure Area", BCP 67, 851 RFC 5727, DOI 10.17487/RFC5727, March 2010, 852 . 854 [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., 855 "Essential Correction for IPv6 ABNF and URI Comparison in 856 RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, 857 . 859 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 860 Uniform Resource Identifiers (URI) Dynamic Delegation 861 Discovery System (DDDS) Application (ENUM)", RFC 6116, 862 DOI 10.17487/RFC6116, March 2011, 863 . 865 [RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for 866 Multimedia INTerconnect (SPEERMINT) Architecture", 867 RFC 6406, DOI 10.17487/RFC6406, November 2011, 868 . 870 [RFC6461] Channabasappa, S., Ed., "Data for Reachability of Inter- 871 /Intra-NetworK SIP (DRINKS) Use Cases and Protocol 872 Requirements", RFC 6461, DOI 10.17487/RFC6461, January 873 2012, . 875 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 876 of Named Entities (DANE) Transport Layer Security (TLS) 877 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 878 2012, . 880 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 881 "Architectural Considerations on Application Features in 882 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 883 . 885 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 886 DOI 10.17487/RFC7095, January 2014, 887 . 889 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 890 Telephone Identity Problem Statement and Requirements", 891 RFC 7340, DOI 10.17487/RFC7340, September 2014, 892 . 894 Author's Address 896 Jon Peterson 897 Neustar, Inc. 899 Email: jon.peterson@neustar.biz