idnits 2.17.1 draft-peterson-modern-teri-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (July 3, 2017) is 2489 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 582, but not defined == Missing Reference: 'TBD' is mentioned on line 1011, but not defined == Unused Reference: 'RFC3324' is defined on line 1041, but no explicit reference was found in the text == Unused Reference: 'RFC3325' is defined on line 1045, but no explicit reference was found in the text == Unused Reference: 'RFC4474' is defined on line 1064, but no explicit reference was found in the text == Unused Reference: 'RFC4916' is defined on line 1075, but no explicit reference was found in the text == Unused Reference: 'RFC5039' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RFC5727' is defined on line 1087, but no explicit reference was found in the text == Unused Reference: 'RFC6698' is defined on line 1114, but no explicit reference was found in the text == Unused Reference: 'RFC6950' is defined on line 1119, but no explicit reference was found in the text == Unused Reference: 'RFC7340' is defined on line 1128, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-modern-problem-framework-02 -- 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 July 3, 2017 5 Expires: January 4, 2018 7 An Architecture and Information Model for Telephone-Related Information 8 (TeRI) 9 draft-peterson-modern-teri-03 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 January 4, 2018. 36 Copyright Notice 38 Copyright (c) 2017 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 . . . . . . . . . . 7 69 4. The Information Model . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Record Elements . . . . . . . . . . . . . . . . . . . . . 9 71 4.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 9 72 4.1.2. Authority . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1.3. Access . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1.4. Subject . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1.5. Signature . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1.6. Administrative Elements . . . . . . . . . . . . . . . 10 77 4.1.6.1. Contact . . . . . . . . . . . . . . . . . . . . . 10 78 4.1.7. Service Elements . . . . . . . . . . . . . . . . . . 10 79 4.1.7.1. Service . . . . . . . . . . . . . . . . . . . . . 10 80 4.1.7.1.1. Priority . . . . . . . . . . . . . . . . . . 10 81 4.1.7.1.2. Expiration . . . . . . . . . . . . . . . . . 10 82 4.2. Element Value Types . . . . . . . . . . . . . . . . . . . 11 83 4.2.1. Service Types . . . . . . . . . . . . . . . . . . . . 11 84 4.2.1.1. Telephone Number Type . . . . . . . . . . . . . . 11 85 4.2.1.1.1. TN Range Type . . . . . . . . . . . . . . . . 11 86 4.2.1.2. Domain Name Type . . . . . . . . . . . . . . . . 11 87 4.2.1.3. Uniform Resource Indicator (URI) Type . . . . . . 11 88 4.2.1.4. Internet Protocol (IP) Address Type . . . . . . . 12 89 4.2.1.5. Trunk Group Type . . . . . . . . . . . . . . . . 12 90 4.2.1.6. Service Provider Identifier (SPID) Type . . . . . 12 91 4.2.2. Public Key Type . . . . . . . . . . . . . . . . . . . 12 92 4.2.3. Contact Type . . . . . . . . . . . . . . . . . . . . 12 93 4.2.4. Access Type . . . . . . . . . . . . . . . . . . . . . 12 94 4.2.5. Expiry Type . . . . . . . . . . . . . . . . . . . . . 13 95 4.2.6. Priority Type . . . . . . . . . . . . . . . . . . . . 13 96 4.2.7. Record Identifier Type . . . . . . . . . . . . . . . 13 97 4.2.8. Signature . . . . . . . . . . . . . . . . . . . . . . 13 98 4.2.9. Extension Type . . . . . . . . . . . . . . . . . . . 13 99 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 13 100 5.1. Elements Common to All Operations . . . . . . . . . . . . 13 101 5.1.1. Requests . . . . . . . . . . . . . . . . . . . . . . 14 102 5.1.1.1. Source . . . . . . . . . . . . . . . . . . . . . 14 103 5.1.1.1.1. Request Source . . . . . . . . . . . . . . . 14 104 5.1.1.1.2. Request Intermediary . . . . . . . . . . . . 14 105 5.1.1.2. Subject . . . . . . . . . . . . . . . . . . . . . 15 106 5.1.1.2.1. Request Restrictions . . . . . . . . . . . . 15 107 5.1.2. Responses . . . . . . . . . . . . . . . . . . . . . . 15 108 5.1.2.1. Response Code . . . . . . . . . . . . . . . . . . 15 109 5.2. The Acquisition Operation . . . . . . . . . . . . . . . . 16 110 5.3. The Management Operation . . . . . . . . . . . . . . . . 16 111 5.3.1. Service-to-Service Record Distribution . . . . . . . 17 112 5.4. The Retrieval Operation . . . . . . . . . . . . . . . . . 17 113 5.5. Common Restrictions . . . . . . . . . . . . . . . . . . . 17 114 5.5.1. Route Source . . . . . . . . . . . . . . . . . . . . 18 115 6. Implementing Operations . . . . . . . . . . . . . . . . . . . 18 116 6.1. Transport Independence . . . . . . . . . . . . . . . . . 19 117 6.2. Bindings . . . . . . . . . . . . . . . . . . . . . . . . 19 118 6.3. Encodings . . . . . . . . . . . . . . . . . . . . . . . . 20 119 6.4. Profiles and Extension Elements . . . . . . . . . . . . . 21 120 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 121 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 122 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 123 10. Informative References . . . . . . . . . . . . . . . . . . . 22 124 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 126 1. Terminology 128 In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 129 and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 130 This document also incorporates the terminology of the MODERN 131 Framework [I-D.ietf-modern-problem-framework]. 133 2. Motivation 135 Telephone numbers remain the worldwide standard identifier for 136 routing calls and text messages over the Public Switched Telephone 137 Network (PSTN). Increasingly, real-time communications is migrating 138 to the Internet, and bringing telephone numbers with it. As 139 identifiers, however, telephone numbers differ fundamentally from 140 those commonly used by Internet applications. Email, the web and 141 native Voice over IP (VoIP) systems such as SIP ([RFC3261]) use 142 identifiers that rely on the Domain Name System (DNS) to resolve a 143 domain portion of the identifier to a particular IP address; 144 commonly, Uniform Resource Indicators (URIs) with a user and host 145 component serve this purpose. To help telephone numbers work 146 similarly on the Internet, a number of efforts have specified 147 mechanisms to manage and retrieve information about telephone numbers 148 via network services. SIP, for example, quickly developed a 149 convention for using a TEL URI in the user part of its URIs. 151 The ENUM ([RFC6116]) effort originally specified a public DNS profile 152 for translating telephone numbers into URIs. Due to the difficulty 153 of coordinating the public administration of telephone numbers in the 154 DNS, this work transitioned to "infrastructure" ENUM ([RFC5067]), 155 which assumed private DNS implementations, each of which could give a 156 different answer to the same request to translate a telephone number 157 depending on who asked, or other internal factors. The framework of 158 the SPEERMINT working group ([RFC6406]), expanding on these 159 requirements, differentiated the mapping of a telephone number to a 160 target network (the "Look-up Function") from the mapping made by the 161 originating network to the proper next-hop to reach such a target 162 network (the "Location Routing Function"). To provision the data 163 associated with telephone numbers, the DRINKS working group 164 ([RFC6461]) designed systems for uploading back-end data to the 165 services that would answer ENUM queries. 167 None of the preceding efforts, however, encompassed the entire 168 lifecycle of a telephone number as an Internet identifier. They 169 focused largely on service data, on how to "resolve" a telephone 170 number to a location on the Internet, rather than on administrative 171 questions of how numbers are acquired, how the entities associated 172 with telephone numbers are authorized to provision data, and what 173 kinds of systems need to be in place to allow a diverse community of 174 devices, applications and users to rely on telephone numbers. Early 175 considerations were moreover based on overlapping, but not entirely 176 consistent, information models: intrinsic limitations in the DNS kept 177 the queries and responses of ENUM relatively simple, whereas the 178 DRINKS provisioning system considered a much richer syntax. 180 The need for solutions in this space is pressing, as many carriers 181 worldwide contemplate migrating their entire PSTN infrastructure onto 182 the Internet within the next decade. Further pressures come from 183 emerging Internet communications providers who never invested in PSTN 184 infrastructure in the first place, but want access to services 185 related to telephone numbers. This includes devices, services, and 186 applications on the Internet that make use of telephone numbers and 187 need to distribute and manage numbering inventory: for example, an 188 Internet-enabled PBX that might want to automate the process for 189 allowing new connected phones to acquire numbers and provision 190 contact information for their users. Ultimately, the resources 191 identified by telephone numbers must also be reachable on the 192 Internet, and different applications might want to use different 193 protocols to retrieve information about numbers. In some 194 environments, there are performance constraints that would require a 195 very lightweight binary protocol; in others, applications might 196 prefer human-readable markup languages suitable for interfacing with 197 existing APIs. The use cases associated with these functions are 198 detailed in [I-D.ietf-modern-problem-framework]. 200 Therefore, this document proposes a reconsideration of telephone 201 service and administration data on the Internet, based on an 202 information model that allows records associated with telephone 203 number to be created, modified and accessed through network 204 interfaces. This document specifies no particular syntax or encoding 205 for queries or responses, but instead describes an extensible 206 information model for the semantics of provisioning and querying 207 operations associated with a telephone number. 209 3. Overview of Operations 211 In TeRI, Clients use Operations to acquire, manage, or retrieve 212 Records, which are typically stored at Services. Every Operation 213 consists of a Request and a Response. Requests may pass directly 214 from a Client to a Service, or they may pass through one or more 215 Request Intermediaries; Request Intermediaries can modify Requests 216 and Responses in transit. A Response will contain a Response Code 217 indicating the status of the requested Operation. Both Requests and 218 Responses can, in certain Operations, carry Records. TeRI does not 219 specify any specific data format or underlying protocol to 220 instantiate Requests, Responses, or Records: TeRI is an abstract 221 architecture that must be implemented with concrete bindings and 222 encodings (see Section 6). 224 The TeRI information model (see Section 4) specifies the baseline 225 contents of Records, though Records are designed to be extended by 226 future specifications for particular use cases or environments. 227 Records provide information related to telephone numbers; a Record 228 may apply to one telephone number, a block of numbers, or several 229 discrete blocks of numbers. There may be multiple Records stored at 230 a Service which cover a single telephone number: this may include 231 multiple Records that apply only to that one telephone number, which 232 probably have been provisioned by different Authorities, as well as 233 Records applying to a telephone number range which contains that one 234 telephone number. Authorities sign Records, and Clients typically 235 have a trust relationship with those Authorities. 237 The three TeRI Operations are as follows: 239 The Acquisition Operation enables a Client to request the 240 allocation of unallocated telephone numbers that are held by a 241 Service on behalf of an Authority. A Service makes an 242 authorization decision before allocating the telephone number(s) 243 in accordance with the policy of the Authority. One or more new 244 Records may be created as a result of a successful Acquisition 245 Operation, and the Service will pass any such Record(s) to the 246 acquiring Client as well as retaining them locally at the Service. 247 As a result of a successful Acquisition Operation, the 248 administrative entity operating the Client will typically become a 249 new Authority for the allocated telephone numbers. 251 The Management Operation enables a Client to push new values for a 252 Record to a Service. In the baseline Operation described in this 253 document, the Client pushes the entire value of the Record to the 254 Service. The Service then makes an authorization decision to 255 determine whether or not the Client is permitted to upload the 256 Record in question. The policy behind those authorization 257 decisions is outside the scope of this document, though at a high- 258 level, the Client must be an Authority for a telephone number in 259 order to publish and modify Records associated with that number. 260 However, outside of hierarchical Authorities, Clients will not be 261 able to modify or delete Records related to that number that have 262 been provisioned by other Authorities. 264 The Retrieval Operation enables a Client to request one or more 265 Records that are stored at a Service. Some Records may contain 266 public information, and some may contain information that requires 267 an authorization decision to be made before it is shared with a 268 Client. Note that Services may have trust relationships with 269 Request Intermediaries, and that the Response may depend on that 270 trust relationship rather than on the Service's trust relationship 271 with the Client. Although a Client acquires Records from a 272 Service, a Client need not have a trust relationship with it - 273 typically, the Client trusts the Record because it trusts the 274 Authority which signed the Record rather than the Service that 275 holds or delivers the Record. 277 All entities that act as TeRI Services will offer at least the 278 Management and Retrieval interfaces, and some will also offer the 279 Acquisition interface. All entities that act as TeRI Clients will 280 implement at least the Retrieval Operation; others may implement the 281 client side of one or both of the Management and Acquisition 282 Interfaces. 284 3.1. Relationship to the MODERN Framework 286 The MODERN Framework [I-D.ietf-modern-problem-framework] enumerates a 287 series of actors and use cases related to telephone number 288 administration on the Internet. In terms of actors, it details 289 interactions between Users, Communications Service Providers (CSPs), 290 Registries, Registrars, and Government Entities. These actors 291 implement the interfaces and Operations of TeRI Clients or Services 292 in support of various use cases. Typically, Users, CSPs, and 293 Government Entities act as TeRI Clients, and CSPs, Registries, and 294 Registrars act as TeRI Services. 296 In the MODERN framework, the lifecycle of a number begins with a 297 Registry. Registrars acquire telephone numbers from Registries, and 298 make those numbers available for allocation. Thus, an Acquisition 299 Operation is used by a Registrar that acquires numbers from a 300 Registry, and this Request, if successful, will result in the 301 creation of a Record that is returned in the Response. That Record 302 renders the Registrar an Authority for the telephone numbers in 303 question, but that Record will contain exclusively Administrative 304 Data, with no Service Data. 306 In some cases, that Registrar will also fulfil the role of a CSP, and 307 as a CSP, it will allocate those numbers to Users and generate any 308 associated Records itself. Alternatively, a Registrar that does not 309 act as a CSP may in turn act as a TeRI Service to which CSPs, and 310 potentially Users, will send Acquisition Requests to acquire number 311 blocks or individual numbers. Through that process, CSPs and Users 312 can also become Authorities for telephone numbers. New Records 313 containing Administrative Data indicating the contact information and 314 so forth of the CSP or the User will be generated when that 315 allocation occurs; those Records will be stored at the Registrar. 316 The Registrar may also house a "glue" Record of Service Data that 317 indicates the servicing CSP for the telephone number, and in 318 particular the Retrieval interface of that CSP where Records with 319 further Service Data can be found. 321 The Authorities who create and propagate Records of Service Data are 322 typically CSPs and Users. Most commonly, CSPs will store these 323 Service Data Records, and make them accessible through a Retrieval 324 interface. CSPs may also propagate these Records to various external 325 directories; the signature of the CSP and expiry data in the Record 326 will prove its integrity and freshness to any relying party. It is 327 envisioned that multiple Authorities may create Records for different 328 services that are associated with a given telephone number. 330 Finally, CSPs and Users may query a Retrieval interface at a CSP to 331 acquire Records containing Service Data that will enable them to 332 route communications. The Retrieval interface will enable Clients to 333 ask for Records associated with particular services, though Retrieval 334 can present Clients with a number of service options. Entities may 335 also query the Retrieval Interface of Registrars to acquire 336 Administrative Data about a telephone number, though it is likely 337 that authorization policies will restrict access to that data. 338 Government Entities may have legal relationships with Registrars that 339 grant them authorization privileges with regard to Administrative 340 Data. 342 4. The Information Model 344 The fundamental building block of the TeRI model is the Record. A 345 Record is created by an Authority who has authority over a particular 346 telephone number or a set of numbers. There may be more than one 347 Authority who is authorized to create Records for a particular 348 telephone number, and a TeRI service may have multiple Records 349 corresponding to a single telephone number, including potentially 350 overlapping Records associated with a range of numbers that 351 encompasses a particular telephone number. Under various 352 circumstances detailed in Section 5, participants in the numbering 353 ecosystem may create, read, update, and modify Records. 355 Records contain Elements that hold data about the telephone number. 356 Elements in this information model have a Name, which may optionally 357 be associated with a Type and Value. Records are divided into two 358 broad categories: Administrative Records and Service Records. 359 Administrative Records hold data about how records have been 360 allocated that is typically generated by a Registrar or similar 361 entity that distributes numbers; they include information on the 362 administrative contacts for telephone numbers, and so on. Service 363 Records hold data required to initiate communication with the 364 resources reachable at a telephone number; these Records are 365 typically generated by an assignee or delegate such as a CSP. 367 The distinction between Administrative and Service Records exists so 368 that Clients performing Retrieval Queries can ask for one instead of 369 the other. Some Clients may be authorized to receive Service Records 370 for a particular telephone number but not Administrative Records, or 371 vice versa. In practice, a Record may contain both Administrative 372 and Service Elements, but the creators of Records may find it useful 373 to keep the two types of information separate. If a Record contains 374 both Administrative and Service Elements, it may be returned in a 375 Retrieval Query for either, provided the Client is authorized to 376 receive the Elements within. 378 4.1. Record Elements 380 A Record is made up of Elements, which may contain Service or 381 Administrative Data. All Records can contain the following generic 382 Elements. 384 4.1.1. Identifier 386 Every Record has an Identifier, which is a globally unique identifier 387 of the Record. The Identifier will typically be created at the same 388 time as the Record itself, at a time when an assignment or delegation 389 has occurred (as described in [I-D.ietf-modern-problem-framework]). 391 4.1.2. Authority 393 Every Record contains an Authority Element indicating the source of 394 the data: either the entity that provisioned the data with the 395 Service, or the external source from which the Service collected the 396 data. The Authority element ideally gives a logical identity of the 397 source of the data. A public key value may also be associated with 398 an Authority element. 400 4.1.3. Access 402 Every Record contains an Access Element indicating the conditions 403 under which Retrieval Requests can acquire the Record. The Access 404 Element is set by the Authority generating the Record. 406 4.1.4. Subject 408 Every Record has a Subject. As TeRI Records concern telephone 409 numbers, the Subject of a Record is an array of either a telephone 410 number type or a telephone number range type. The simplest Record 411 Subject is an array with one element consisting of a single telephone 412 number. 414 4.1.5. Signature 416 Optionally, a Record contains a Signature element. The Signature 417 element contains a signature over the concatenation of the other 418 elements given the Record. Signatures are provided by the Authority 419 responsible for the Record. 421 [Syntax TBD] 423 4.1.6. Administrative Elements 425 Records that contain Administrative Elements are Administrative 426 Records. The baseline TeRI specification sets only one 427 Administrative Element, the Contact. 429 4.1.6.1. Contact 431 Every Administrative Record has at least one Contact. The Contact 432 contains administrative data about the assignee of the telephone 433 number, though additionally Contacts may contain information about 434 delegates (as defined in [I-D.ietf-modern-problem-framework]). 435 Typically, this information would be set by the Registrar; policies 436 outside the scope of this specification dictate the sorts of entities 437 that may be designated as Contacts in Records. 439 4.1.7. Service Elements 441 Records that contain a Service Element are Service Records. The most 442 important Service Element is simply called Service, and it contains 443 an identifier for a communications resource reachable through a 444 telephone number. More than one Service Element can appear in a 445 given Record. Other Service Elements may be defined by later 446 specifications. 448 4.1.7.1. Service 450 Records optionally have one or more Service entries. A Service may 451 be of any Service Type, as given in Section 4.2.1. Optionally, 452 subelements modify how a Service Element should be retained. 454 4.1.7.1.1. Priority 456 Optionally, a Service may specify a weighted Priority associated with 457 a Record. Priorities are between 0 and 1, with a value of 1 having 458 the highest priority. 460 4.1.7.1.2. Expiration 462 Optionally, a Service may specify an absolute time at which a Record 463 will no longer be valid, should a client or intermediary wish to 464 cache a Record. In the absence of an Expiration element, Records may 465 be cached for a maximum of twenty-four hours. 467 4.2. Element Value Types 469 The remainder of a Record is made up of Elements. Elements types are 470 specified in this section. Every Element Type has a Type Code. A 471 Type Code is used as a short form for the Element in a Record. 473 4.2.1. Service Types 475 4.2.1.1. Telephone Number Type 477 The telephone number type conforms to the telephone number syntax 478 given in [RFC3966] Section 3, in the ABNF for "telephone-subscriber." 480 Type Code: T 482 [TBD - need for subtying? E.164, Service Code, Short Code, Prefix, 483 Nationally-Specific and Unknown. ] 485 4.2.1.1.1. TN Range Type 487 The TN range type consists of a prefix of a telephone number (per 488 [RFC3966] "telephone-subscriber"), and is semantically equivalent to 489 all syntactically-valid telephone numbers below that prefix. For 490 example, in the North American Numbering plan, the prefix 157143454 491 would be equivalent to all numbers ranging from 15714345400 to 492 15714345499. 494 [TBD - identify alternative ways of specifying ranges, potentially as 495 separate element types] 497 Type Code: R 499 4.2.1.2. Domain Name Type 501 The domain name type conforms to the syntax of RFC1034 Section 3.5 502 and Section 2.1 of [RFC1123]. 504 Type Code: D 506 4.2.1.3. Uniform Resource Indicator (URI) Type 508 The Uniform Resource Indicator (URI) type conforms to the syntax for 509 URIs given in [RFC3986] (see Section 3). 511 Type Code: U 513 4.2.1.4. Internet Protocol (IP) Address Type 515 The IP Address type conforms to the ABNF syntax of either the 516 IPv4address given in RFC3986 (Appendix A) or the IPv6reference of 517 [RFC5954]. 519 Type Code: I 521 4.2.1.5. Trunk Group Type 523 The trunk group type conforms to the "trunk-group-label" ABNF given 524 in [RFC4904] (Section 5). 526 Type Code: G 528 4.2.1.6. Service Provider Identifier (SPID) Type 530 The SPID type consists of a four-digit number. 532 [TBD - introduce other elements for alternative SPID syntaxes] 534 Type Code: ? 536 4.2.2. Public Key Type 538 The Credential type consists of a public key [encoding TBD]. 540 Type Code: C 542 4.2.3. Contact Type 544 The contact type follows the conventions of jCard [RFC7095]. 546 Type Code: C 548 4.2.4. Access Type 550 The access type consists of a string, which is set to the values 551 "Public," "Semi-restricted" or "Restricted." If either "Semi- 552 restricted" or "Restricted" appears as the access type, the Element 553 will need to be accompanied by a Permissions Element. [TBD - work to 554 be done here] 556 Type Code: A 558 4.2.5. Expiry Type 560 The Expiry type is an absolute time conformant to the syntax of 561 [RFC3339]. 563 Type Code: E 565 4.2.6. Priority Type 567 The Priority type contains a number between 0 and 1, conforming to 568 the specification of the "q" parameter of the Contact header field in 569 [RFC3261]. 571 Type Code: P 573 4.2.7. Record Identifier Type 575 The Record Identifier Type consists of a unique identifier for a 576 record [format TBD]. 578 Type Code: U 580 4.2.8. Signature 582 [Syntax TBD] 584 Type Code: S 586 4.2.9. Extension Type 588 This code is reserved for future use. 590 Type Code: X 592 5. Operations 594 In this section are detailed the three TeRI Operations: Acquisition, 595 Management, and Retrieval Operations. 597 5.1. Elements Common to All Operations 599 All Operations in the TeRI model consist of Requests and Responses. 600 A Request from a TeRI Client to a Service may attempt to create, 601 read, update, or delete TeRI Records. Requests may use Restrictions 602 to focus only on particular parts of a TeRI Record. A Response gives 603 the result of the Operation back to the Client, which may indicate 604 success of failure. 606 5.1.1. Requests 608 All TeRI Requests have a Source, a Subject, and optionally a set of 609 Restrictions which further specify the nature of the Request. Some 610 Requests will contain the Identifier of the Record they concern; 611 others will query for all Records matching a given Subject. 613 5.1.1.1. Source 615 The Source is a required element in all Requests. In this 616 specification, two categories of Sources are defined: Request Source 617 and Request Intermediary. At least one of these Sources must be 618 present in a Retrieval Request, and multiple Sources are permitted. 619 Responses do not contain a Source. 621 Future specifications may extend the set of Source types. 623 5.1.1.1.1. Request Source 625 Every Request generated by a Client has a Request Source, which 626 identifies the originator of the Request. This represents the 627 logical identity of the user or service provider who first sent the 628 Request, rather than the identity of any Intermediate entity. This 629 field is provided in the Source to authenticate the poser of the 630 Request, so that the Service can make any necessary authorization 631 decisions as it formulates a Response. 633 In some service deployments, an Intermediary may wish to mask the 634 Request's Source from a Service. The removal of the Request's Source 635 by an Intermediary is permitted by TeRI, but any Intermediary that 636 removes the Request Source must provide a Request Intermediary for 637 the Source element. 639 A Request Source element has a Type, which indicates how the logical 640 identity of the originator of the Request has been represented. The 641 Type field of the Request Source is extensible. Initial values 642 include a domain name, a URI and a telephone number. 644 The Type element of the Request Source is followed by a Value, which 645 contains the identity. The format of the identity is determined by 646 the Type. 648 5.1.1.1.2. Request Intermediary 650 Optionally, Requests may contain one or more Request Intermediary 651 elements in the Source. A Request Intermediary resides between the 652 originator of the Request (the Client) and the Service, where it may 653 aggregate queries, proxy them, transcode them, or provide any related 654 relay function to assist the delivery of Requests to the Service. 656 The Request Intermediary element, like the Request Source, contains 657 the logical identity of the service that relayed the Request. This 658 field is provided in the Source for those deployments in which the 659 Service makes an authorization decision based on the identity of the 660 Intermediary rather than a Request Source. 662 A Request Intermediary element has a Type, which indicates how the 663 logical identity of the Intermediary has been represented. The Type 664 element of the Request Intermediary is extensible. Initial values 665 include a domain name, an X.509 certificate subject, or a URI. 667 The Type of the Request Intermediary element is followed by a Value, 668 which contains the identity. The format of the identity is 669 determined by the Type. 671 5.1.1.2. Subject 673 All Requests have a Subject. The Subject identifies the resource 674 that the Request concerns. Responses only contain a Subject if the 675 Subject of the Response differs from that of the original Request, 676 which may occur when (for example) the Subject contains a broad 677 range, and the Service replies with a more narrow Subject. Future 678 specifications, including Profiles, may define alternative Subject 679 elements. 681 5.1.1.2.1. Request Restrictions 683 TeRI Request Restrictions consist of a Name with an optional Type and 684 an Optional Value. Most Restrictions are specific to the Operation. 686 5.1.2. Responses 688 All TeRI Responses will have a Responde Code, and may contain one or 689 more Records. 691 5.1.2.1. Response Code 693 All Responses contain a Response Code. 695 Response Codes defined by this document include: Success, Subject 696 Does Not Exist, Subject Conflict, No Suitable Records Exist for 697 Subject, Subject Syntax Error, No Suitable Records Exist for 698 Restriction, Unauthorized Source, Route Source Topology Unavailable. 700 [TBD] 702 5.2. The Acquisition Operation 704 An Acquisition Request has a Source and a Subject, and may have one 705 or more Restrictions. An Acquisition Response has a Response Code, 706 and will contain one Record if it is successful. 708 The Subject of an Acquisition Request always specifies a Telephone 709 Number Type or a Telephone Number Range Type. If the Subject 710 contains a particular telephone number, then the Acquisition Request 711 is a Request to acquire that particular telephone number. If it is a 712 range, the Acquisition Request should be considered to be for the 713 entire range, but future Restrictions defined for this the Request 714 might limit the scope of the resources requested. The Service will 715 determine whether or not the Client is authorized to acquire the 716 resources in question based on the Source of the Acquisition Request. 718 The Response to an Acquisition Request will contain a Success 719 Response Code if the resource can be allocated. The Subject of a 720 Success Response will always contain the Telephone Number Type or 721 Telephone Number Range that has been allocated. A successful 722 Acquisition Response must contain a Record with a Identifier Element; 723 that Record may also contain an Element containing tokens or other 724 material that the Client might use to acquire credentials from a 725 Credential Authority (see [I-D.ietf-modern-problem-framework]). By 726 default, this Record will contain only Administrative Elements, 727 without Service Elements. If a requested telephone number (or range) 728 is already allocated, or a telephone number in the specified range is 729 not available, then a Subject Conflict Response Code is returned. 731 5.3. The Management Operation 733 A Management Request comprises a Source, a Subject, and one or more 734 Records; it also may contain one or more Restrictions. A Management 735 Response contains a Response Code, and optionally may contain a 736 Record. 738 The Subject of a Management Request always specifies a Telephone 739 Number Type or a Telephone Number Range Type. In almost all 740 circumstances, however, the Service will locate that Record(s) that a 741 Management Request modifies through the Identifier Restriction on 742 each Record in the Management Request. 744 A Management Request contains at least one Record; it may contain 745 multiple Records. Each Record in the Management Request must contain 746 a Record Identifier Element which designates the Record that the 747 Client is requesting that the Service provision as or replace with 748 the Record included in the Management Request. The Service will 749 authorize whether or not the Client is authorized to modify the 750 Record in question via the Source of the Management Request. 752 The Management Operation not only provisions Records at a Service, 753 but also provisions at the Service any information needed by the 754 Service to make authorization and policy decisions when responding to 755 Retrieval Requests. This information is tied to the Access Element 756 of the Record. 758 5.3.1. Service-to-Service Record Distribution 760 TeRI Records contain the signature of the Authority who generated 761 them, and as such, a relying party trusts a Record based on that 762 signature rather than based on the Service from which a Record was 763 retrieved. This permits architectures that allow a Records to be 764 duplicated across a distributed Service. Distribution protocols are 765 left to future specifications. 767 5.4. The Retrieval Operation 769 Every Retrieval Request comprises a Source and a Subject, and may 770 have one or more Restrictions. A Retrieval Response has a Response 771 Code, optionally one or more Records, and optionally a Subject, if 772 the Subject differs from that of the Request. 774 Retrieval Requests optionally contain Restrictions; a Request with no 775 specified Restrictions requests that the Service return any Records 776 associated with the Subject. In a Request, the presence of one or 777 more Restrictions limits the scope of the Request to Records about 778 the Subject containing those Elements, or the Restrictions otherwise 779 qualify the Request. Typically a Restriction will specify a Service 780 or Service Type that the Client seeks Records for. 782 Successful Retrieval Responses always contain one or more Records; 783 unsuccessful Responses never contain Records. 785 5.5. Common Restrictions 787 Restrictions are broadly structured around Elements, typically the 788 Service, Contact, and Identifier Elements. A TeRI Request may 789 contain a Restriction based on any Element, be it a baseline Element 790 or a Service or Administrative Element, including Elements that are 791 defined in future specifications. Semantically, a Restriction may 792 target Records that contain a particular Element, or only Elements 793 with a particular subtype or even value. Multiple Restrictions may 794 appear in a Request, and Restrictions are always additive, which is 795 to say that Restriction always narrow then target of a Request. 797 Restrictions may either name a target Element, or both an Element and 798 a value. For example, a Management Request replacing an existing 799 Record must name as its target with a Restriction both the Identifier 800 Element and the value, which is the identifier for the Record. A 801 Retrieval Request for a particular Subject might restrict itself to 802 Service elements, or even Service elements that have a particular 803 subtype, such as a URI. 805 5.5.1. Route Source 807 Optionally, Retrieval Requests may contain a Route Source which 808 functions in much the same way as a Restriction. A Route Source 809 identifies a reference point in the network from which any Service 810 Elements in the response should be calculated. It therefore always 811 designates a network element, though depending on the circumstances, 812 it may be an endpoint, a gateway, a border device, or any other agent 813 that makes forwarding decisions for telephone calls and related 814 services. A Route Source is a subelement of the Source element. 816 A Route Source element has a Type, which indicates how the network 817 element has been represented. The Type field of the Request Source 818 is extensible. Initial values include a domain name, an IP address 819 or a trunk group. 821 The Type of the Route Source element is followed by a Value, which 822 designates the network element. The format of the identity is 823 determined by the Type. 825 6. Implementing Operations 827 This framework specifies an abstract Request/Response protocol that 828 enables a Client to send Requests to a Service about telephone 829 numbers or related telephone services. Requests may pass through one 830 or more Intermediaries on their way from a Client to a Service; for 831 example, through aggregators or service bureaus. A Client 832 establishes the Subject of a Request, and optionally includes one or 833 more Restrictions to focus the scope of the Request. When a Service 834 receives a Request, it performs any necessary authorization and 835 policy decisions based on the Source. If policy permits, the Service 836 generates a Response, which will consist of a Response Code and one 837 or more Records associated with the Subject. The Service then sends 838 the Response through the same path that the Request followed; 839 transactional identifiers set by the Client and Service correlate the 840 Request to the Response and assist any intermediary routing. 842 6.1. Transport Independence 844 The information model provided for Requests and Responses in this 845 framework is independent of any underlying transport or encoding. 846 Future specifications will define Bindings that specify particular 847 transports and Encodings for Requests and Responses. In some 848 deployment environments, for example, a binary encoding and 849 lightweight transport might be more appropriate than the use of a web 850 protocol. This specification provides a template of requirements 851 that must be addressed by any encoding scheme. 853 It is a design goal of this work that the semantics of Requests and 854 Responses survive interworking through translations from one encoding 855 to another; for example, when an Intermediary receives a binary 856 Request from a Client, it should be able to transcode it to an XML 857 format to send to a Service without discarding any of the original 858 semantics. 860 6.2. Bindings 862 A TeRI Binding is an underlying protocol that carries Requests and 863 Responses. Future specifications may define Bindings in accordance 864 with the procedures in the IANA Considerations sections of this 865 document. 867 By underlying protocol, this specification means both transport-layer 868 protocols as well as any application-layer protocols that the Binding 869 requires. Thus an example Binding might specify a combination of 870 TCP, TLS, HTTP and SOAP as the underlying transport for TeRI. 871 Alternatively, it might only specify a very lightweight underlying 872 protocol like UDP. A Binding may be specific to a particular 873 Encoding, or it may be independent of any Encoding. 875 Bindings must specify whether they are continuous, transactional or 876 non-transactional. A continuous Binding creates a persistent 877 connection between two TeRI entities over which many, potentially 878 unrelated, Requests and Responses might flow. Many Bindings defined 879 for use between an Intermediary and a Service will have this 880 property, as Intermediaries may aggregate on behalf of many Clients, 881 and opening a separate transport-layer connection for each new 882 Request would be inefficient. A transactional Binding creates a 883 temporary connection between two TeRI entities for the purpose of 884 fulfilling a single Request; any Responses to the Request will use 885 the same connection to return to the sender of the Request. Finally, 886 a non-transactional Binding does not rely on any sort of connection 887 semantics: the senders of Requests and Responses will always initiate 888 a new instance of the Binding to send a message. 890 This document makes no provision for discovering the Bindings 891 supported by a TeRI Client, Intermediary or Service. Intermediaries 892 may transcode between Bindings if necessary when acting to connect a 893 Client and a Service, especially if the Client and Service support no 894 Bindings in common. 896 A Binding specification must enumerate all categories of metadata 897 required to establish a connection using a Binding. For some 898 Bindings, this might comprise solely an IP address and a port; for 899 other Bindings, this might instead require higher-layer application 900 identifiers like a URI. This metadata includes any identifiers 901 necessary for correlating Requests to Responses in a continuous or 902 non-transactional Binding; any Encoding making use of these Bindings 903 must specify how it carries those elements. 905 Bindings must also describe the security services they make 906 available. Bindings must have a means of providing mutual 907 authentication, integrity and confidentiality between Clients, 908 Intermediaries and Services. If a Binding supports TLS, for example, 909 these features can be provided by using TLS in an appropriate 910 deployment environment. 912 6.3. Encodings 914 A TeRI Encoding specifies how the Request and Response are 915 constructed syntactically. An Encoding may be specific to a 916 particular Binding, or it may be specified independently of any 917 Binding. 919 An Encoding may define an object format; for example, an XML or JSON 920 object, described with any appropriate schemas, or an ABNF 921 description. An Encoding might alternatively specify a mapping of 922 the semantic elements of Requests and Responses on to the existing 923 fields of headers of a protocol, especially when that protocol has 924 been defined as an underlying protocol Binding. Encodings must also 925 define whether or not they provide a bundling feature that allows 926 multiple Requests to be carried within particular objects or 927 mappings. 929 Every Encoding must specify how each semantic Element Type of a 930 Request and Response will be represented. For all baseline TeRI 931 Restrictions and Element Types, the Encoding specifies whether values 932 will be text or binary, how they will be encoded. Many baseline 933 Element Types (such as telephone numbers) can appear in different 934 places in a TeRI message; Encodings need only specify these common 935 element types once. Due to the extensibility of TeRI, however, 936 future specifications might define Element Types that an Encoding 937 does not address. Profiles using those extensions and Encodings must 938 explain their interaction. 940 Encodings must also describe the security services they make 941 available. In particular, encodings must describe a means of 942 providing authentication of the Sources and Authorities of Requests 943 and Responses respectively, as well as an integrity check over 944 critical elements including the Subject of Requests and the Record of 945 Responses. 947 [TBD - we may define more about the computation of this signature, 948 including canonicalization of elements, in this framework, and make 949 it a requirement for encodings to support this mechanism] 951 6.4. Profiles and Extension Elements 953 For particular deployment environments, only one Binding, Encoding 954 and set of Restrictions or other extended elements may be meaningful. 955 Future specifications may therefore define TeRI Profiles, which 956 describe a particular deployment environment and the Binding, 957 Encoding and set of Elements and Restrictions it requires. 959 Profiles may encompass extensions to baseline TeRI, and any new 960 Elements or Restrictions necessary may be defined within the Profile. 961 It is not necessary for a TeRI Service to understand extension 962 Elements that appear in Records or as Restrictions in a Query: if a 963 Service receives a Query with a Restriction, it can search Records 964 with the target Subject for Elements matching the Restriction and 965 return only those that apply. As such there is no formal capability 966 negotiation for extensions in the TeRI model: a Record may contain 967 Elements beyond baseline TeRI that a particular Client does not 968 understand and must ignore; similarly, a Service may receive a Query 969 with a Restriction that applies to no Records collected at the 970 Service, in which case the Service returns a "No Suitable Records 971 Exist for Restriction" Response Code. 973 7. Security Considerations 975 The framework of this document differs from previous efforts to 976 manage telephone numbers on the Internet largely by offering a much 977 richer set of security services. In particular, it requires that 978 three entities be capable of authenticating themselves to one another 979 at the layer of a binding: Clients, Intermediaries and Services. It 980 furthermore requires object security at the encoding layer so that 981 Sources and Authorities can sign data in order to authenticate 982 Requests and Responses that may pass through Intermediaries, and 983 moreover so that Authorities can prove to Clients that their Records 984 are authoritative even when the Authority does not operate the 985 Service. The requirements that bindings and encodings must satisfy 986 to meet these security needs are specified in Section 6.1. 988 [TBD - more] 990 8. IANA Considerations 992 This specification defines several registries: A registry of 993 Elements, a registry of Element Types, and a registry of Response 994 Codes. 996 This document creates a registry of Elements for use with this 997 framework. This registry is extensible, with an IANA Registration 998 policy of Specification Required. Any new Element registered must 999 supply the name of the Element, the name of the parent Element in the 1000 information model, and a code point. [TBD] 1002 This specification pre-provisions the Element Types registry with the 1003 entries given in Section 6. These elements are indexed by their Type 1004 Code. This registry is extensible, with an IANA Registration policy 1005 of Specification Required. Any new Element Type registered must 1006 supply the name of the Element Type, the name of the parent element 1007 in the information model, and a Type Code. 1009 This document furthermore creates a registry of Response Codes. This 1010 registry is pre-provisioned with the values given in Section 5.5. 1011 [TBD] 1013 9. Acknowledgements 1015 The authors would like to thank Chris Wendt, Paul Kyzviat and Dale 1016 Worley for their input into this specification. 1018 10. Informative References 1020 [I-D.ietf-modern-problem-framework] 1021 Peterson, J. and T. McGarry, "Modern Problem Statement, 1022 Use Cases, and Framework", draft-ietf-modern-problem- 1023 framework-02 (work in progress), March 2017. 1025 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1026 Application and Support", STD 3, RFC 1123, 1027 DOI 10.17487/RFC1123, October 1989, 1028 . 1030 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1031 Requirement Levels", BCP 14, RFC 2119, 1032 DOI 10.17487/RFC2119, March 1997, 1033 . 1035 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1036 A., Peterson, J., Sparks, R., Handley, M., and E. 1037 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1038 DOI 10.17487/RFC3261, June 2002, 1039 . 1041 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 1042 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 1043 . 1045 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1046 Extensions to the Session Initiation Protocol (SIP) for 1047 Asserted Identity within Trusted Networks", RFC 3325, 1048 DOI 10.17487/RFC3325, November 2002, 1049 . 1051 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1052 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1053 . 1055 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1056 RFC 3966, DOI 10.17487/RFC3966, December 2004, 1057 . 1059 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1060 Resource Identifier (URI): Generic Syntax", STD 66, 1061 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1062 . 1064 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1065 Authenticated Identity Management in the Session 1066 Initiation Protocol (SIP)", RFC 4474, 1067 DOI 10.17487/RFC4474, August 2006, 1068 . 1070 [RFC4904] Gurbani, V. and C. Jennings, "Representing Trunk Groups in 1071 tel/sip Uniform Resource Identifiers (URIs)", RFC 4904, 1072 DOI 10.17487/RFC4904, June 2007, 1073 . 1075 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1076 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 1077 2007, . 1079 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 1080 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 1081 January 2008, . 1083 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 1084 Requirements", RFC 5067, DOI 10.17487/RFC5067, November 1085 2007, . 1087 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 1088 for the Session Initiation Protocol (SIP) and the Real- 1089 time Applications and Infrastructure Area", BCP 67, 1090 RFC 5727, DOI 10.17487/RFC5727, March 2010, 1091 . 1093 [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., 1094 "Essential Correction for IPv6 ABNF and URI Comparison in 1095 RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, 1096 . 1098 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1099 Uniform Resource Identifiers (URI) Dynamic Delegation 1100 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1101 DOI 10.17487/RFC6116, March 2011, 1102 . 1104 [RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for 1105 Multimedia INTerconnect (SPEERMINT) Architecture", 1106 RFC 6406, DOI 10.17487/RFC6406, November 2011, 1107 . 1109 [RFC6461] Channabasappa, S., Ed., "Data for Reachability of Inter- 1110 /Intra-NetworK SIP (DRINKS) Use Cases and Protocol 1111 Requirements", RFC 6461, DOI 10.17487/RFC6461, January 1112 2012, . 1114 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1115 of Named Entities (DANE) Transport Layer Security (TLS) 1116 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1117 2012, . 1119 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 1120 "Architectural Considerations on Application Features in 1121 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 1122 . 1124 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 1125 DOI 10.17487/RFC7095, January 2014, 1126 . 1128 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1129 Telephone Identity Problem Statement and Requirements", 1130 RFC 7340, DOI 10.17487/RFC7340, September 2014, 1131 . 1133 Author's Address 1135 Jon Peterson 1136 Neustar, Inc. 1138 Email: jon.peterson@neustar.biz