idnits 2.17.1 draft-zhang-alto-multipart-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 == Line 324 has weird spacing: '...ceQuery reso...' -- The document date (9 March 2020) is 1507 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 747, but not defined ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-21) exists of draft-ietf-alto-cost-calendar-19 == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-20 == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-09 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-10 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG J. Zhang 3 Internet-Draft Tongji University 4 Intended status: Standards Track Y.R. Yang 5 Expires: 10 September 2020 Yale University 6 9 March 2020 8 Multiple ALTO Resources Query Using Multipart Message 9 draft-zhang-alto-multipart-03 11 Abstract 13 Many ALTO use cases involve multiple ALTO information resources like 14 different network maps, cost maps and property maps to achieve their 15 own specific goals. To make the ALTO client query them one by one is 16 not only inefficient but also error-prone. The inconsistent 17 responses can be performed because of the unstable communication 18 environment, and finally conduct the unexpected traffic optimization. 19 Further more, some ALTO information resources may have correlation, 20 which means one's input parameters may depends on another one's 21 response. To address those issues, some advanced query schema is 22 required. This document proposes an ALTO extension to support the 23 multiple ALTO resources query in the single request using the HTTP 24 multipart message and the existing JSON query languages. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 10 September 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Resource Query Entry . . . . . . . . . . . . . . . . . . 4 68 2.2. Resource Response Entry . . . . . . . . . . . . . . . . . 4 69 2.3. Resource Response Entry Body . . . . . . . . . . . . . . 4 70 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Simple Batch Query . . . . . . . . . . . . . . . . . . . 4 72 3.2. Properties Constrained Query . . . . . . . . . . . . . . 5 73 3.3. Path Vector Query . . . . . . . . . . . . . . . . . . . . 5 74 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 75 5. Design Space of Multipart Resource in ALTO . . . . . . . . . 6 76 6. Multipart Query Resource . . . . . . . . . . . . . . . . . . 7 77 6.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 7 78 6.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 7 79 6.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 7 80 6.4. Accept Input Parameters . . . . . . . . . . . . . . . . . 7 81 6.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 6.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 8 83 7. Protocol Errors . . . . . . . . . . . . . . . . . . . . . . . 8 84 7.1. Partial Error . . . . . . . . . . . . . . . . . . . . . . 8 85 7.2. Entire Error . . . . . . . . . . . . . . . . . . . . . . 9 86 8. Incremental Update Integration . . . . . . . . . . . . . . . 9 87 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 9.1. IRD Example . . . . . . . . . . . . . . . . . . . . . . . 10 89 9.2. Example 1: Simple Batch Query . . . . . . . . . . . . . . 11 90 9.3. Example 2: Properties Constrained Query . . . . . . . . . 13 91 9.4. Example 3: Path Vector Query . . . . . . . . . . . . . . 15 92 10. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 17 93 10.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 17 94 10.2. Compatibility with Existing Protocol Extensions . . . . 18 95 11. Misc Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 11.1. Return ALTO Information Resources over HTTP/2 . . . . . 18 97 11.2. Support Incremental Update . . . . . . . . . . . . . . . 18 98 11.3. Anonymous Resources . . . . . . . . . . . . . . . . . . 19 99 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 100 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 101 13.1. application/alto-* Media Types . . . . . . . . . . . . . 19 102 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 103 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 15.1. Normative References . . . . . . . . . . . . . . . . . . 21 105 15.2. Informative References . . . . . . . . . . . . . . . . . 21 106 Appendix A. Figures . . . . . . . . . . . . . . . . . . . . . . 22 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 109 1. Introduction 111 Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] and 112 its extensions already define several types of information resources, 113 like Network Map, Cost Map and Property Map, to expose useful network 114 information to applications. However, many applications do not only 115 use a single information resource to perform their traffic 116 optimization. Retrieving multiple ALTO information resources is very 117 common in many ALTO use cases. 119 Using the current ALTO framework defined in [RFC7285], the ALTO 120 client can only query multiple ALTO information resources one by one. 121 It is not only inefficient but also error-prone. Because of the 122 network delay between different requests and the frequent change of 123 ALTO information resources, the responses received by the ALTO client 124 may be inconsistent. 126 Further more, some ALTO information resources have known 127 dependencies, which means the ALTO client may need one's response to 128 decide another one's query input parameters. 130 To be summarized, we need the multipart query service for three 131 reasons: 133 * Clients may want to query multiple ALTO information resources in a 134 single request to reduce the network latency. 136 * Clients may want to query multiple ALTO resources consistently, 137 which means the server should guarantee the responses of all 138 resources are generated at the same time. 140 * Some use cases need to query multiple ALTO resources with a joint 141 relationship. 143 This document defines a new ALTO services for: (1) querying multiple 144 ALTO resources in a single request/response, and (2) supporting 145 general-purpose JSON query languages to resolve the relational query. 147 2. Terminologies 149 Besides the terms defined in [RFC2045], [RFC2046], [RFC2387], and 150 [RFC7285], this document also uses the following additional terms: 152 2.1. Resource Query Entry 154 A Resource Query Entry indicates the ResoureQuery object (see 155 Section 6.4) for an individual resource in the accept input 156 parameters of the Multipart Query resource. 158 2.2. Resource Response Entry 160 A Resource Response Entry indicates the entry of an individual part 161 of the multipart response message, including the MIME headers and the 162 body content. 164 2.3. Resource Response Entry Body 166 A Resource Response Entry Body indicates the body content of a 167 Resource Response Entry. 169 3. Use Cases 171 The following use cases can benefit from the multipart query service. 173 3.1. Simple Batch Query 175 The simplest use case is to query a batch of ALTO resources in a 176 single request. 178 Although the ALTO client can perform ALTO requests for multiple 179 times, it is not only inefficient but also inconsistent. 181 For example, the ALTO server provides a network map resource A and a 182 dependent cost map resource B. Both resources may change frequently. 183 Assume the ALTO client queries the network map first, and it gets the 184 revision A1. When the client queries the cost map, the network map 185 may be already changed from A1 to A2, and the client receives cost 186 map B2 which depends on A2 not A1. So the responded cost map B2 is 187 not consistent with the previous network map A1. 189 This case requires the ALTO server to provide a way for the ALTO 190 client to query multiple ALTO resources in a single transaction. 192 3.2. Properties Constrained Query 194 Beyond the simple batch query, there are also some another use cases 195 requiring a new service for relational query. For example, Some 196 clients may need to query an endpoint property map first, and find 197 endpoints with some properties fitting some conditions. And then 198 they query the endpoint cost of these endpoints. 200 In this case, the endpoint cost query depends on the result of the 201 property map query. Although the ALTO client can cache the whole 202 property map in its local storage, it is still not efficient and may 203 conduct the consistency issue if the property map changes frequently. 204 So it requires a new service to provide multiple dependent resources 205 efficiently and consistently. 207 A general multipart query service benefits the ALTO client in two 208 aspects: 210 * It allows the ALTO client to specify the boolean test to reduce 211 the transmission of the useless data from the ALTO server. 213 * It compounds multiple ALTO information resources in a single 214 response to reduce the communication times. Thus, the 215 transmission latency can be reduced. 217 3.3. Path Vector Query 219 Another use case requiring the multiple resource query is the 220 relational query between the on-demand generated resources. A 221 straightforward example is the path vector query demonstrated in 222 [I-D.ietf-alto-path-vector]. 224 [I-D.ietf-alto-path-vector] introduces an extension of ALTO to 225 provide path vector information by cost map and unified property map 226 [I-D.ietf-alto-unified-props-new]. The client using path vector 227 extension will usually query cost map and a dynamically generated 228 property map sequentially. It is even hard to cache the full data of 229 resources, because both the cost map and the property map are on- 230 demand generated by the query input here. Thus, the only way to 231 reduce the time consumption is to compound the two resources. 233 4. Requirements 235 From the use cases described in Section 3, there are three additional 236 requirements for ALTO protocol: 238 MPQ-Req1: The ALTO protocol SHOULD allow the client to query 239 multiple ALTO resources in a single request, and return the result 240 in a single response. 242 It is the basic requirement to provide the query for the compound 243 resources. Even simple cases can benefit if this requirement is 244 realized. 246 MPQ-Req2: The ALTO protocol SHOULD provide general filter schema for 247 any ALTO resources. 249 Current filter schema in ALTO protocol only supports the simple 250 boolean test of numerical comparison. And the boolean filtered 251 query is only supported by the cost map and the endpoint cost 252 resource. It is not enough for the general cases. Even simple 253 property map may require more general filter schema. 255 MPQ-Req3: The ALTO protocol SHOULD support relational query for 256 mulitple joint resources. 258 Some ALTO resources are relational and cannot be used 259 individually. The path vector query is such an example. In these 260 use cases, the support of relational query for multiple joint 261 resources is very helpful. 263 5. Design Space of Multipart Resource in ALTO 265 This document discusses the solution of how to apply "multipart/*" 266 (see [RFC2045] and [RFC2046]) response to the ALTO protocol. 268 There are three cases applying Multipart response to ALTO: 270 Multipart Request and Multipart Response: In this case, an ALTO 271 client can start a single request using Multipart encoding to 272 query a batch of resources. 274 Single Request and Fixed-Layout Multipart Response: In this case, an 275 ALTO server receives a non-Multipart request, e.g., the filtered 276 costmap request or the endpoint cost request, but returns a 277 Multipart response. The ALTO server MUST export the layout of the 278 Multipart response in the IRD. A special example can be found in 279 [I-D.ietf-alto-path-vector]. 281 Single Request and Flexible-Layout Multipart Response: This case 282 extends the previous case to allows the Multipart response with 283 flexible layout. The ALTO server receives the unified query 284 request and generate the layout of the response based on the 285 request. The ALTO client can even use general-purpose query 286 language like XQuery [W3CXQUERY] and JSONiq [JSONIQ] for general 287 query process and relational joint query. 289 The application about Multipart request to the single object response 290 is out of the scope of this document. 292 6. Multipart Query Resource 294 6.1. Media Type 296 "multipart/related" [RFC2387]. 298 6.2. HTTP Method 300 An ALTO Multipart Query resource is requested using the HTTP POST 301 method. 303 6.3. Capabilities 305 The capabilities are defined by an object of type 306 MultipartQueryCapabilities: 308 object { 309 JSONString query-langs<0..*>; 310 } MultipartQueryCapabilities; 312 where "query-langs" is an array of JSONString to indicate which query 313 languages are supported by this resource. 315 6.4. Accept Input Parameters 317 The input parameters for a Multipart Query request are supplied in 318 the entity body of the POST request. This document specifies the 319 input parameters with a data format indicated by the media type 320 "application/alto-multipartquery+alto", which is a JSON object of 321 type ReqMultipartQuery: 323 object { 324 ResourceQuery resources<1..*>; 325 [JsonString query-lang;] 326 } ReqMultipartQuery; 328 object { 329 JsonString resource-id; 330 [JsonValue input;] 331 } ResourceQuery; 333 with fields: 335 resources: List of ResourceQuery objects for which resources are to 336 be queried and how to query them. Each ResourceQuery object MUST 337 include the "resource-id" field to indicate which resource is to 338 be queried. If the queried resource requires the POST method, the 339 "input" field MUST be specified. The value of the "input" field 340 MUST be either a JSONString or a JSONObject. When its value is a 341 JSONObject, its format MUST be as the accept input parameters of 342 its resource. When its value is a JSONString, it MUST be a 343 program written in the query language specified by the "query- 344 lang" field. 346 query-lang: Optional. The value of the "query-lang" field MUST be 347 one of values in the "query-langs" capability. If this field is 348 not specified in the request, the ALTO client SHOULD NOT use any 349 query language in the "input" field. 351 6.5. Uses 353 An array with the resource ID(s) of resource(s) which this multipart 354 query resource can compound. The used resource can be any available 355 ALTO resources except for the multipart query resource. If the 356 "uses" field is not specified, all the available ALTO resources can 357 be queried except for the multipart query resource. 359 6.6. Response 361 The response of multipart query resource is a multipart message. 362 Each part of this multipart message is the response of a queried 363 resource in the request. 365 7. Protocol Errors 367 At the top level, the request of ALTO Multipart Query resource may 368 conduct two types of errors: Partial Error and Entire Error. 370 7.1. Partial Error 372 The Partial Error only occurs when the value of the "resource-id" 373 field or the "input" field is invalid. 375 When the Partial Error occurs, the ALTO server MUST still return the 376 response in the media type "multipart/related". For the resource 377 query entry with an error, the ALTO server MUST specify the "Content- 378 Type" of its resource response entry as "application/alto- 379 error+json", and include the ALTO error message in its resource 380 response entry body. For the resource query entry without any error, 381 the ALTO server MUST perform its query request normally. 383 The value of the "resource-id" field is invalid when this resource id 384 is not defined by the Information Resource Directory. In this case, 385 the ALTO server MUST return the E_INVALID_FIELD_VALUE error. 387 The validation of each "input" field of the multipart query input 388 parameters depends on the queried resource: 390 * If the "input" field of the multipart query input parameters is 391 neither a JSONObject nor a JSONString, the ALTO server SHOULD 392 return the E_INVALID_FIELD_TYPE error, unless a future protocol 393 extension supports the non-JSONObject input parameters. 395 * If the "input" field of the multipart query input parameters is a 396 JSONObject, the ALTO server MUST validate the value using its 397 queried resource and return the corresponding error if it has. 399 * If the "input" field of the multipart query input parameters is a 400 JSONString: 402 - If the "query-lang" is not specified, the ALTO server MUST 403 return the E_INVALID_FIELD_TYPE error. 405 - If the "query-lang" is specified, the ALTO server MUST execute 406 this JSONString as a program written in the "query-lang". If 407 the execution failed, the ALTO server MUST return the 408 E_INVALID_FIELD_VALUE error. If the execution succeed but the 409 result fails to pass the validation of the queried resource, 410 the ALTO server MUST return the E_INVALID_FIELD_VALUE error and 411 attach the error message returned by the queried resource into 412 the "message" field of the ALTO error message. 414 The syntax error is an Entire Error. 416 7.2. Entire Error 418 Any other invalid request will conduct the Entire Error. 420 When the Entire Error occurs, the ALTO server MUST return the error 421 response in the media type "application/alto-error+json" instead of 422 "multipart/related". The process of the Entire Error is as defined 423 in Section 8.5 of [RFC7285]. 425 8. Incremental Update Integration 427 This document defines a compatible incremental update process for 428 Multipart Query resource with [I-D.ietf-alto-incr-update-sse]. 430 An ALTO server's IRD can export an Update Stream service defined in 431 [I-D.ietf-alto-incr-update-sse] including the Resource ID of a 432 Multipart Query resource in the "uses" field. When an ALTO client 433 subscribe the incremental update for this Multipart Query resource, 434 the ALTO server sends the whole Multipart response message back at 435 the first data update message. Then the ALTO server subscribe all 436 nodes in this multipart resource tree automatically. Once data 437 updated later, the ALTO server publishes the update for each node 438 individually. 440 9. Examples 442 9.1. IRD Example 444 Assume the root IRD is like the following: 446 { 447 "meta": { 448 "path-vector": { 449 "cost-mode": "array", 450 "cost-metric": "ane-path" 451 }, 452 "num-routingcost": { 453 "cost-mode": "numerical", 454 "cost-metric": "routingcost" 455 }, 456 "num-hopcount": { 457 "cost-mode": "numerical", 458 "cost-metric": "hopcount" 459 } 460 }, 461 "resources": { 462 "my-default-networkmap": { 463 "uri": "http://alto.example.com/networkmap", 464 "media-type": "application/alto-networkmap+json" 465 }, 466 "my-default-costmap": { 467 "uri": "http://alto.example.com/costmap", 468 "media-type": "application/alto-costmap+json", 469 "capabilities": { 470 "cost-type-names": [ "num-routingcost" ] 471 }, 472 "uses": [ "my-default-networkmap" ] 473 }, 474 "my-filtered-costmap": { 475 "uri": "http://alto.example.com/costmap/filtered", 476 "media-type": "application/alto-costmap+json", 477 "accepts": "application/alto-costmapfilter+json", 478 "capabilities": { 479 "cost-type-names": [ "num-hopcount" ] 480 }, 481 "uses": [ "my-default-networkmap" ] 482 }, 483 "endpoint-path-vector": { 484 "uri": "http://alto.exmaple.com/endpointcost", 485 "media-type": "application/alto-endpointcost+json", 486 "accepts": "application/alto-endpointcostparams+json", 487 "capabilities": { 488 "cost-constraints": true, 489 "cost-type-names": [ "path-vector" ], 490 }, 491 "property-map": "propmap-availbw" 492 }, 493 "propmap-availbw-delay": { 494 "uri": "http://alto.exmaple.com/propmap/availbw", 495 "media-type": "application/alto-propmap+json", 496 "accepts": "application/alto-propmapparams+json", 497 "capabilities": { 498 "domain-types": [ "ane" ], 499 "prop-types": [ "availbw" ] 500 } 501 }, 502 "propmap-location": { 503 "uri": "http://alto.exmaple.com/propmap/location", 504 "media-type": "application/alto-propmap+json", 505 "accepts": "application/alto-propmapparams+json", 506 "capabilities": { 507 "domain-types": [ "pid" ], 508 "prop-types": [ "country", "state" ] 509 } 510 }, 511 "multipart-query": { 512 "uri": "http://alto.example.com/multipart", 513 "media-type": "multipart/related", 514 "accepts": "application/alto-multipartquery+json", 515 "capabilities": { 516 "query-langs": [ "xquery", "jsoniq" ] 517 } 518 } 519 } 520 } 522 9.2. Example 1: Simple Batch Query 523 POST /multipart HTTP/1.1 524 Host: alto.example.com 525 Accept: multipart/related, application/alto-error+json 526 Content-Lenght: [TBD] 527 Content-Type: application/alto-multipartquery+json 529 { 530 "resources": [ 531 { 532 "resource-id": "my-default-networkmap" 533 }, 534 { 535 "resource-id": "my-default-costmap" 536 } 537 ] 538 } 540 HTTP/1.1 200 OK 541 Content-Lenght: [TBD] 542 Content-Type: multipart/related; boundary=simple-batch-query 544 --simple-batch-query 545 Content-Type: application/alto-networkmap+json 547 { 548 "meta": { 549 "vtag": { 550 "resource-id": "my-default-networkmap", 551 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 552 } 553 }, 554 "network-map": { 555 "PID1" : { 556 "ipv4" : [ 557 "192.0.2.0/24", 558 "198.51.100.0/25" 559 ] 560 }, 561 "PID2" : { 562 "ipv4" : [ 563 "198.51.100.128/25" 564 ] 565 }, 566 "PID3" : { 567 "ipv4" : [ 568 "0.0.0.0/0" 569 ], 570 "ipv6" : [ 571 "::/0" 572 ] 573 } 574 } 575 } 577 --simple-batch-query 578 Content-Type: application/alto-costmap+json 580 { 581 "meta": { 582 "dependent-vtags": [ 583 { 584 "resource-id": "my-default-networkmap", 585 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 586 } 587 ], 588 "cost-type": { 589 "cost-mode": "numerical", 590 "cost-metric": "routingcost" 591 } 592 }, 593 "cost-map": { 594 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 595 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 596 "PID3": { "PID1": 20, "PID2": 15 } 597 } 598 } 600 9.3. Example 2: Properties Constrained Query 602 NOTE: In this example, we use the "`" block to express the raw string 603 with unescaped characters like "\n" and "\"". It is not valid HTTP 604 body, but only used to better present. When the request is sent to 605 the ALTO server, the "`" block should be escaped. 607 POST /multipart HTTP/1.1 608 Host: alto.example.com 609 Accept: multipart/related, application/alto-error+json 610 Content-Lenght: [TBD] 611 Content-Type: application/alto-multipartquery+json 613 { 614 "query-lang": "jsoniq", 615 "resources": [ 616 { 617 "resource-id": "propmap-location" 618 }, 619 { 620 "resource-id": "my-default-costmap", 621 "input": ` 622 let $propmap := collection("propmap-location") 623 .("property-map") 624 return { 625 "cost-type": { 626 "cost-mode": "numerical", 627 "cost-metric": "hopcount" 628 }, 629 "pids": { 630 "srcs": [ 631 for $pid in keys($propmap) 632 where $propmap.$pid.country eq "US" 633 return substring-after($pid, "PID:") 634 ], 635 "dsts": [ 636 for $pid in keys($propmap) 637 where $propmap.$pid.country eq "CA" 638 return substring-after($pid, "PID:") 639 ] 640 } 641 } 642 ` 643 } 644 ] 645 } 647 HTTP/1.1 200 OK 648 Content-Lenght: [TBD] 649 Content-Type: multipart/related; boundary=prop-const-query 651 --prop-const-query 652 Content-Type: application/alto-propmap+json 654 { 655 "property-map": { 656 "pid:PID1": { 657 "country": "US", 658 "state": "CA" 659 }, 660 "pid:PID2": { 661 "country": "US", 662 "state": "CT" 663 }, 664 "pid:PID3": { 665 "country": "CA", 666 "state": "QC" 667 }, 668 "pid:PID4": { 669 "country": "CA", 670 "state": "NT" 671 }, 672 "pid:PID5": { 673 "country": "FR" 674 } 675 } 676 } 678 --prop-const-query 679 Content-Type: application/alto-costmap+json 681 { 682 "meta": { 683 "cost-type": { 684 "cost-mode": "numerical", 685 "cost-metric": "hopcount" 686 } 687 }, 688 "cost-map": { 689 "PID1": { 690 "PID3": 5, 691 "PID4": 7 692 }, 693 "PID2": { 694 "PID3": 8, 695 "PID4": 4 696 } 697 } 698 } 700 9.4. Example 3: Path Vector Query 701 POST /multipart HTTP/1.1 702 Host: alto.example.com 703 Accept: multipart/related, application/alto-error+json 704 Content-Lenght: [TBD] 705 Content-Type: application/alto-multipartquery+json 707 { 708 "query-lang": "jsoniq", 709 "resources": [ 710 { 711 "resource-id": "endpoint-path-vector", 712 "input": { 713 "cost-type": { 714 "cost-mode": "array", 715 "cost-metric": "ane-path" 716 }, 717 "endpoints": { 718 "srcs": [ "ipv4:192.0.2.2" ], 719 "dsts": [ "ipv4:192.0.2.89", 720 "ipv4:203.0.113.45" ] 721 } 722 } 723 }, 724 { 725 "resource-id": "propmap-availbw", 726 "input": ` 727 let $propmap := collection("endpiont-path-vector") 728 .("endpoint-cost-map") 729 return { 730 "entities": [ 731 distinct-values(flatten( 732 for $src in keys($propmap) 733 let $dsts := $propmap.$src 734 return flatten( 735 for $dst in keys($dsts) 736 return $dsts.$dst 737 ) 738 )) 739 ], 740 "properties": [ "availbw" ] 741 } 742 ` 743 } 744 ] 745 } 746 HTTP/1.1 200 OK 747 Content-Length: [TBD] 748 Content-Type: multipart/related; boundary=path-vector-query 750 --path-vector-query 751 Content-Type: application/alto-endpointcost+json 753 { 754 "meta": { 755 "cost-type": { 756 "cost-mode": "array", 757 "cost-metric": "ane-path" 758 } 759 }, 760 "endpoint-cost-map": { 761 "ipv4:192.0.2.2": { 762 "ipv4:192.0.2.89": [ "ane:L001", "ane:L003", "ane:L004" ], 763 "ipv4:203.0.113.45": [ "ane:L001", "ane:L004", "ane:L005" ], 764 "ipv6:2001:db8::10": [ "ane:L001", "ane:L005", "ane:L007" ] 765 } 766 } 767 } 769 --path-vector-query 770 Content-Type: application/alto-propmap+json 772 { 773 "property-map": { 774 "ane:L001": { "availbw": 50 }, 775 "ane:L003": { "availbw": 48 }, 776 "ane:L004": { "availbw": 55 }, 777 "ane:L005": { "availbw": 60 }, 778 "ane:L007": { "availbw": 35 } 779 } 780 } 782 10. Compatibility 784 10.1. Compatibility with Legacy ALTO Clients/Servers 786 The multipart query service is a new ALTO service using the new media 787 type. So the legacy ALTO client cannot identify this service from 788 the IRD of the ALTO server supporting it. And the legacy ALTO server 789 also cannot interpret the request of a multipart query service sent 790 by the ALTO client. 792 10.2. Compatibility with Existing Protocol Extensions 794 The multipart query service can use any ALTO resources exchanging 795 JSON data in request/response mechanism. So all the known ALTO 796 extensions like ALTO Calendar [I-D.ietf-alto-cost-calendar], Multi- 797 Cost [RFC8189] and the Path Vector [I-D.ietf-alto-path-vector] 798 extension, which does not change the request/response mechanism, are 799 compatible with the multipart query service. 801 11. Misc Considerations 803 11.1. Return ALTO Information Resources over HTTP/2 805 HTTP/2 [RFC7540] provides new features like streams and multiplexing 806 that can essentially improve the web interface communication latency. 807 As the deployment of HTTP/2, it is valuable to consider how to 808 transit the ALTO information resources over HTTP/2. 810 The multipart query service defined in this document includes two 811 parts: the multiple-resource query schema and the multipart response 812 schema. 814 By leveraging HTTP/2 multiplexing in the scope of this document, the 815 multipart response schema can be replaced with sending multiple 816 HTTP/2 streams using HTTP/2 server push. Each stream only needs to 817 include a single ALTO information resource. The benefit is that the 818 Server can include additional meta information in the HTTP HEADERS 819 frame of each stream. And the Client can parse each ALTO information 820 resource in parallel. 822 However, the multiple-resource query schema is required to be reused 823 to keep the consistent request semantics. The Server requires the 824 Client to send the multiple-resource query request in a single HTTP/2 825 stream. It will enforce the Server to generate the response to 826 different ALTO information resources based on the same database 827 snapshot. 829 11.2. Support Incremental Update 831 Because the response body entry of the multipart query resource is 832 not a single JSON object, it may not be compatible with the current 833 incremental update representation used in 834 [I-D.ietf-alto-incr-update-sse]. 836 11.3. Anonymous Resources 838 Some use cases may need the server generates "anonymous" ALTO 839 resources for the on-demand information. The "anonymous" ALTO 840 resources usually cannot appear alone but need to bind with some 841 "non-anonymous" ALTO resources. 843 12. Security Considerations 845 Allow the ALTO clients to upload the query language script may not be 846 safe. The code injection and many potential attacks can be 847 conducted. The security issue should be discussed and considered. 849 To avoid the attacks like the code injection, this document 850 recommends the following approaches: 852 Database Isolation: Some clients may attempt to access the secure 853 database inside the server. Isolate the data into the different 854 databases can reduce the risk of the information leak. 856 Application Container Isolation: Attackers may inject harmful code 857 into the input query programs to attempt to access the system 858 control. To avoid this, each query process is recommended to be 859 isolated using the application container. 861 Resource Limit: Even attackers cannot get the permission to crack 862 the data or the system, they can still inject some heavy-load 863 programs to consume the server resources. Thus, limiting the 864 memory usage and execution time of each query process is highly 865 recommended. 867 13. IANA Considerations 869 13.1. application/alto-* Media Types 871 This document registers an additional ALTO media type, listed in 872 Table 1. 874 +-------------+--------------------------+---------------+ 875 | Type | Subtype | Specification | 876 +=============+==========================+===============+ 877 | application | alto-multipartquery+json | Section 6.4 | 878 +-------------+--------------------------+---------------+ 880 Table 1: Additional ALTO Media Type. 882 Type name: application 883 Subtype name: This document registers multiple subtypes, as listed 884 in Table 1. 886 Required parameters: n/a 888 Optional parameters: n/a 890 Encoding considerations: Encoding considerations are identical to 891 those specified for the "application/json" media type. See 892 [RFC8259]. 894 Security considerations: Security considerations related to the 895 generation and consumption of ALTO Protocol messages are discussed 896 in Section 15 of [RFC7285]. 898 Interoperability considerations: This document specifies formats of 899 conforming messages and the interpretation thereof. 901 Published specification: This document is the specification for 902 these media types; see Table 1 for the section documenting each 903 media type. 905 Applications that use this media type: ALTO servers and ALTO clients 906 either stand alone or are embedded within other applications. 908 Additional information: Magic number(s): n/a 910 File extension(s): This document uses the 911 mime type to refer to protocol messages and thus does not 912 require a file extension. 914 Macintosh file type code(s): n/a 916 Person & email address to contact for further information: See 917 Authors' Addresses section. 919 Intended usage: COMMON 921 Restrictions on usage: n/a 923 Author: See Authors' Addresses section. 925 Change controller: Internet Engineering Task Force 926 (mailto:iesg@ietf.org). 928 14. Acknowledgements 930 15. References 932 15.1. Normative References 934 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 935 Extensions (MIME) Part One: Format of Internet Message 936 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 937 . 939 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 940 Extensions (MIME) Part Two: Media Types", RFC 2046, 941 DOI 10.17487/RFC2046, November 1996, 942 . 944 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 945 Requirement Levels", BCP 14, RFC 2119, 946 DOI 10.17487/RFC2119, March 1997, 947 . 949 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 950 RFC 2387, DOI 10.17487/RFC2387, August 1998, 951 . 953 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 954 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 955 "Application-Layer Traffic Optimization (ALTO) Protocol", 956 RFC 7285, DOI 10.17487/RFC7285, September 2014, 957 . 959 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 960 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 961 DOI 10.17487/RFC7540, May 2015, 962 . 964 15.2. Informative References 966 [I-D.ietf-alto-cost-calendar] 967 Randriamasy, S., Yang, Y., WU, Q., Lingli, D., and N. 968 Schwan, "Application-Layer Traffic Optimization (ALTO) 969 Cost Calendar", Work in Progress, Internet-Draft, draft- 970 ietf-alto-cost-calendar-19, 2 March 2020, 971 . 974 [I-D.ietf-alto-incr-update-sse] 975 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 976 Server-Sent Events (SSE)", Work in Progress, Internet- 977 Draft, draft-ietf-alto-incr-update-sse-20, 20 February 978 2020, . 981 [I-D.ietf-alto-path-vector] 982 Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang, 983 "ALTO Extension: Path Vector", Work in Progress, Internet- 984 Draft, draft-ietf-alto-path-vector-09, 3 November 2019, 985 . 988 [I-D.ietf-alto-unified-props-new] 989 Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. 990 Gao, "Unified Properties for the ALTO Protocol", Work in 991 Progress, Internet-Draft, draft-ietf-alto-unified-props- 992 new-10, 4 November 2019, . 995 [JSONIQ] Robie, J., Fourny, G., Brantner, M., Florescu, D., 996 Westmann, T., and M. Zaharioudakis, "JSONiq - the SQL of 997 NoSQL 1.0", JSONiq , 2015. 999 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1000 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 1001 DOI 10.17487/RFC8189, October 2017, 1002 . 1004 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1005 Interchange Format", STD 90, RFC 8259, 1006 DOI 10.17487/RFC8259, December 2017, 1007 . 1009 [W3CXQUERY] 1010 Robie, J., Chamberlin, D., Dyck, M., and J. Snelson, 1011 "XQuery 3.0: An XML query language", W3C Recommendation, 1012 W3C, 2014. 1014 Appendix A. Figures 1016 TODO: Put additional figures here if we have. 1018 Authors' Addresses 1020 Jingxuan Jensen Zhang 1021 Tongji University 1022 4800 Cao'An Hwy 1023 Shanghai 1024 201804 1025 China 1027 Email: jingxuan.n.zhang@gmail.com 1029 Yang Richard Yang 1030 Yale University 1031 51 Prospect Street 1032 New Haven, CT 1033 United States of America 1035 Email: yry@cs.yale.edu