idnits 2.17.1 draft-zhang-alto-multipart-01.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 296 has weird spacing: '...ceQuery reso...' -- The document date (December 11, 2018) is 1962 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: 'TBD' is mentioned on line 708, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-alto-cost-calendar-09 == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-15 == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-04 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-04 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG S. Chen 3 Internet-Draft J. Zhang 4 Intended status: Standards Track Tongji University 5 Expires: June 14, 2019 December 11, 2018 7 Multiple ALTO Resources Query Using Multipart Message 8 draft-zhang-alto-multipart-01 10 Abstract 12 Many ALTO use cases involve multiple ALTO information resources like 13 different network maps, cost maps and property maps to achieve their 14 own specific goals. To make the ALTO client query them one by one is 15 not only inefficient but also error-prone. The inconsistent 16 responses can be performed because of the unstable communication 17 environment, and finally conduct the unexpected traffic optimization. 18 Further more, some ALTO information resources may have correlation, 19 which means one's input parameters may depends on another one's 20 response. To address those issues, some advanced query schema is 21 required. This document proposes an ALTO extension to support the 22 multiple ALTO resources query in the single request using the HTTP 23 multipart message and the existing JSON query languages. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on June 14, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 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 . . . . . . . . . . . . . . 4 73 3.3. Path Vector Query . . . . . . . . . . . . . . . . . . . . 5 74 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 75 5. Overview of Approach . . . . . . . . . . . . . . . . . . . . 6 76 6. Multipart Query Resource . . . . . . . . . . . . . . . . . . 6 77 6.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 6 78 6.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 6 79 6.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 6 80 6.4. Accept Input Parameters . . . . . . . . . . . . . . . . . 7 81 6.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 6.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 8 83 7. Protocol Errors . . . . . . . . . . . . . . . . . . . . . . . 8 84 7.1. Partial Error . . . . . . . . . . . . . . . . . . . . . . 8 85 7.2. Entire Error . . . . . . . . . . . . . . . . . . . . . . 9 86 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 8.1. IRD Example . . . . . . . . . . . . . . . . . . . . . . . 9 88 8.2. Example 1: Simple Batch Query . . . . . . . . . . . . . . 11 89 8.3. Example 2: Properties Constrained Query . . . . . . . . . 12 90 8.4. Example 3: Path Vector Query . . . . . . . . . . . . . . 15 91 9. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 16 92 9.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 16 93 9.2. Compatibility with Existing Protocol Extensions . . . . . 17 94 9.3. Compatibility with New Communication Mechanism . . . . . 17 95 10. Misc Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 10.1. Support Incremental Update . . . . . . . . . . . . . . . 17 97 10.2. Anonymous Resources . . . . . . . . . . . . . . . . . . 17 98 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 99 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 100 12.1. application/alto-* Media Types . . . . . . . . . . . . . 18 101 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 102 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 14.1. Normative References . . . . . . . . . . . . . . . . . . 19 104 14.2. Informative References . . . . . . . . . . . . . . . . . 20 105 Appendix A. Figures . . . . . . . . . . . . . . . . . . . . . . 21 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 108 1. Introduction 110 Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] and 111 its extensions already define several types of information resources, 112 like Network Map, Cost Map and Property Map, to expose useful network 113 informations to applications. However, many applications do not only 114 use a single information resource to perform their traffic 115 optimization. Retrieving multiple ALTO information resources is very 116 common in many ALTO use cases. 118 Using the current ALTO framework defined in [RFC7285], the ALTO 119 client can only query multiple ALTO information resources one by one. 120 It is not only inefficient but also error-prone. Because of the 121 network delay between different requests and the frequent change of 122 ALTO information resources, the responses received by the ALTO client 123 may be inconsistent. 125 Further more, some ALTO information resources have known 126 dependencies, which means the ALTO client may need one's response to 127 decide another one's query input parameters. 129 To be summarized, we need the multipart query service for three 130 reasons: 132 o Clients may want to query multiple ALTO information resources in a 133 single request to reduce the time consumption. 135 o Clients may want to query multiple ALTO resources consistently, 136 which means the server should guarantee the responses of all 137 resources are generated at the same time. 139 o Some use cases need to query multiple ALTO resources with a joint 140 relationship. 142 This document defines a new ALTO services for: (1) querying multiple 143 ALTO resources in a single request/response, and (2) supporting 144 general-purpose JSON query languages to resolve the relational query. 146 2. Terminologies 148 2.1. Resource Query Entry 150 TBD. 152 2.2. Resource Response Entry 154 TBD. 156 2.3. Resource Response Entry Body 158 TBD. 160 3. Use Cases 162 The following use cases can benefit from the multipart query service. 164 3.1. Simple Batch Query 166 The simplest use case is to query a batch of ALTO resources in a 167 single request. 169 Although the ALTO client can perform ALTO requests for multiple 170 times, it is not only inefficient but also inconsistent. 172 For example, the ALTO server provides a network map resource A and a 173 dependent cost map resource B. Both resources may change frequently. 174 Assume the ALTO client queries the network map first, and it gets the 175 revision A1. When the client queries the cost map, the network map 176 may be already changed from A1 to A2, and the client receives cost 177 map B2 which depends on A2 not A1. So the responded cost map B2 is 178 not consistent with the previous network map A1. 180 This case requires the ALTO server to provide a way for the ALTO 181 client to query multiple ALTO resources in a single transaction. 183 3.2. Properties Constrained Query 185 Beyond the simple batch query, there are also some another use cases 186 requiring a new service for relational query. For example, Some 187 clients may need to query an endpoint property map first, and find 188 endpoints with some properties fitting some conditions. And then 189 they query the endpoint cost of these endpoints. 191 In this case, the endpoint cost query depends on the result of the 192 property map query. Although the ALTO client can cache the whole 193 property map in its local storage, it is still not efficient and may 194 conduct the consistency issue if the property map changes frequently. 195 So it requires a new service to provide multiple dependent resources 196 efficiently and consistently. 198 A general multipart query service benefits the ALTO client in two 199 aspects: 201 o It allows the ALTO client to specify the boolean test to reduce 202 the transmission of the useless data from the ALTO server. 204 o It compounds multiple ALTO information resources in a single 205 response to reduce the communication times. Thus, the 206 transmission latency can be reduced. 208 3.3. Path Vector Query 210 Another use case requiring the multiple resource query is the 211 relational query between the on-demand generated resources. A 212 straightforward example is the path vector query demonstrated in 213 [I-D.ietf-alto-path-vector]. 215 [I-D.ietf-alto-path-vector] introduces an extension of ALTO to 216 provide path vector information by cost map and unified property map 217 [I-D.ietf-alto-unified-props-new]. The client using path vector 218 extension will usually query cost map and a dynamically generated 219 property map sequentially. It is even hard to cache the full data of 220 resources, because both the cost map and the property map are on- 221 demand generated by the query input here. Thus, the only way to 222 reduce the time consumption is to compound the two resources. 224 4. Requirements 226 From the use cases described in Section 3, there are three additional 227 requirements for ALTO protocol: 229 MPQ-Req1: The ALTO protocol SHOULD allow the client to query 230 multiple ALTO resources in a single request, and return the result 231 in a single response. 233 It is the basic requirement to provide the query for the compound 234 resources. Even simple cases can benefit if this requirement is 235 realized. 237 MPQ-Req2: The ALTO protocol SHOULD provide general filter schema for 238 any ALTO resources. 240 Current filter schema in ALTO protocol only supports the simple 241 boolean test of numerical comparison. And the boolean filtered 242 query is only supported by the cost map and the endpoint cost 243 resource. It is not enough for the general cases. Even simple 244 property map may require more general filter schema. 246 MPQ-Req3: The ALTO protocol SHOULD support relational query for 247 mulitple joint resources. 249 Some ALTO resources are relational and cannot be used 250 individually. The path vector query is such an example. In these 251 use cases, the support of relational query for multiple joint 252 resources is very helpful. 254 5. Overview of Approach 256 This document uses two key techniques to realize the general multiple 257 resources query: 259 o Use Multipart message [RFC2046] to deliver compound resources. 261 o Accept JSON Query Language like XQuery [W3CXQUERY] and JSONiq 262 [JSONIQ] for general query process and relational joint query. 264 6. Multipart Query Resource 266 6.1. Media Type 268 "multipart/related" [RFC2387]. 270 6.2. HTTP Method 272 An ALTO Multipart Query resource is requested using the HTTP POST 273 method. 275 6.3. Capabilities 277 The capabilities are defined by an object of type 278 MultipartQueryCapabilities: 280 object { 281 JSONString query-langs<0..*>; 282 } MultipartQueryCapabilities; 284 where "query-langs" is an array of JSONString to indicate which query 285 languages are supported by this resource. 287 6.4. Accept Input Parameters 289 The input parameters for a Multipart Query request are supplied in 290 the entity body of the POST request. This document specifies the 291 input parameters with a data format indicated by the media type 292 "application/alto-multipartquery+alto", which is a JSON object of 293 type ReqMultipartQuery: 295 object { 296 ResourceQuery resources<1..*>; 297 [JsonString query-lang;] 298 } ReqMultipartQuery; 300 object { 301 JsonString resource-id; 302 [JsonValue input;] 303 } ResourceQuery; 305 with fields: 307 resources: List of ResourceQuery objects for which resources are to 308 be queried and how to query them. Each ResourceQuery object MUST 309 include the "resource-id" field to indicate which resource is to 310 be queried. If the queried resource requires the POST method, the 311 "input" field MUST be specified. The value of the "input" field 312 MUST be either a JSONString or a JSONObject. When its value is a 313 JSONObject, its format MUST be as the accept input parameters of 314 its resource. When its value is a JSONString, it MUST be a 315 program written in the query language specified by the "query- 316 lang" field. 318 query-lang: Optional. The value of the "query-lang" field MUST be 319 one of values in the "query-langs" capability. If this field is 320 not specified in the request, the ALTO client SHOULD NOT use any 321 query language in the "input" field. 323 6.5. Uses 325 An array with the resource ID(s) of resource(s) which this multipart 326 query resource can compound. The used resource can be any available 327 ALTO resources except for the multipart query resource. If the 328 "uses" field is not specified, all the available ALTO resources can 329 be queried except for the multipart query resource. 331 6.6. Response 333 The response of multipart query resource is a multipart message. 334 Each part of this multipart message is the response of a queried 335 resource in the request. 337 7. Protocol Errors 339 At the top level, the request of ALTO Multipart Query resource may 340 conduct two types of errors: Partial Error and Entire Error. 342 7.1. Partial Error 344 The Partial Error only occurs when the value of the "resource-id" 345 field or the "input" field is invalid. 347 When the Partial Error occurs, the ALTO server MUST still return the 348 response in the media type "multipart/related". For the resource 349 query entry with an error, the ALTO server MUST specify the "Content- 350 Type" of its resource response entry as "application/alto- 351 error+json", and include the ALTO error message in its resource 352 response entry body. For the resource query entry without any error, 353 the ALTO server MUST perform its query request normally. 355 The value of the "resource-id" field is invalid when this resource id 356 is not defined by the Information Resource Directory. In this case, 357 the ALTO server MUST return the E_INVALID_FIELD_VALUE error. 359 The validation of each "input" field of the multipart query input 360 parameters depends on the queried resource: 362 o If the "input" field of the multipart query input parameters is 363 neither a JSONObject nor a JSONString, the ALTO server SHOULD 364 return the E_INVALID_FIELD_TYPE error, unless a future protocol 365 extension supports the non-JSONObject input parameters. 367 o If the "input" field of the multipart query input parameters is a 368 JSONObject, the ALTO server MUST validate the value using its 369 queried resource and return the corresponding error if it has. 371 o If the "input" field of the multipart query input parameters is a 372 JSONString: 374 * If the "query-lang" is not specified, the ALTO server MUST 375 return the E_INVALID_FIELD_TYPE error. 377 * If the "query-lang" is specified, the ALTO server MUST execute 378 this JSONString as a program written in the "query-lang". If 379 the execution failed, the ALTO server MUST return the 380 E_INVALID_FIELD_VALUE error. If the execution succeed but the 381 result fails to pass the validation of the queried resource, 382 the ALTO server MUST return the E_INVALID_FIELD_VALUE error and 383 attach the error message returned by the queried resource into 384 the "message" field of the ALTO error message. 386 The syntax error is an Entire Error. 388 7.2. Entire Error 390 Any other invalid request will conduct the Entire Error. 392 When the Entire Error occurs, the ALTO server MUST return the error 393 response in the media type "application/alto-error+json" instead of 394 "multipart/related". The process of the Entire Error is as defined 395 in Section 8.5 of [RFC7285]. 397 8. Examples 399 8.1. IRD Example 401 Assume the root IRD is like the following: 403 { 404 "meta": { 405 "path-vector": { 406 "cost-mode": "array", 407 "cost-metric": "ane-path" 408 }, 409 "num-routingcost": { 410 "cost-mode": "numerical", 411 "cost-metric": "routingcost" 412 }, 413 "num-hopcount": { 414 "cost-mode": "numerical", 415 "cost-metric": "hopcount" 416 } 417 }, 418 "resources": { 419 "my-default-networkmap": { 420 "uri": "http://alto.example.com/networkmap", 421 "media-type": "application/alto-networkmap+json" 422 }, 423 "my-default-costmap": { 424 "uri": "http://alto.example.com/costmap", 425 "media-type": "application/alto-costmap+json", 426 "capabilities": { 427 "cost-type-names": [ "num-routingcost" ] 428 }, 429 "uses": [ "my-default-networkmap" ] 430 }, 431 "my-filtered-costmap": { 432 "uri": "http://alto.example.com/costmap/filtered", 433 "media-type": "application/alto-costmap+json", 434 "accepts": "application/alto-costmapfilter+json", 435 "capabilities": { 436 "cost-type-names": [ "num-hopcount" ] 437 }, 438 "uses": [ "my-default-networkmap" ] 439 }, 440 "endpoint-path-vector": { 441 "uri": "http://alto.exmaple.com/endpointcost", 442 "media-type": "application/alto-endpointcost+json", 443 "accepts": "application/alto-endpointcostparams+json", 444 "capabilities": { 445 "cost-constraints": true, 446 "cost-type-names": [ "path-vector" ], 447 }, 448 "property-map": "propmap-availbw" 449 }, 450 "propmap-availbw-delay": { 451 "uri": "http://alto.exmaple.com/propmap/availbw", 452 "media-type": "application/alto-propmap+json", 453 "accepts": "application/alto-propmapparams+json", 454 "capabilities": { 455 "domain-types": [ "ane" ], 456 "prop-types": [ "availbw" ] 457 } 458 }, 459 "propmap-location": { 460 "uri": "http://alto.exmaple.com/propmap/location", 461 "media-type": "application/alto-propmap+json", 462 "accepts": "application/alto-propmapparams+json", 463 "capabilities": { 464 "domain-types": [ "pid" ], 465 "prop-types": [ "country", "state" ] 466 } 467 }, 468 "multipart-query": { 469 "uri": "http://alto.example.com/multipart", 470 "media-type": "multipart/related", 471 "accepts": "application/alto-multipartquery+json", 472 "capabilities": { 473 "query-langs": [ "xquery", "jsoniq" ] 474 } 476 } 477 } 478 } 480 8.2. Example 1: Simple Batch Query 482 POST /multipart HTTP/1.1 483 Host: alto.example.com 484 Accept: multipart/related, application/alto-error+json 485 Content-Lenght: [TBD] 486 Content-Type: application/alto-multipartquery+json 488 { 489 "resources": [ 490 { 491 "resource-id": "my-default-networkmap" 492 }, 493 { 494 "resource-id": "my-default-costmap" 495 } 496 ] 497 } 499 HTTP/1.1 200 OK 500 Content-Lenght: [TBD] 501 Content-Type: multipart/related; boundary=simple-batch-query 503 --simple-batch-query 504 Content-Type: application/alto-networkmap+json 506 { 507 "meta": { 508 "vtag": { 509 "resource-id": "my-default-networkmap", 510 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 511 } 512 }, 513 "network-map": { 514 "PID1" : { 515 "ipv4" : [ 516 "192.0.2.0/24", 517 "198.51.100.0/25" 518 ] 519 }, 520 "PID2" : { 521 "ipv4" : [ 522 "198.51.100.128/25" 523 ] 525 }, 526 "PID3" : { 527 "ipv4" : [ 528 "0.0.0.0/0" 529 ], 530 "ipv6" : [ 531 "::/0" 532 ] 533 } 534 } 535 } 537 --simple-batch-query 538 Content-Type: application/alto-costmap+json 540 { 541 "meta": { 542 "dependent-vtags": [ 543 { 544 "resource-id": "my-default-networkmap", 545 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 546 } 547 ], 548 "cost-type": { 549 "cost-mode": "numerical", 550 "cost-metric": "routingcost" 551 } 552 }, 553 "cost-map": { 554 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 555 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 556 "PID3": { "PID1": 20, "PID2": 15 } 557 } 558 } 560 8.3. Example 2: Properties Constrained Query 562 NOTE: In this example, we use the "`" block to express the raw string 563 with unescaped characters like "\n" and "\"". It is not valid HTTP 564 body, but only used to better present. When the request is sent to 565 the ALTO server, the "`" block should be escaped. 567 POST /multipart HTTP/1.1 568 Host: alto.example.com 569 Accept: multipart/related, application/alto-error+json 570 Content-Lenght: [TBD] 571 Content-Type: application/alto-multipartquery+json 573 { 574 "query-lang": "jsoniq", 575 "resources": [ 576 { 577 "resource-id": "propmap-location" 578 }, 579 { 580 "resource-id": "my-default-costmap", 581 "input": ` 582 let $propmap := collection("propmap-location") 583 .("property-map") 584 return { 585 "cost-type": { 586 "cost-mode": "numerical", 587 "cost-metric": "hopcount" 588 }, 589 "pids": { 590 "srcs": [ 591 for $pid in keys($propmap) 592 where $propmap.$pid.country eq "US" 593 return substring-after($pid, "PID:") 594 ], 595 "dsts": [ 596 for $pid in keys($propmap) 597 where $propmap.$pid.country eq "CA" 598 return substring-after($pid, "PID:") 599 ] 600 } 601 } 602 ` 603 } 604 ] 605 } 607 HTTP/1.1 200 OK 608 Content-Lenght: [TBD] 609 Content-Type: multipart/related; boundary=prop-const-query 611 --prop-const-query 612 Content-Type: application/alto-propmap+json 614 { 615 "property-map": { 616 "pid:PID1": { 617 "country": "US", 618 "state": "CA" 619 }, 620 "pid:PID2": { 621 "country": "US", 622 "state": "CT" 623 }, 624 "pid:PID3": { 625 "country": "CA", 626 "state": "QC" 627 }, 628 "pid:PID4": { 629 "country": "CA", 630 "state": "NT" 631 }, 632 "pid:PID5": { 633 "country": "FR" 634 } 635 } 636 } 638 --prop-const-query 639 Content-Type: application/alto-costmap+json 641 { 642 "meta": { 643 "cost-type": { 644 "cost-mode": "numerical", 645 "cost-metric": "hopcount" 646 } 647 }, 648 "cost-map": { 649 "PID1": { 650 "PID3": 5, 651 "PID4": 7 652 }, 653 "PID2": { 654 "PID3": 8, 655 "PID4": 4 656 } 657 } 658 } 660 8.4. Example 3: Path Vector Query 662 POST /multipart HTTP/1.1 663 Host: alto.example.com 664 Accept: multipart/related, application/alto-error+json 665 Content-Lenght: [TBD] 666 Content-Type: application/alto-multipartquery+json 668 { 669 "query-lang": "jsoniq", 670 "resources": [ 671 { 672 "resource-id": "endpoint-path-vector", 673 "input": { 674 "cost-type": { 675 "cost-mode": "array", 676 "cost-metric": "ane-path" 677 }, 678 "endpoints": { 679 "srcs": [ "ipv4:192.0.2.2" ], 680 "dsts": [ "ipv4:192.0.2.89", 681 "ipv4:203.0.113.45" ] 682 } 683 } 684 }, 685 { 686 "resource-id": "propmap-availbw", 687 "input": ` 688 let $propmap := collection("endpiont-path-vector") 689 .("endpoint-cost-map") 690 return { 691 "entities": [ 692 distinct-values(flatten( 693 for $src in keys($propmap) 694 let $dsts := $propmap.$src 695 return flatten( 696 for $dst in keys($dsts) 697 return $dsts.$dst 698 ) 699 )) 700 ], 701 "properties": [ "availbw" ] 702 } 703 ` 704 } 705 ] 706 } 707 HTTP/1.1 200 OK 708 Content-Length: [TBD] 709 Content-Type: multipart/related; boundary=path-vector-query 711 --path-vector-query 712 Content-Type: application/alto-endpointcost+json 714 { 715 "meta": { 716 "cost-type": { 717 "cost-mode": "array", 718 "cost-metric": "ane-path" 719 } 720 }, 721 "endpoint-cost-map": { 722 "ipv4:192.0.2.2": { 723 "ipv4:192.0.2.89": [ "ane:L001", "ane:L003", "ane:L004" ], 724 "ipv4:203.0.113.45": [ "ane:L001", "ane:L004", "ane:L005" ], 725 "ipv6:2001:db8::10": [ "ane:L001", "ane:L005", "ane:L007" ] 726 } 727 } 728 } 730 --path-vector-query 731 Content-Type: application/alto-propmap+json 733 { 734 "property-map": { 735 "ane:L001": { "availbw": 50 }, 736 "ane:L003": { "availbw": 48 }, 737 "ane:L004": { "availbw": 55 }, 738 "ane:L005": { "availbw": 60 }, 739 "ane:L007": { "availbw": 35 } 740 } 741 } 743 9. Compatibility 745 9.1. Compatibility with Legacy ALTO Clients/Servers 747 The multipart query service is a new ALTO service using the new media 748 type. So the legacy ALTO client cannot identify this service from 749 the IRD of the ALTO server supporting it. And the legacy ALTO server 750 also cannot interpret the request of a multipart query service sent 751 by the ALTO client. 753 9.2. Compatibility with Existing Protocol Extensions 755 The multipart query service can use any ALTO resources exchanging 756 JSON data in request/response mechanism. So all the known ALTO 757 extensions like ALTO Calendar [I-D.ietf-alto-cost-calendar], Multi- 758 Cost [RFC8189] and the Path Vector [I-D.ietf-alto-path-vector] 759 extension, which does not change the request/response mechanism, are 760 compatible with the multipart query service. 762 9.3. Compatibility with New Communication Mechanism 764 Since the multipart query service use multipart messages as the 765 response instead of the JSON data, the incremental update service 766 defined in [I-D.ietf-alto-incr-update-sse] does not support it. If 767 the update service does not notify the incremental change to the ALTO 768 client but only notify the full replacement, it can still work. But 769 it is very inefficient. So an extension to integrate multipart query 770 and the incremental update smoothly is required. HTTP/2 may be a 771 candidate solution to this problem. 773 10. Misc Considerations 775 10.1. Support Incremental Update 777 Because the response body entry of the multipart query resource is 778 not a single JSON object, it may not be compatible with the current 779 incremental update representation used in 780 [I-D.ietf-alto-incr-update-sse]. 782 10.2. Anonymous Resources 784 Some use cases may need the server generates "anonymous" ALTO 785 resources for the on-demand information. The "anonymous" ALTO 786 resources usually cannot appear alone but need to bind with some 787 "non-anonymous" ALTO resources. 789 11. Security Considerations 791 Allow the ALTO clients to upload the query language script may not be 792 safe. The code injection and many potential attacks can be 793 conducted. The security issue should be discussed and considered. 795 To avoid the attacks like the code injection, this document 796 recommends the following approaches: 798 Database Isolation: Some clients may attempt to access the secure 799 database inside the server. Isolate the data into the different 800 databases can reduce the risk of the information leak. 802 Application Container Isolation: Attackers may inject harmful code 803 into the input query programs to attempt to access the system 804 control. To avoid this, each query process is recommended to be 805 isolated using the application container. 807 Resource Limit: Even attackers cannot get the permission to crack 808 the data or the system, they can still inject some heavy-load 809 programs to consume the server resources. Thus, limiting the 810 memory usage and execution time of each query process is highly 811 recommended. 813 12. IANA Considerations 815 12.1. application/alto-* Media Types 817 This document registers an additional ALTO media type, listed in 818 Table 1. 820 +-------------+--------------------------+---------------+ 821 | Type | Subtype | Specification | 822 +-------------+--------------------------+---------------+ 823 | application | alto-multipartquery+json | Section 6.4 | 824 +-------------+--------------------------+---------------+ 826 Table 1: Additional ALTO Media Type. 828 Type name: application 830 Subtype name: This document registers multiple subtypes, as listed 831 in Table 1. 833 Required parameters: n/a 835 Optional parameters: n/a 837 Encoding considerations: Encoding considerations are identical to 838 those specified for the "application/json" media type. See 839 [RFC8259]. 841 Security considerations: Security considerations related to the 842 generation and consumption of ALTO Protocol messages are discussed 843 in Section 15 of [RFC7285]. 845 Interoperability considerations: This document specifies formats of 846 conforming messages and the interpretation thereof. 848 Published specification: This document is the specification for 849 these media types; see Table 1 for the section documenting each 850 media type. 852 Applications that use this media type: ALTO servers and ALTO clients 853 either stand alone or are embedded within other applications. 855 Additional information: 857 Magic number(s): n/a 859 File extension(s): This document uses the mime type to refer to 860 protocol messages and thus does not require a file extension. 862 Macintosh file type code(s): n/a 864 Person & email address to contact for further information: See 865 Authors' Addresses section. 867 Intended usage: COMMON 869 Restrictions on usage: n/a 871 Author: See Authors' Addresses section. 873 Change controller: Internet Engineering Task Force 874 (mailto:iesg@ietf.org). 876 13. Acknowledgements 878 14. References 880 14.1. Normative References 882 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 883 Requirement Levels", BCP 14, RFC 2119, 884 DOI 10.17487/RFC2119, March 1997, 885 . 887 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 888 RFC 2387, DOI 10.17487/RFC2387, August 1998, 889 . 891 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 892 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 893 "Application-Layer Traffic Optimization (ALTO) Protocol", 894 RFC 7285, DOI 10.17487/RFC7285, September 2014, 895 . 897 14.2. Informative References 899 [I-D.ietf-alto-cost-calendar] 900 Randriamasy, S., Yang, Y., Wu, Q., Lingli, D., and N. 901 Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost- 902 calendar-09 (work in progress), November 2018. 904 [I-D.ietf-alto-incr-update-sse] 905 Roome, W., Yang, Y., and S. Chen, "ALTO Incremental 906 Updates Using Server-Sent Events (SSE)", draft-ietf-alto- 907 incr-update-sse-15 (work in progress), December 2018. 909 [I-D.ietf-alto-path-vector] 910 Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W., 911 Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path 912 Vector Cost Type", draft-ietf-alto-path-vector-04 (work in 913 progress), July 2018. 915 [I-D.ietf-alto-unified-props-new] 916 Roome, W., Chen, S., Randriamasy, S., Yang, Y., and J. 917 Zhang, "Unified Properties for the ALTO Protocol", draft- 918 ietf-alto-unified-props-new-04 (work in progress), June 919 2018. 921 [JSONIQ] Robie, J., Fourny, G., Brantner, M., Florescu, D., 922 Westmann, T., and M. Zaharioudakis, "JSONiq - the SQL of 923 NoSQL 1.0", JSONiq , 2015. 925 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 926 Extensions (MIME) Part Two: Media Types", RFC 2046, 927 DOI 10.17487/RFC2046, November 1996, 928 . 930 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 931 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 932 DOI 10.17487/RFC8189, October 2017, 933 . 935 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 936 Interchange Format", STD 90, RFC 8259, 937 DOI 10.17487/RFC8259, December 2017, 938 . 940 [W3CXQUERY] 941 Robie, J., Chamberlin, D., Dyck, M., and J. Snelson, 942 "XQuery 3.0: An XML query language", W3C Recommendation, 943 W3C, 2014. 945 Appendix A. Figures 947 TODO: Put additional figures here if we have. 949 Authors' Addresses 951 Shiwei Dawn Chen 952 Tongji University 953 4800 Cao'An Hwy 954 Shanghai 201804 955 China 957 Email: dawn_chen_f@hotmail.com 959 Jingxuan Jensen Zhang 960 Tongji University 961 4800 Cao'An Hwy 962 Shanghai 201804 963 China 965 Email: jingxuan.n.zhang@gmail.com