idnits 2.17.1 draft-ietf-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 (June 29, 2018) is 2127 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 448, 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 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 1 error (**), 0 flaws (~~), 13 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 June 29, 2018 5 Expires: December 31, 2018 7 An Architecture and Information Model for Telephone-Related Information 8 (TeRI) 9 draft-ietf-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 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 https://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 December 31, 2018. 36 Copyright Notice 38 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Record Elements . . . . . . . . . . . . . . . . . . . . . 6 69 3.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 6 70 3.1.2. Authority . . . . . . . . . . . . . . . . . . . . . . 6 71 3.1.3. Access . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1.4. Subject . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1.5. Signature . . . . . . . . . . . . . . . . . . . . . . 6 74 3.1.6. Administrative Elements . . . . . . . . . . . . . . . 7 75 3.1.6.1. Contact . . . . . . . . . . . . . . . . . . . . . 7 76 3.1.7. Service Elements . . . . . . . . . . . . . . . . . . 7 77 3.1.7.1. Service . . . . . . . . . . . . . . . . . . . . . 7 78 3.1.7.1.1. Priority . . . . . . . . . . . . . . . . . . 7 79 3.1.7.1.2. Expiration . . . . . . . . . . . . . . . . . 7 80 3.2. Element Value Types . . . . . . . . . . . . . . . . . . . 8 81 3.2.1. Service Types . . . . . . . . . . . . . . . . . . . . 8 82 3.2.1.1. Telephone Number Type . . . . . . . . . . . . . . 8 83 3.2.1.1.1. TN Range Type . . . . . . . . . . . . . . . . 8 84 3.2.1.2. Domain Name Type . . . . . . . . . . . . . . . . 8 85 3.2.1.3. Uniform Resource Indicator (URI) Type . . . . . . 8 86 3.2.1.4. Internet Protocol (IP) Address Type . . . . . . . 9 87 3.2.1.5. Trunk Group Type . . . . . . . . . . . . . . . . 9 88 3.2.1.6. Service Provider Identifier (SPID) Type . . . . . 9 89 3.2.2. Public Key Type . . . . . . . . . . . . . . . . . . . 9 90 3.2.3. Contact Type . . . . . . . . . . . . . . . . . . . . 9 91 3.2.4. Access Type . . . . . . . . . . . . . . . . . . . . . 9 92 3.2.5. Expiry Type . . . . . . . . . . . . . . . . . . . . . 10 93 3.2.6. Priority Type . . . . . . . . . . . . . . . . . . . . 10 94 3.2.7. Record Identifier Type . . . . . . . . . . . . . . . 10 95 3.2.8. Signature . . . . . . . . . . . . . . . . . . . . . . 10 96 3.2.9. Extension Type . . . . . . . . . . . . . . . . . . . 10 97 4. Relationship to the MODERN Framework . . . . . . . . . . . . 10 98 5. TeRI Client-Server Operations . . . . . . . . . . . . . . . . 12 99 5.1. Elements Common to All Operations . . . . . . . . . . . . 13 100 5.1.1. Requests . . . . . . . . . . . . . . . . . . . . . . 13 101 5.1.1.1. Source . . . . . . . . . . . . . . . . . . . . . 14 102 5.1.1.1.1. Request Source . . . . . . . . . . . . . . . 14 103 5.1.1.1.2. Request Intermediary . . . . . . . . . . . . 14 104 5.1.1.2. Subject . . . . . . . . . . . . . . . . . . . . . 15 105 5.1.1.2.1. Request Restrictions . . . . . . . . . . . . 15 106 5.1.2. Responses . . . . . . . . . . . . . . . . . . . . . . 15 107 5.1.2.1. Response Code . . . . . . . . . . . . . . . . . . 15 108 5.2. The Acquisition Operation . . . . . . . . . . . . . . . . 15 109 5.3. The Management Operation . . . . . . . . . . . . . . . . 16 110 5.3.1. Service-to-Service Record Distribution . . . . . . . 17 111 5.4. The Retrieval Operation . . . . . . . . . . . . . . . . . 17 112 5.5. Common Restrictions . . . . . . . . . . . . . . . . . . . 17 113 5.5.1. Route Source . . . . . . . . . . . . . . . . . . . . 18 114 5.6. Implementing Operations . . . . . . . . . . . . . . . . . 18 115 5.6.1. Transport Independence . . . . . . . . . . . . . . . 18 116 5.6.2. Bindings . . . . . . . . . . . . . . . . . . . . . . 19 117 5.6.3. Encodings . . . . . . . . . . . . . . . . . . . . . . 20 118 5.6.4. Profiles and Extension Elements . . . . . . . . . . . 21 119 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 120 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 121 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 122 9. Informative References . . . . . . . . . . . . . . . . . . . 22 123 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 125 1. Terminology 127 In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 128 and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 129 This document also incorporates the terminology of the MODERN 130 Framework [I-D.ietf-modern-problem-framework]. 132 2. Motivation 134 Telephone numbers remain the worldwide standard identifier for 135 routing calls and text messages over the Public Switched Telephone 136 Network (PSTN). Increasingly, real-time communications is migrating 137 to the Internet, and bringing telephone numbers with it. As 138 identifiers, however, telephone numbers differ fundamentally from 139 those commonly used by Internet applications. Email, the web and 140 native Voice over IP (VoIP) systems such as SIP ([RFC3261]) use 141 identifiers that rely on the Domain Name System (DNS) to resolve a 142 domain portion of the identifier to a particular IP address; 143 commonly, Uniform Resource Indicators (URIs) with a user and host 144 component serve this purpose. SIP, for example, quickly developed a 145 convention for using a TEL URI in the user part of its URIs. To help 146 telephone numbers work similarly on the Internet, a number of efforts 147 have specified mechanisms to manage and retrieve information about 148 telephone numbers via network services. 150 The ENUM ([RFC6116]) effort originally specified a public DNS profile 151 for translating telephone numbers into URIs. Due to the difficulty 152 of coordinating the public administration of telephone numbers in the 153 DNS, this work transitioned to "infrastructure" ENUM ([RFC5067]), 154 which assumed private DNS implementations, each of which could give a 155 different answer to the same request to translate a telephone number 156 depending on who asked, or other internal factors. The framework of 157 the SPEERMINT working group ([RFC6406]), expanding on these 158 requirements, differentiated the mapping of a telephone number to a 159 target network (the "Look-up Function") from the mapping made by the 160 originating network to the proper next-hop to reach such a target 161 network (the "Location Routing Function"). To provision the data 162 associated with telephone numbers, the DRINKS working group 163 ([RFC6461]) designed systems for uploading back-end data to the 164 services that would answer ENUM queries. 166 None of the preceding efforts, however, encompassed the entire 167 lifecycle of a telephone number as an Internet identifier. They 168 focused largely on service data, on how to "resolve" a telephone 169 number to a location on the Internet, rather than on administrative 170 questions of how numbers are acquired, how the entities associated 171 with telephone numbers are authorized to provision data, and what 172 kinds of systems need to be in place to allow a diverse community of 173 devices, applications and users to rely on telephone numbers. Early 174 considerations were moreover based on overlapping, but not entirely 175 consistent, information models: intrinsic limitations in the DNS kept 176 the queries and responses of ENUM relatively simple, whereas the 177 DRINKS provisioning system considered a much richer syntax. 179 The need for solutions in this space is pressing, as many carriers 180 worldwide contemplate migrating their entire PSTN infrastructure onto 181 the Internet within the next decade. Further pressures come from 182 emerging Internet communications providers who never invested in PSTN 183 infrastructure in the first place, but want access to services 184 related to telephone numbers. This includes devices, services, and 185 applications on the Internet that make use of telephone numbers and 186 need to distribute and manage numbering inventory: for example, an 187 Internet-enabled PBX that might want to automate the process for 188 allowing new connected phones to acquire numbers and provision 189 contact information for their users. Ultimately, the resources 190 identified by telephone numbers must also be reachable on the 191 Internet, and different applications might want to use different 192 protocols to retrieve information about numbers. In some 193 environments, there are performance constraints that would require a 194 very lightweight binary protocol; in others, applications might 195 prefer human-readable markup languages suitable for interfacing with 196 existing APIs. The use cases associated with these functions are 197 detailed in [I-D.ietf-modern-problem-framework]. 199 Therefore, this document proposes a reconsideration of telephone 200 service and administration data on the Internet, based on an 201 information model that allows records associated with telephone 202 number to be created, modified and accessed through network 203 interfaces. This document specifies no particular syntax or encoding 204 for queries or responses, but instead describes an extensible 205 information model for the semantics of provisioning and querying 206 operations associated with a telephone number. 208 3. The Information Model 210 The fundamental building block of the TeRI model is the Record. A 211 Record is created by an Authority who has authority over a particular 212 telephone number or a set of numbers. There may be more than one 213 Authority who is authorized to create Records for a particular 214 telephone number, and a TeRI service may have multiple Records 215 corresponding to a single telephone number, including potentially 216 overlapping Records associated with a range of numbers that 217 encompasses a particular telephone number. Under various 218 circumstances detailed in Section 5, participants in the numbering 219 ecosystem may create, read, update, and modify Records. 221 Records contain Elements that hold data about the telephone number. 222 Elements in this information model have a Name, which may optionally 223 be associated with a Type and Value. Records are divided into two 224 broad categories: Administrative Records and Service Records. 225 Administrative Records hold data about how records have been 226 allocated that is typically generated by a Registrar or similar 227 entity that distributes numbers; they include information on the 228 administrative contacts for telephone numbers, and so on. Service 229 Records hold data required to initiate communication with the 230 resources reachable at a telephone number; these Records are 231 typically generated by an assignee or delegate such as a CSP. 233 The distinction between Administrative and Service Records exists 234 because different parties might only need acces to one sort of 235 information instead of another: moreover, some actors may be 236 authorized to view Service Records for a particular telephone number 237 but not Administrative Records, or vice versa. In practice, a Record 238 may contain both Administrative and Service Elements, but the 239 creators of Records may find it useful to keep the two types of 240 information separate. If a Record contains both Administrative and 241 Service Elements, it may be returned in a Retrieval Query for either, 242 provided the Client is authorized to receive the Elements within. 244 3.1. Record Elements 246 A Record is made up of Elements, which may contain Service or 247 Administrative Data. All Records can contain the following generic 248 Elements. 250 3.1.1. Identifier 252 Every Record has an Identifier, which is a globally unique identifier 253 of the Record. The Identifier will typically be created at the same 254 time as the Record itself, at a time when an assignment or delegation 255 has occurred (as described in [I-D.ietf-modern-problem-framework]). 257 3.1.2. Authority 259 Every Record contains an Authority Element indicating the source of 260 the data: either the entity that provisioned the data with the 261 Service, or the external source from which the Service collected the 262 data. The Authority element ideally gives a logical identity of the 263 source of the data. A public key value may also be associated with 264 an Authority element. 266 3.1.3. Access 268 Every Record contains an Access Element indicating the conditions 269 under which Retrieval Requests can acquire the Record. The Access 270 Element is set by the Authority generating the Record. 272 3.1.4. Subject 274 Every Record has a Subject. As TeRI Records concern telephone 275 numbers, the Subject of a Record is an array of either a telephone 276 number type or a telephone number range type. The simplest Record 277 Subject is an array with one element consisting of a single telephone 278 number. 280 3.1.5. Signature 282 Optionally, a Record contains a Signature element. The Signature 283 element contains a signature over the concatenation of the other 284 elements given the Record. Signatures are provided by the Authority 285 responsible for the Record. 287 [Syntax TBD] 289 3.1.6. Administrative Elements 291 Records that contain Administrative Elements are Administrative 292 Records. The baseline TeRI specification sets only one 293 Administrative Element, the Contact. 295 3.1.6.1. Contact 297 Every Administrative Record has at least one Contact. The Contact 298 contains administrative data about the assignee of the telephone 299 number, though additionally Contacts may contain information about 300 delegates (as defined in [I-D.ietf-modern-problem-framework]). 301 Typically, this information would be set by the Registrar; policies 302 outside the scope of this specification dictate the sorts of entities 303 that may be designated as Contacts in Records. 305 3.1.7. Service Elements 307 Records that contain a Service Element are Service Records. The most 308 important Service Element is simply called Service, and it contains 309 an identifier for a communications resource reachable through a 310 telephone number. More than one Service Element can appear in a 311 given Record. Other Service Elements may be defined by later 312 specifications. 314 3.1.7.1. Service 316 Records optionally have one or more Service entries. A Service may 317 be of any Service Type, as given in Section 3.2.1. Optionally, 318 subelements modify how a Service Element should be retained. 320 3.1.7.1.1. Priority 322 Optionally, a Service may specify a weighted Priority associated with 323 a Record. Priorities are between 0 and 1, with a value of 1 having 324 the highest priority. 326 3.1.7.1.2. Expiration 328 Optionally, a Service may specify an absolute time at which a Record 329 will no longer be valid, should a client or intermediary wish to 330 cache a Record. In the absence of an Expiration element, Records may 331 be cached for a maximum of twenty-four hours. 333 3.2. Element Value Types 335 The remainder of a Record is made up of Elements. Elements types are 336 specified in this section. Every Element Type has a Type Code. A 337 Type Code is used as a short form for the Element in a Record. 339 3.2.1. Service Types 341 3.2.1.1. Telephone Number Type 343 The telephone number type conforms to the telephone number syntax 344 given in [RFC3966] Section 3, in the ABNF for "telephone-subscriber." 346 Type Code: T 348 [TBD - need for subtying? E.164, Service Code, Short Code, Prefix, 349 Nationally-Specific and Unknown. ] 351 3.2.1.1.1. TN Range Type 353 The TN range type consists of a prefix of a telephone number (per 354 [RFC3966] "telephone-subscriber"), and is semantically equivalent to 355 all syntactically-valid telephone numbers below that prefix. For 356 example, in the North American Numbering plan, the prefix 157143454 357 would be equivalent to all numbers ranging from 15714345400 to 358 15714345499. 360 [TBD - identify alternative ways of specifying ranges, potentially as 361 separate element types] 363 Type Code: R 365 3.2.1.2. Domain Name Type 367 The domain name type conforms to the syntax of RFC1034 Section 3.5 368 and Section 2.1 of [RFC1123]. 370 Type Code: D 372 3.2.1.3. Uniform Resource Indicator (URI) Type 374 The Uniform Resource Indicator (URI) type conforms to the syntax for 375 URIs given in [RFC3986] (see Section 3). 377 Type Code: U 379 3.2.1.4. Internet Protocol (IP) Address Type 381 The IP Address type conforms to the ABNF syntax of either the 382 IPv4address given in RFC3986 (Appendix A) or the IPv6reference of 383 [RFC5954]. 385 Type Code: I 387 3.2.1.5. Trunk Group Type 389 The trunk group type conforms to the "trunk-group-label" ABNF given 390 in [RFC4904] (Section 5). 392 Type Code: G 394 3.2.1.6. Service Provider Identifier (SPID) Type 396 The SPID type consists of a four-digit number. 398 [TBD - introduce other elements for alternative SPID syntaxes] 400 Type Code: ? 402 3.2.2. Public Key Type 404 The Credential type consists of a public key [encoding TBD]. 406 Type Code: C 408 3.2.3. Contact Type 410 The contact type follows the conventions of jCard [RFC7095]. 412 Type Code: C 414 3.2.4. Access Type 416 The access type consists of a string, which is set to the values 417 "Public," "Semi-restricted" or "Restricted." If either "Semi- 418 restricted" or "Restricted" appears as the access type, the Element 419 will need to be accompanied by a Permissions Element. [TBD - work to 420 be done here] 422 Type Code: A 424 3.2.5. Expiry Type 426 The Expiry type is an absolute time conformant to the syntax of 427 [RFC3339]. 429 Type Code: E 431 3.2.6. Priority Type 433 The Priority type contains a number between 0 and 1, conforming to 434 the specification of the "q" parameter of the Contact header field in 435 [RFC3261]. 437 Type Code: P 439 3.2.7. Record Identifier Type 441 The Record Identifier Type consists of a unique identifier for a 442 record [format TBD]. 444 Type Code: U 446 3.2.8. Signature 448 [Syntax TBD] 450 Type Code: S 452 3.2.9. Extension Type 454 This code is reserved for future use. 456 Type Code: X 458 4. Relationship to the MODERN Framework 460 The MODERN Framework [I-D.ietf-modern-problem-framework] enumerates a 461 series of actors and use cases related to telephone number 462 administration on the Internet. In terms of actors, it details 463 interactions between Users, Communications Service Providers (CSPs), 464 Registries, Registrars, and Government Entities. These actors 465 acquire, manage, or retrieve telephone numbers, implementing various 466 interfaces in support of different use cases. Registries in MODERN 467 may be centralized or decentralized. The TeRI Operations discussed 468 in this document pertain largely to centralized Registries: the 469 creation and propagation of Records for decentralized Registries is 470 outside the scope of this document. For centralized Registries, 471 client-server operations are conducted to acquire, manage, and 472 retrieve telephone numbers with TeRI. Typically, Users, CSPs, and 473 Government Entities act as TeRI Clients, and CSPs, Registries, and 474 Registrars act as TeRI Services. 476 In the MODERN framework, the lifecycle of a number begins with a 477 Registry. Registrars acquire telephone numbers from Registries, and 478 make those numbers available for allocation. Thus, an Acquisition 479 Operation is used by a Registrar that acquires numbers from a 480 Registry, and this Request, if successful, will result in the 481 creation of a Record that is returned in the Response. That Record 482 renders the Registrar an Authority for the telephone numbers in 483 question, but that Record will contain exclusively Administrative 484 Data, with no Service Data. 486 In some cases, that Registrar will also fulfil the role of a CSP, and 487 as a CSP, it will allocate those numbers to Users and generate any 488 associated Records itself. Alternatively, a Registrar that does not 489 act as a CSP may in turn act as a TeRI Service to which CSPs, and 490 potentially Users, will send Acquisition Requests to acquire number 491 blocks or individual numbers. Through that process, CSPs and Users 492 can also become Authorities for telephone numbers. New Records 493 containing Administrative Data indicating the contact information and 494 so forth of the CSP or the User will be generated when that 495 allocation occurs; those Records will be stored at the Registrar. 496 The Registrar may also house a "glue" Record of Service Data that 497 indicates the servicing CSP for the telephone number, and in 498 particular the Retrieval interface of that CSP where Records with 499 further Service Data can be found. 501 The Authorities who create and propagate Records of Service Data are 502 typically CSPs and Users. Most commonly, CSPs will store these 503 Service Data Records, and make them accessible through a Retrieval 504 interface. CSPs may also propagate these Records to various external 505 directories; the signature of the CSP and expiry data in the Record 506 will prove its integrity and freshness to any relying party. It is 507 envisioned that multiple Authorities may create Records for different 508 services that are associated with a given telephone number. 510 Finally, CSPs and Users may query a Retrieval interface at a CSP to 511 acquire Records containing Service Data that will enable them to 512 route communications. The Retrieval interface will enable Clients to 513 ask for Records associated with particular services, though Retrieval 514 can present Clients with a number of service options. Entities may 515 also query the Retrieval Interface of Registrars to acquire 516 Administrative Data about a telephone number, though it is likely 517 that authorization policies will restrict access to that data. 518 Government Entities may have legal relationships with Registrars that 519 grant them authorization privileges with regard to Administrative 520 Data. 522 5. TeRI Client-Server Operations 524 In TeRI, Clients use Operations to acquire, manage, or retrieve 525 Records, which are typically stored at Services. Every Operation 526 consists of a Request and a Response. Requests may pass directly 527 from a Client to a Service, or they may pass through one or more 528 Request Intermediaries; Request Intermediaries can modify Requests 529 and Responses in transit. A Response will contain a Response Code 530 indicating the status of the requested Operation. Both Requests and 531 Responses can, in certain Operations, carry Records. TeRI does not 532 specify any specific data format or underlying protocol to 533 instantiate Requests, Responses, or Records: TeRI is an abstract 534 architecture that must be implemented with concrete bindings and 535 encodings (see Section 5.6). 537 The TeRI information model (see Section 3) specifies the baseline 538 contents of Records, though Records are designed to be extended by 539 future specifications for particular use cases or environments. 540 Records provide information related to telephone numbers; a Record 541 may apply to one telephone number, a block of numbers, or several 542 discrete blocks of numbers. There may be multiple Records stored at 543 a Service which cover a single telephone number: this may include 544 multiple Records that apply only to that one telephone number, which 545 probably have been provisioned by different Authorities, as well as 546 Records applying to a telephone number range which contains that one 547 telephone number. Authorities sign Records, and Clients typically 548 have a trust relationship with those Authorities. 550 The three TeRI Operations are as follows: 552 The Acquisition Operation enables a Client to request the 553 allocation of unallocated telephone numbers that are held by a 554 Service on behalf of an Authority. A Service makes an 555 authorization decision before allocating the telephone number(s) 556 in accordance with the policy of the Authority. One or more new 557 Records may be created as a result of a successful Acquisition 558 Operation, and the Service will pass any such Record(s) to the 559 acquiring Client as well as retaining them locally at the Service. 560 As a result of a successful Acquisition Operation, the 561 administrative entity operating the Client will typically become a 562 new Authority for the allocated telephone numbers. 564 The Management Operation enables a Client to push new values for a 565 Record to a Service. In the baseline Operation described in this 566 document, the Client pushes the entire value of the Record to the 567 Service. The Service then makes an authorization decision to 568 determine whether or not the Client is permitted to upload the 569 Record in question. The policy behind those authorization 570 decisions is outside the scope of this document, though at a high- 571 level, the Client must be an Authority for a telephone number in 572 order to publish and modify Records associated with that number. 573 However, outside of hierarchical Authorities, Clients will not be 574 able to modify or delete Records related to that number that have 575 been provisioned by other Authorities. 577 The Retrieval Operation enables a Client to request one or more 578 Records that are stored at a Service. Some Records may contain 579 public information, and some may contain information that requires 580 an authorization decision to be made before it is shared with a 581 Client. Note that Services may have trust relationships with 582 Request Intermediaries, and that the Response may depend on that 583 trust relationship rather than on the Service's trust relationship 584 with the Client. Although a Client acquires Records from a 585 Service, a Client need not have a trust relationship with it - 586 typically, the Client trusts the Record because it trusts the 587 Authority which signed the Record rather than the Service that 588 holds or delivers the Record. 590 All entities that act as TeRI Services will offer at least the 591 Management and Retrieval interfaces, and some will also offer the 592 Acquisition interface. All entities that act as TeRI Clients will 593 implement at least the Retrieval Operation; others may implement the 594 client side of one or both of the Management and Acquisition 595 Interfaces. 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 5.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 5.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 5.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 5.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 5.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 6. 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 5.6.1. 988 [TBD - more] 990 7. 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 8. Acknowledgements 1015 The authors would like to thank Chris Wendt, Paul Kyzviat and Dale 1016 Worley for their input into this specification. 1018 9. 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-04 (work in progress), March 2018. 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@team.neustar