idnits 2.17.1 draft-zhang-alto-multipart-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 281 has weird spacing: '...ceQuery reso...' -- The document date (July 02, 2018) is 2124 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 661, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-alto-cost-calendar-06 == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-11 == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-03 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-04 -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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: January 3, 2019 July 02, 2018 7 Multiple ALTO Resources Query Using Multipart Message 8 draft-zhang-alto-multipart-00 10 Abstract 12 Many ALTO use cases involve multiple ALTO information resources like 13 network map, cost map and property map to achieve their own goal. To 14 make the ALTO client query them one by one is not only inefficient 15 but also possible to introduce inconsistent issues. Further more, 16 some ALTO information resources may have correlation, which means 17 one's input parameters may depends on another one's response. So 18 some advanced query schema is required. This document proposes an 19 extension to support the multiple ALTO resources query with HTTP 20 multipart message and the existing JSON query languages. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 3, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Simple Batch Query . . . . . . . . . . . . . . . . . . . 4 62 3.2. Properties Constrained Query . . . . . . . . . . . . . . 4 63 3.3. Path Vector Query . . . . . . . . . . . . . . . . . . . . 5 64 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Overview of Approach . . . . . . . . . . . . . . . . . . . . 6 66 6. Multipart Query Resource . . . . . . . . . . . . . . . . . . 6 67 6.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 6 69 6.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 6 70 6.4. Accept Input Parameters . . . . . . . . . . . . . . . . . 6 71 6.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 7 73 7. Protocol Errors . . . . . . . . . . . . . . . . . . . . . . . 7 74 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8.1. IRD Example . . . . . . . . . . . . . . . . . . . . . . . 8 76 8.2. Example 1: Simple Batch Query . . . . . . . . . . . . . . 10 77 8.3. Example 2: Properties Constrained Query . . . . . . . . . 11 78 8.4. Example 3: Path Vector Query . . . . . . . . . . . . . . 14 79 9. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 15 80 9.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 15 81 9.2. Compatibility with Existing Protocol Extensions . . . . . 16 82 9.3. Compatibility with New Communication Mechanism . . . . . 16 83 10. Misc Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 10.1. Support Incremental Update . . . . . . . . . . . . . . . 16 85 10.2. Anonymous Resources . . . . . . . . . . . . . . . . . . 16 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 12.1. application/alto-* Media Types . . . . . . . . . . . . . 16 89 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 90 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 92 14.2. Informative References . . . . . . . . . . . . . . . . . 18 93 Appendix A. Figures . . . . . . . . . . . . . . . . . . . . . . 19 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 96 1. Introduction 98 1.1. Background 100 Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] and 101 its extensions already define several kinds of information resources, 102 like network map, cost map, property map, to expose useful network 103 informations to applications. However, many applications cannot only 104 use a single information resource to achieve their optimization goal. 105 Retrieving multiple ALTO information resources is very common in many 106 ALTO use cases. 108 Although the ALTO client can query multiple ALTO information 109 resources one by one, it is not inefficient. And because the network 110 delay between different requests and the frequent change of ALTO 111 information resources, the responses may be inconsistent. 113 Further more, some ALTO information resources have known 114 dependencies, which means the ALTO client may need one's response to 115 decide another one's query input parameters. 117 To be summarized, we need the multipart query service for three 118 reasons: 120 o Clients may want to query multiple ALTO information resources in a 121 single request to reduce the time consumption. 123 o Clients may want to query multiple ALTO resources consistently, 124 which means the server should guarantee the responses of all 125 resources are generated at the same time. 127 o Some use cases need to query multiple ALTO resources with a joint 128 relationship. 130 This document defines a new ALTO services for: (1) querying multiple 131 ALTO resources in a single request/response, and (2) supporting 132 general-purpose JSON query languages to resolve the relational query. 134 1.2. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 2. Terminologies 142 TBD. 144 3. Use Cases 146 We take the following potential use cases which may benefit from the 147 multipart query service. 149 3.1. Simple Batch Query 151 The simplest use case is to query a batch of ALTO resources in a 152 single request. 154 Although the ALTO client can perform ALTO requests for multiple 155 times, it is not only inefficient but also inconsistent. 157 For example, the ALTO server provides a network map resource A and a 158 dependent cost map resource B. Both resources may change frequently. 159 Assume the ALTO client queries the network map first, and it gets the 160 revision A1. When the client queries the cost map, the network map 161 may be already changed from A1 to A2, and the client receives cost 162 map B2 which depends on A2 not A1. So the responded cost map B2 is 163 not consistent with the previous network map A1. 165 This case requires the ALTO server to provide a way for the ALTO 166 client to query multiple ALTO resources in a single transaction. 168 3.2. Properties Constrained Query 170 Beyond the simple batch query, there are also some another use cases 171 requiring a new service for relational query. For example, Some 172 clients may need to query an endpoint property map first, and find 173 endpoints with some properties fitting some conditions. And then 174 they query the endpoint cost of these endpoints. 176 In this case, the endpoint cost query depends on the result of the 177 property map query. Although the ALTO client can cache the whole 178 property map in its local storage, it is still not efficient and may 179 conduct the consistency issue if the property map changes frequently. 180 So it requires a new service to provide multiple dependent resources 181 efficiently and consistently. 183 A general multipart query service benefits the ALTO client in two 184 aspects: 186 o It allows the ALTO client to specify the boolean test to reduce 187 the transmission of the useless data from the ALTO server. 189 o It compounds multiple ALTO information resources in a single 190 response to reduce the communication times. Thus, the 191 transmission latency can be reduced. 193 3.3. Path Vector Query 195 Another use case requiring the multiple resource query is the 196 relational query between the on-demand generated resources. A 197 straightforward example is the path vector query demonstrated in 198 [I-D.ietf-alto-path-vector]. 200 [I-D.ietf-alto-path-vector] introduces an extension of ALTO to 201 provide path vector information by cost map and unified property map 202 [I-D.ietf-alto-unified-props-new]. The client using path vector 203 extension will usually query cost map and a dynamically generated 204 property map sequentially. It is even hard to cache the full data of 205 resources, because both the cost map and the property map are on- 206 demand generated by the query input here. Thus, the only way to 207 reduce the time consumption is to compound the two resources. 209 4. Requirements 211 From the use cases described in Section 3, there are three additional 212 requirements for ALTO protocol: 214 MPQ-Req1: The ALTO protocol SHOULD allow the client to query 215 multiple ALTO resources in a single request, and return the result 216 in a single response. 218 It is the basic requirement to provide the query for the compound 219 resources. Even simple cases can benefit if this requirement is 220 realized. 222 MPQ-Req2: The ALTO protocol SHOULD provide general filter schema for 223 any ALTO resources. 225 Current filter schema in ALTO protocol only supports the simple 226 boolean test of numerical comparison. And the boolean filtered 227 query is only supported by the cost map and the endpoint cost 228 resource. It is not enough for the general cases. Even simple 229 property map may require more general filter schema. 231 MPQ-Req3: The ALTO protocol SHOULD support relational query for 232 mulitple joint resources. 234 Some ALTO resources are relational and cannot be used 235 individually. The path vector query is such an example. In these 236 use cases, the support of relational query for multiple joint 237 resources is very helpful. 239 5. Overview of Approach 241 This document uses two key techniques to realize the general multiple 242 resources query: 244 o Use Multipart message [RFC2046] to deliver compound resources. 246 o Accept JSON Query Language like XQuery [W3CXQUERY] and JSONiq 247 [JSONIQ] for general query process and relational joint query. 249 6. Multipart Query Resource 251 6.1. Media Type 253 "multipart/related" [RFC2387]. 255 6.2. HTTP Method 257 An ALTO Multipart Query resource is requested using the HTTP POST 258 method. 260 6.3. Capabilities 262 The capabilities are defined by an object of type 263 MultipartQueryCapabilities: 265 object { 266 JSONString query-langs<0..*>; 267 } MultipartQueryCapabilities; 269 where "query-langs" is an array of JSONString to indicate which query 270 languages are supported by this resource. 272 6.4. Accept Input Parameters 274 The input parameters for a Multipart Query request are supplied in 275 the entity body of the POST request. This document specifies the 276 input parameters with a data format indicated by the media type 277 "application/alto-multipartquery+alto", which is a JSON object of 278 type ReqMultipartQuery: 280 object { 281 ResourceQuery resources<1..*>; 282 [JsonString query-lang;] 283 } ReqMultipartQuery; 285 object { 286 JsonString resource-id; 287 [JsonValue input;] 288 } ResourceQuery; 290 with fields: 292 resources: List of ResourceQuery objects for which resources are to 293 be queried and how to query them. Each ResourceQuery object MUST 294 include the "resource-id" field to indicate which resource is to 295 be queried. If the queried resource requires the POST method, the 296 "input" field MUST be specified. The value of the "input" field 297 MUST be either a JSONString or a JSONObject. When its value is a 298 JSONObject, its format MUST be as the accept input parameters of 299 its resource. When its value is a JSONString, it MUST be a 300 program written in the query language specified by the "query- 301 lang" field. 303 query-lang: Optional. The value of the "query-lang" field MUST be 304 one of values in the "query-langs" capability. If this field is 305 not specified in the request, the ALTO client SHOULD NOT use any 306 query language in the "input" field. 308 6.5. Uses 310 An array with the resource ID(s) of resource(s) which this multipart 311 query resource can compound. The used resource can be any available 312 ALTO resources except for the multipart query resource. If the 313 "uses" field is not specified, all the available ALTO resources can 314 be queried except for the multipart query resource. 316 6.6. Response 318 The response of multipart query resource is a multipart message. 319 Each part of this multipart message is the response of a queried 320 resource in the request. 322 7. Protocol Errors 324 The validation of each "input" field of the multipart query input 325 parameters depends on the queried resource: 327 o If the "input" field of the multipart query input parameters is 328 neither a JSONObject nor a JSONString, the ALTO server SHOULD 329 return the E_INVALID_FIELD_TYPE error, unless a future protocol 330 extension supports the non-JSONObject input parameters. 332 o If the "input" field of the multipart query input parameters is a 333 JSONObject, the ALTO server MUST validate the value using its 334 queried resource and return the corresponding error if it has. 336 o If the "input" field of the multipart query input parameters is a 337 JSONString: 339 * If the "query-lang" is not specified, the ALTO server MUST 340 return the E_INVALID_FIELD_TYPE error. 342 * If the "query-lang" is specified, the ALTO server MUST execute 343 this JSONString as a program written in the "query-lang". If 344 the execution failed, the ALTO server MUST return the 345 E_INVALID_FIELD_VALUE error. If the execution succeed but the 346 result fails to pass the validation of the queried resource, 347 the ALTO server MUST return the E_INVALID_FIELD_VALUE error and 348 attach the error message returned by the queried resource into 349 the "message" field of the ALTO error message. 351 8. Examples 353 8.1. IRD Example 355 Assume the root IRD is like the following: 357 { 358 "meta": { 359 "path-vector": { 360 "cost-mode": "array", 361 "cost-metric": "ane-path" 362 }, 363 "num-routingcost": { 364 "cost-mode": "numerical", 365 "cost-metric": "routingcost" 366 }, 367 "num-hopcount": { 368 "cost-mode": "numerical", 369 "cost-metric": "hopcount" 370 } 371 }, 372 "resources": { 373 "my-default-networkmap": { 374 "uri": "http://alto.example.com/networkmap", 375 "media-type": "application/alto-networkmap+json" 376 }, 377 "my-default-costmap": { 378 "uri": "http://alto.example.com/costmap", 379 "media-type": "application/alto-costmap+json", 380 "capabilities": { 381 "cost-type-names": [ "num-routingcost" ] 382 }, 383 "uses": [ "my-default-networkmap" ] 384 }, 385 "my-filtered-costmap": { 386 "uri": "http://alto.example.com/costmap/filtered", 387 "media-type": "application/alto-costmap+json", 388 "accepts": "application/alto-costmapfilter+json", 389 "capabilities": { 390 "cost-type-names": [ "num-hopcount" ] 391 }, 392 "uses": [ "my-default-networkmap" ] 393 }, 394 "endpoint-path-vector": { 395 "uri": "http://alto.exmaple.com/endpointcost", 396 "media-type": "application/alto-endpointcost+json", 397 "accepts": "application/alto-endpointcostparams+json", 398 "capabilities": { 399 "cost-constraints": true, 400 "cost-type-names": [ "path-vector" ], 401 }, 402 "property-map": "propmap-availbw" 403 }, 404 "propmap-availbw-delay": { 405 "uri": "http://alto.exmaple.com/propmap/availbw", 406 "media-type": "application/alto-propmap+json", 407 "accepts": "application/alto-propmapparams+json", 408 "capabilities": { 409 "domain-types": [ "ane" ], 410 "prop-types": [ "availbw" ] 411 } 412 }, 413 "propmap-location": { 414 "uri": "http://alto.exmaple.com/propmap/location", 415 "media-type": "application/alto-propmap+json", 416 "accepts": "application/alto-propmapparams+json", 417 "capabilities": { 418 "domain-types": [ "pid" ], 419 "prop-types": [ "country", "state" ] 420 } 421 }, 422 "multipart-query": { 423 "uri": "http://alto.example.com/multipart", 424 "media-type": "multipart/related", 425 "accepts": "application/alto-multipartquery+json", 426 "capabilities": { 427 "query-langs": [ "xquery", "jsoniq" ] 428 } 429 } 430 } 431 } 433 8.2. Example 1: Simple Batch Query 435 POST /multipart HTTP/1.1 436 Host: alto.example.com 437 Accept: multipart/related, application/alto-error+json 438 Content-Lenght: [TBD] 439 Content-Type: application/alto-multipartquery+json 441 { 442 "resources": [ 443 { 444 "resource-id": "my-default-networkmap" 445 }, 446 { 447 "resource-id": "my-default-costmap" 448 } 449 ] 450 } 452 HTTP/1.1 200 OK 453 Content-Lenght: [TBD] 454 Content-Type: multipart/related; boundary=simple-batch-query 456 --simple-batch-query 457 Content-Type: application/alto-networkmap+json 459 { 460 "meta": { 461 "vtag": { 462 "resource-id": "my-default-networkmap", 463 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 464 } 465 }, 466 "network-map": { 467 "PID1" : { 468 "ipv4" : [ 469 "192.0.2.0/24", 470 "198.51.100.0/25" 472 ] 473 }, 474 "PID2" : { 475 "ipv4" : [ 476 "198.51.100.128/25" 477 ] 478 }, 479 "PID3" : { 480 "ipv4" : [ 481 "0.0.0.0/0" 482 ], 483 "ipv6" : [ 484 "::/0" 485 ] 486 } 487 } 488 } 490 --simple-batch-query 491 Content-Type: application/alto-costmap+json 493 { 494 "meta": { 495 "dependent-vtags": [ 496 { 497 "resource-id": "my-default-networkmap", 498 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 499 } 500 ], 501 "cost-type": { 502 "cost-mode": "numerical", 503 "cost-metric": "routingcost" 504 } 505 }, 506 "cost-map": { 507 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 508 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 509 "PID3": { "PID1": 20, "PID2": 15 } 510 } 511 } 513 8.3. Example 2: Properties Constrained Query 515 NOTE: In this example, we use the "`" block to express the raw string 516 with unescaped characters like "\n" and "\"". It is not valid HTTP 517 body, but only used to better present. When the request is sent to 518 the ALTO server, the "`" block should be escaped. 520 POST /multipart HTTP/1.1 521 Host: alto.example.com 522 Accept: multipart/related, application/alto-error+json 523 Content-Lenght: [TBD] 524 Content-Type: application/alto-multipartquery+json 526 { 527 "query-lang": "jsoniq", 528 "resources": [ 529 { 530 "resource-id": "propmap-location" 531 }, 532 { 533 "resource-id": "my-default-costmap", 534 "input": ` 535 let $propmap := collection("propmap-location") 536 .("property-map") 537 return { 538 "cost-type": { 539 "cost-mode": "numerical", 540 "cost-metric": "hopcount" 541 }, 542 "pids": { 543 "srcs": [ 544 for $pid in keys($propmap) 545 where $propmap.$pid.country eq "US" 546 return substring-after($pid, "PID:") 547 ], 548 "dsts": [ 549 for $pid in keys($propmap) 550 where $propmap.$pid.country eq "CA" 551 return substring-after($pid, "PID:") 552 ] 553 } 554 } 555 ` 556 } 557 ] 558 } 560 HTTP/1.1 200 OK 561 Content-Lenght: [TBD] 562 Content-Type: multipart/related; boundary=prop-const-query 564 --prop-const-query 565 Content-Type: application/alto-propmap+json 567 { 568 "property-map": { 569 "pid:PID1": { 570 "country": "US", 571 "state": "CA" 572 }, 573 "pid:PID2": { 574 "country": "US", 575 "state": "CT" 576 }, 577 "pid:PID3": { 578 "country": "CA", 579 "state": "QC" 580 }, 581 "pid:PID4": { 582 "country": "CA", 583 "state": "NT" 584 }, 585 "pid:PID5": { 586 "country": "FR" 587 } 588 } 589 } 591 --prop-const-query 592 Content-Type: application/alto-costmap+json 594 { 595 "meta": { 596 "cost-type": { 597 "cost-mode": "numerical", 598 "cost-metric": "hopcount" 599 } 600 }, 601 "cost-map": { 602 "PID1": { 603 "PID3": 5, 604 "PID4": 7 605 }, 606 "PID2": { 607 "PID3": 8, 608 "PID4": 4 609 } 610 } 611 } 613 8.4. Example 3: Path Vector Query 615 POST /multipart HTTP/1.1 616 Host: alto.example.com 617 Accept: multipart/related, application/alto-error+json 618 Content-Lenght: [TBD] 619 Content-Type: application/alto-multipartquery+json 621 { 622 "query-lang": "jsoniq", 623 "resources": [ 624 { 625 "resource-id": "endpoint-path-vector", 626 "input": { 627 "cost-type": { 628 "cost-mode": "array", 629 "cost-metric": "ane-path" 630 }, 631 "endpoints": { 632 "srcs": [ "ipv4:192.0.2.2" ], 633 "dsts": [ "ipv4:192.0.2.89", 634 "ipv4:203.0.113.45" ] 635 } 636 } 637 }, 638 { 639 "resource-id": "propmap-availbw", 640 "input": ` 641 let $propmap := collection("endpiont-path-vector") 642 .("endpoint-cost-map") 643 return { 644 "entities": [ 645 distinct-values(flatten( 646 for $src in keys($propmap) 647 let $dsts := $propmap.$src 648 return flatten( 649 for $dst in keys($dsts) 650 return $dsts.$dst 651 ) 652 )) 653 ], 654 "properties": [ "availbw" ] 655 } 656 ` 657 } 658 ] 659 } 660 HTTP/1.1 200 OK 661 Content-Length: [TBD] 662 Content-Type: multipart/related; boundary=path-vector-query 664 --path-vector-query 665 Content-Type: application/alto-endpointcost+json 667 { 668 "meta": { 669 "cost-type": { 670 "cost-mode": "array", 671 "cost-metric": "ane-path" 672 } 673 }, 674 "endpoint-cost-map": { 675 "ipv4:192.0.2.2": { 676 "ipv4:192.0.2.89": [ "ane:L001", "ane:L003", "ane:L004" ], 677 "ipv4:203.0.113.45": [ "ane:L001", "ane:L004", "ane:L005" ], 678 "ipv6:2001:db8::10": [ "ane:L001", "ane:L005", "ane:L007" ] 679 } 680 } 681 } 683 --path-vector-query 684 Content-Type: application/alto-propmap+json 686 { 687 "property-map": { 688 "ane:L001": { "availbw": 50 }, 689 "ane:L003": { "availbw": 48 }, 690 "ane:L004": { "availbw": 55 }, 691 "ane:L005": { "availbw": 60 }, 692 "ane:L007": { "availbw": 35 } 693 } 694 } 696 9. Compatibility 698 9.1. Compatibility with Legacy ALTO Clients/Servers 700 The multipart query service is a new ALTO service using the new media 701 type. So the legacy ALTO client cannot identify this service from 702 the IRD of the ALTO server supporting it. And the legacy ALTO server 703 also cannot interpret the request of a multipart query service sent 704 by the ALTO client. 706 9.2. Compatibility with Existing Protocol Extensions 708 The multipart query service can use any ALTO resources exchanging 709 JSON data in request/response mechanism. So all the known ALTO 710 extensions like ALTO Calendar [I-D.ietf-alto-cost-calendar], Multi- 711 Cost [RFC8189] and the Path Vector [I-D.ietf-alto-path-vector] 712 extension, which does not change the request/response mechanism, are 713 compatible with the multipart query service. 715 9.3. Compatibility with New Communication Mechanism 717 Since the multipart query service use multipart messages as the 718 response instead of the JSON data, the incremental update service 719 defined in [I-D.ietf-alto-incr-update-sse] does not support it. If 720 the update service does not notify the incremental change to the ALTO 721 client but only notify the full replacement, it can still work. But 722 it is very inefficient. So an extension to integrate multipart query 723 and the incremental update smoothly is required. HTTP/2 may be a 724 candidate solution to this problem. 726 10. Misc Considerations 728 10.1. Support Incremental Update 730 Because the response body entry of the multipart query resource is 731 not a single JSON object, it may not be compatible with the existing 732 incremental update representation. 734 10.2. Anonymous Resources 736 Some use cases may need the server generates "anonymous" ALTO 737 resources for the on-demand information. The "anonymous" ALTO 738 resources usually cannot appear alone but need to bind with some 739 "non-anonymous" ALTO resources. 741 11. Security Considerations 743 Allow the ALTO clients to upload the query language script may not be 744 safe. The script injection and many potential attacks can be 745 conducted. The security issue should be discussed and considered. 747 12. IANA Considerations 749 12.1. application/alto-* Media Types 751 This document registers an additional ALTO media type, listed in 752 Table 1. 754 +-------------+--------------------------+---------------+ 755 | Type | Subtype | Specification | 756 +-------------+--------------------------+---------------+ 757 | application | alto-multipartquery+json | Section 6.4 | 758 +-------------+--------------------------+---------------+ 760 Table 1: Additional ALTO Media Type. 762 Type name: application 764 Subtype name: This document registers multiple subtypes, as listed 765 in Table 1. 767 Required parameters: n/a 769 Optional parameters: n/a 771 Encoding considerations: Encoding considerations are identical to 772 those specified for the "application/json" media type. See 773 [RFC7159]. 775 Security considerations: Security considerations related to the 776 generation and consumption of ALTO Protocol messages are discussed 777 in Section 15 of [RFC7285]. 779 Interoperability considerations: This document specifies formats of 780 conforming messages and the interpretation thereof. 782 Published specification: This document is the specification for 783 these media types; see Table 1 for the section documenting each 784 media type. 786 Applications that use this media type: ALTO servers and ALTO clients 787 either stand alone or are embedded within other applications. 789 Additional information: 791 Magic number(s): n/a 793 File extension(s): This document uses the mime type to refer to 794 protocol messages and thus does not require a file extension. 796 Macintosh file type code(s): n/a 798 Person & email address to contact for further information: See 799 Authors' Addresses section. 801 Intended usage: COMMON 802 Restrictions on usage: n/a 804 Author: See Authors' Addresses section. 806 Change controller: Internet Engineering Task Force 807 (mailto:iesg@ietf.org). 809 13. Acknowledgements 811 14. References 813 14.1. Normative References 815 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 816 Requirement Levels", BCP 14, RFC 2119, 817 DOI 10.17487/RFC2119, March 1997, 818 . 820 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 821 RFC 2387, DOI 10.17487/RFC2387, August 1998, 822 . 824 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 825 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 826 "Application-Layer Traffic Optimization (ALTO) Protocol", 827 RFC 7285, DOI 10.17487/RFC7285, September 2014, 828 . 830 14.2. Informative References 832 [I-D.ietf-alto-cost-calendar] 833 Randriamasy, S., Yang, Y., Wu, Q., Lingli, D., and N. 834 Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost- 835 calendar-06 (work in progress), July 2018. 837 [I-D.ietf-alto-incr-update-sse] 838 Roome, W., Yang, Y., and S. Chen, "ALTO Incremental 839 Updates Using Server-Sent Events (SSE)", draft-ietf-alto- 840 incr-update-sse-11 (work in progress), June 2018. 842 [I-D.ietf-alto-path-vector] 843 Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W., 844 Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path 845 Vector Cost Type", draft-ietf-alto-path-vector-03 (work in 846 progress), March 2018. 848 [I-D.ietf-alto-unified-props-new] 849 Roome, W., Chen, S., Randriamasy, S., Yang, Y., and J. 850 Zhang, "Unified Properties for the ALTO Protocol", draft- 851 ietf-alto-unified-props-new-04 (work in progress), June 852 2018. 854 [JSONIQ] Robie, J., Fourny, G., Brantner, M., Florescu, D., 855 Westmann, T., and M. Zaharioudakis, "JSONiq - the SQL of 856 NoSQL 1.0", JSONiq , 2015. 858 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 859 Extensions (MIME) Part Two: Media Types", RFC 2046, 860 DOI 10.17487/RFC2046, November 1996, 861 . 863 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 864 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 865 2014, . 867 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 868 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 869 DOI 10.17487/RFC8189, October 2017, 870 . 872 [W3CXQUERY] 873 Robie, J., Chamberlin, D., Dyck, M., and J. Snelson, 874 "XQuery 3.0: An XML query language", W3C Recommendation, 875 W3C, 2014. 877 Appendix A. Figures 879 TODO: Put additional figures here if we have. 881 Authors' Addresses 883 Shiwei Dawn Chen 884 Tongji University 885 4800 Cao'An Hwy 886 Shanghai 201804 887 China 889 Email: dawn_chen_f@hotmail.com 890 Jingxuan Jensen Zhang 891 Tongji University 892 4800 Cao'An Hwy 893 Shanghai 201804 894 China 896 Email: jingxuan.n.zhang@gmail.com