idnits 2.17.1 draft-zhang-alto-multipart-02.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 323 has weird spacing: '...ceQuery reso...' -- The document date (March 25, 2019) is 1860 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 749, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-alto-cost-calendar-11 == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-16 == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-05 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-07 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 J. Zhang 3 Internet-Draft Tongji University 4 Intended status: Standards Track March 25, 2019 5 Expires: September 26, 2019 7 Multiple ALTO Resources Query Using Multipart Message 8 draft-zhang-alto-multipart-02 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 September 26, 2019. 48 Copyright Notice 50 Copyright (c) 2019 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 . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 12 90 9.3. Example 2: Properties Constrained Query . . . . . . . . . 13 91 9.4. Example 3: Path Vector Query . . . . . . . . . . . . . . 16 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. Support Incremental Update . . . . . . . . . . . . . . . 18 97 11.2. Anonymous Resources . . . . . . . . . . . . . . . . . . 18 98 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 99 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 100 13.1. application/alto-* Media Types . . . . . . . . . . . . . 19 101 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 102 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 103 15.1. Normative References . . . . . . . . . . . . . . . . . . 20 104 15.2. Informative References . . . . . . . . . . . . . . . . . 21 105 Appendix A. Figures . . . . . . . . . . . . . . . . . . . . . . 21 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 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 Besides the terms defined in [RFC2045], [RFC2046], [RFC2387], and 149 [RFC7285], this document also uses the following additional terms: 151 2.1. Resource Query Entry 153 A Resource Query Entry indicates the ResoureQuery object (see 154 Section 6.4) for an individual resource in the accept input 155 parameters of the Multipart Query resource. 157 2.2. Resource Response Entry 159 A Resource Response Entry indicates the entry of an individual part 160 of the multipart response message, including the MIME headers and the 161 body content. 163 2.3. Resource Response Entry Body 165 A Resource Response Entry Body indicates the body content of a 166 Resource Response Entry. 168 3. Use Cases 170 The following use cases can benefit from the multipart query service. 172 3.1. Simple Batch Query 174 The simplest use case is to query a batch of ALTO resources in a 175 single request. 177 Although the ALTO client can perform ALTO requests for multiple 178 times, it is not only inefficient but also inconsistent. 180 For example, the ALTO server provides a network map resource A and a 181 dependent cost map resource B. Both resources may change frequently. 182 Assume the ALTO client queries the network map first, and it gets the 183 revision A1. When the client queries the cost map, the network map 184 may be already changed from A1 to A2, and the client receives cost 185 map B2 which depends on A2 not A1. So the responded cost map B2 is 186 not consistent with the previous network map A1. 188 This case requires the ALTO server to provide a way for the ALTO 189 client to query multiple ALTO resources in a single transaction. 191 3.2. Properties Constrained Query 193 Beyond the simple batch query, there are also some another use cases 194 requiring a new service for relational query. For example, Some 195 clients may need to query an endpoint property map first, and find 196 endpoints with some properties fitting some conditions. And then 197 they query the endpoint cost of these endpoints. 199 In this case, the endpoint cost query depends on the result of the 200 property map query. Although the ALTO client can cache the whole 201 property map in its local storage, it is still not efficient and may 202 conduct the consistency issue if the property map changes frequently. 203 So it requires a new service to provide multiple dependent resources 204 efficiently and consistently. 206 A general multipart query service benefits the ALTO client in two 207 aspects: 209 o It allows the ALTO client to specify the boolean test to reduce 210 the transmission of the useless data from the ALTO server. 212 o It compounds multiple ALTO information resources in a single 213 response to reduce the communication times. Thus, the 214 transmission latency can be reduced. 216 3.3. Path Vector Query 218 Another use case requiring the multiple resource query is the 219 relational query between the on-demand generated resources. A 220 straightforward example is the path vector query demonstrated in 221 [I-D.ietf-alto-path-vector]. 223 [I-D.ietf-alto-path-vector] introduces an extension of ALTO to 224 provide path vector information by cost map and unified property map 225 [I-D.ietf-alto-unified-props-new]. The client using path vector 226 extension will usually query cost map and a dynamically generated 227 property map sequentially. It is even hard to cache the full data of 228 resources, because both the cost map and the property map are on- 229 demand generated by the query input here. Thus, the only way to 230 reduce the time consumption is to compound the two resources. 232 4. Requirements 234 From the use cases described in Section 3, there are three additional 235 requirements for ALTO protocol: 237 MPQ-Req1: The ALTO protocol SHOULD allow the client to query 238 multiple ALTO resources in a single request, and return the result 239 in a single response. 241 It is the basic requirement to provide the query for the compound 242 resources. Even simple cases can benefit if this requirement is 243 realized. 245 MPQ-Req2: The ALTO protocol SHOULD provide general filter schema for 246 any ALTO resources. 248 Current filter schema in ALTO protocol only supports the simple 249 boolean test of numerical comparison. And the boolean filtered 250 query is only supported by the cost map and the endpoint cost 251 resource. It is not enough for the general cases. Even simple 252 property map may require more general filter schema. 254 MPQ-Req3: The ALTO protocol SHOULD support relational query for 255 mulitple joint resources. 257 Some ALTO resources are relational and cannot be used 258 individually. The path vector query is such an example. In these 259 use cases, the support of relational query for multiple joint 260 resources is very helpful. 262 5. Design Space of Multipart Resource in ALTO 264 This document discusses the solution of how to apply "multipart/*" 265 (see [RFC2045] and [RFC2046]) response to the ALTO protocol. 267 There are three cases applying Multipart response to ALTO: 269 Multipart Request and Multipart Response: In this case, an ALTO 270 client can start a single request using Multipart encoding to 271 query a batch of resources. 273 Single Request and Fixed-Layout Multipart Response: In this case, an 274 ALTO server receives a non-Multipart request, e.g., the filtered 275 costmap request or the endpoint cost request, but returns a 276 Multipart response. The ALTO server MUST export the layout of the 277 Multipart response in the IRD. A special example can be found in 278 [I-D.ietf-alto-path-vector]. 280 Single Request and Flexible-Layout Multipart Response: This case 281 extends the previous case to allows the Multipart response with 282 flexible layout. The ALTO server receives the unified query 283 request and generate the layout of the response based on the 284 request. The ALTO client can even use general-purpose query 285 language like XQuery [W3CXQUERY] and JSONiq [JSONIQ] for general 286 query process and relational joint query. 288 The application about Multipart request to the single object response 289 is out of the scope of this document. 291 6. Multipart Query Resource 293 6.1. Media Type 295 "multipart/related" [RFC2387]. 297 6.2. HTTP Method 299 An ALTO Multipart Query resource is requested using the HTTP POST 300 method. 302 6.3. Capabilities 304 The capabilities are defined by an object of type 305 MultipartQueryCapabilities: 307 object { 308 JSONString query-langs<0..*>; 309 } MultipartQueryCapabilities; 311 where "query-langs" is an array of JSONString to indicate which query 312 languages are supported by this resource. 314 6.4. Accept Input Parameters 316 The input parameters for a Multipart Query request are supplied in 317 the entity body of the POST request. This document specifies the 318 input parameters with a data format indicated by the media type 319 "application/alto-multipartquery+alto", which is a JSON object of 320 type ReqMultipartQuery: 322 object { 323 ResourceQuery resources<1..*>; 324 [JsonString query-lang;] 325 } ReqMultipartQuery; 327 object { 328 JsonString resource-id; 329 [JsonValue input;] 330 } ResourceQuery; 332 with fields: 334 resources: List of ResourceQuery objects for which resources are to 335 be queried and how to query them. Each ResourceQuery object MUST 336 include the "resource-id" field to indicate which resource is to 337 be queried. If the queried resource requires the POST method, the 338 "input" field MUST be specified. The value of the "input" field 339 MUST be either a JSONString or a JSONObject. When its value is a 340 JSONObject, its format MUST be as the accept input parameters of 341 its resource. When its value is a JSONString, it MUST be a 342 program written in the query language specified by the "query- 343 lang" field. 345 query-lang: Optional. The value of the "query-lang" field MUST be 346 one of values in the "query-langs" capability. If this field is 347 not specified in the request, the ALTO client SHOULD NOT use any 348 query language in the "input" field. 350 6.5. Uses 352 An array with the resource ID(s) of resource(s) which this multipart 353 query resource can compound. The used resource can be any available 354 ALTO resources except for the multipart query resource. If the 355 "uses" field is not specified, all the available ALTO resources can 356 be queried except for the multipart query resource. 358 6.6. Response 360 The response of multipart query resource is a multipart message. 361 Each part of this multipart message is the response of a queried 362 resource in the request. 364 7. Protocol Errors 366 At the top level, the request of ALTO Multipart Query resource may 367 conduct two types of errors: Partial Error and Entire Error. 369 7.1. Partial Error 371 The Partial Error only occurs when the value of the "resource-id" 372 field or the "input" field is invalid. 374 When the Partial Error occurs, the ALTO server MUST still return the 375 response in the media type "multipart/related". For the resource 376 query entry with an error, the ALTO server MUST specify the "Content- 377 Type" of its resource response entry as "application/alto- 378 error+json", and include the ALTO error message in its resource 379 response entry body. For the resource query entry without any error, 380 the ALTO server MUST perform its query request normally. 382 The value of the "resource-id" field is invalid when this resource id 383 is not defined by the Information Resource Directory. In this case, 384 the ALTO server MUST return the E_INVALID_FIELD_VALUE error. 386 The validation of each "input" field of the multipart query input 387 parameters depends on the queried resource: 389 o If the "input" field of the multipart query input parameters is 390 neither a JSONObject nor a JSONString, the ALTO server SHOULD 391 return the E_INVALID_FIELD_TYPE error, unless a future protocol 392 extension supports the non-JSONObject input parameters. 394 o If the "input" field of the multipart query input parameters is a 395 JSONObject, the ALTO server MUST validate the value using its 396 queried resource and return the corresponding error if it has. 398 o If the "input" field of the multipart query input parameters is a 399 JSONString: 401 * If the "query-lang" is not specified, the ALTO server MUST 402 return the E_INVALID_FIELD_TYPE error. 404 * If the "query-lang" is specified, the ALTO server MUST execute 405 this JSONString as a program written in the "query-lang". If 406 the execution failed, the ALTO server MUST return the 407 E_INVALID_FIELD_VALUE error. If the execution succeed but the 408 result fails to pass the validation of the queried resource, 409 the ALTO server MUST return the E_INVALID_FIELD_VALUE error and 410 attach the error message returned by the queried resource into 411 the "message" field of the ALTO error message. 413 The syntax error is an Entire Error. 415 7.2. Entire Error 417 Any other invalid request will conduct the Entire Error. 419 When the Entire Error occurs, the ALTO server MUST return the error 420 response in the media type "application/alto-error+json" instead of 421 "multipart/related". The process of the Entire Error is as defined 422 in Section 8.5 of [RFC7285]. 424 8. Incremental Update Integration 426 This document defines a compatible incremental update process for 427 Multipart Query resource with [I-D.ietf-alto-incr-update-sse]. 429 An ALTO server's IRD can export an Update Stream service defined in 430 [I-D.ietf-alto-incr-update-sse] including the Resource ID of a 431 Multipart Query resource in the "uses" field. When an ALTO client 432 subscribe the incremental update for this Multipart Query resource, 433 the ALTO server sends the whole Multipart response message back at 434 the first data update message. Then the ALTO server subscribe all 435 nodes in this multipart resource tree automatically. Once data 436 updated later, the ALTO server publishes the update for each node 437 individually. 439 9. Examples 441 9.1. IRD Example 443 Assume the root IRD is like the following: 445 { 446 "meta": { 447 "path-vector": { 448 "cost-mode": "array", 449 "cost-metric": "ane-path" 450 }, 451 "num-routingcost": { 452 "cost-mode": "numerical", 453 "cost-metric": "routingcost" 454 }, 455 "num-hopcount": { 456 "cost-mode": "numerical", 457 "cost-metric": "hopcount" 458 } 459 }, 460 "resources": { 461 "my-default-networkmap": { 462 "uri": "http://alto.example.com/networkmap", 463 "media-type": "application/alto-networkmap+json" 464 }, 465 "my-default-costmap": { 466 "uri": "http://alto.example.com/costmap", 467 "media-type": "application/alto-costmap+json", 468 "capabilities": { 469 "cost-type-names": [ "num-routingcost" ] 470 }, 471 "uses": [ "my-default-networkmap" ] 472 }, 473 "my-filtered-costmap": { 474 "uri": "http://alto.example.com/costmap/filtered", 475 "media-type": "application/alto-costmap+json", 476 "accepts": "application/alto-costmapfilter+json", 477 "capabilities": { 478 "cost-type-names": [ "num-hopcount" ] 479 }, 480 "uses": [ "my-default-networkmap" ] 481 }, 482 "endpoint-path-vector": { 483 "uri": "http://alto.exmaple.com/endpointcost", 484 "media-type": "application/alto-endpointcost+json", 485 "accepts": "application/alto-endpointcostparams+json", 486 "capabilities": { 487 "cost-constraints": true, 488 "cost-type-names": [ "path-vector" ], 489 }, 490 "property-map": "propmap-availbw" 491 }, 492 "propmap-availbw-delay": { 493 "uri": "http://alto.exmaple.com/propmap/availbw", 494 "media-type": "application/alto-propmap+json", 495 "accepts": "application/alto-propmapparams+json", 496 "capabilities": { 497 "domain-types": [ "ane" ], 498 "prop-types": [ "availbw" ] 499 } 500 }, 501 "propmap-location": { 502 "uri": "http://alto.exmaple.com/propmap/location", 503 "media-type": "application/alto-propmap+json", 504 "accepts": "application/alto-propmapparams+json", 505 "capabilities": { 506 "domain-types": [ "pid" ], 507 "prop-types": [ "country", "state" ] 508 } 509 }, 510 "multipart-query": { 511 "uri": "http://alto.example.com/multipart", 512 "media-type": "multipart/related", 513 "accepts": "application/alto-multipartquery+json", 514 "capabilities": { 515 "query-langs": [ "xquery", "jsoniq" ] 516 } 517 } 518 } 519 } 521 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" 570 ], 571 "ipv6" : [ 572 "::/0" 573 ] 574 } 575 } 576 } 578 --simple-batch-query 579 Content-Type: application/alto-costmap+json 581 { 582 "meta": { 583 "dependent-vtags": [ 584 { 585 "resource-id": "my-default-networkmap", 586 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 587 } 588 ], 589 "cost-type": { 590 "cost-mode": "numerical", 591 "cost-metric": "routingcost" 592 } 593 }, 594 "cost-map": { 595 "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 }, 596 "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 }, 597 "PID3": { "PID1": 20, "PID2": 15 } 598 } 599 } 601 9.3. Example 2: Properties Constrained Query 603 NOTE: In this example, we use the "`" block to express the raw string 604 with unescaped characters like "\n" and "\"". It is not valid HTTP 605 body, but only used to better present. When the request is sent to 606 the ALTO server, the "`" block should be escaped. 608 POST /multipart HTTP/1.1 609 Host: alto.example.com 610 Accept: multipart/related, application/alto-error+json 611 Content-Lenght: [TBD] 612 Content-Type: application/alto-multipartquery+json 614 { 615 "query-lang": "jsoniq", 616 "resources": [ 617 { 618 "resource-id": "propmap-location" 619 }, 620 { 621 "resource-id": "my-default-costmap", 622 "input": ` 623 let $propmap := collection("propmap-location") 624 .("property-map") 625 return { 626 "cost-type": { 627 "cost-mode": "numerical", 628 "cost-metric": "hopcount" 629 }, 630 "pids": { 631 "srcs": [ 632 for $pid in keys($propmap) 633 where $propmap.$pid.country eq "US" 634 return substring-after($pid, "PID:") 635 ], 636 "dsts": [ 637 for $pid in keys($propmap) 638 where $propmap.$pid.country eq "CA" 639 return substring-after($pid, "PID:") 640 ] 641 } 642 } 643 ` 644 } 645 ] 646 } 648 HTTP/1.1 200 OK 649 Content-Lenght: [TBD] 650 Content-Type: multipart/related; boundary=prop-const-query 652 --prop-const-query 653 Content-Type: application/alto-propmap+json 655 { 656 "property-map": { 657 "pid:PID1": { 658 "country": "US", 659 "state": "CA" 660 }, 661 "pid:PID2": { 662 "country": "US", 663 "state": "CT" 664 }, 665 "pid:PID3": { 666 "country": "CA", 667 "state": "QC" 668 }, 669 "pid:PID4": { 670 "country": "CA", 671 "state": "NT" 672 }, 673 "pid:PID5": { 674 "country": "FR" 675 } 676 } 677 } 679 --prop-const-query 680 Content-Type: application/alto-costmap+json 682 { 683 "meta": { 684 "cost-type": { 685 "cost-mode": "numerical", 686 "cost-metric": "hopcount" 687 } 688 }, 689 "cost-map": { 690 "PID1": { 691 "PID3": 5, 692 "PID4": 7 693 }, 694 "PID2": { 695 "PID3": 8, 696 "PID4": 4 697 } 698 } 699 } 701 9.4. Example 3: Path Vector Query 703 POST /multipart HTTP/1.1 704 Host: alto.example.com 705 Accept: multipart/related, application/alto-error+json 706 Content-Lenght: [TBD] 707 Content-Type: application/alto-multipartquery+json 709 { 710 "query-lang": "jsoniq", 711 "resources": [ 712 { 713 "resource-id": "endpoint-path-vector", 714 "input": { 715 "cost-type": { 716 "cost-mode": "array", 717 "cost-metric": "ane-path" 718 }, 719 "endpoints": { 720 "srcs": [ "ipv4:192.0.2.2" ], 721 "dsts": [ "ipv4:192.0.2.89", 722 "ipv4:203.0.113.45" ] 723 } 724 } 725 }, 726 { 727 "resource-id": "propmap-availbw", 728 "input": ` 729 let $propmap := collection("endpiont-path-vector") 730 .("endpoint-cost-map") 731 return { 732 "entities": [ 733 distinct-values(flatten( 734 for $src in keys($propmap) 735 let $dsts := $propmap.$src 736 return flatten( 737 for $dst in keys($dsts) 738 return $dsts.$dst 739 ) 740 )) 741 ], 742 "properties": [ "availbw" ] 743 } 744 ` 745 } 746 ] 747 } 748 HTTP/1.1 200 OK 749 Content-Length: [TBD] 750 Content-Type: multipart/related; boundary=path-vector-query 752 --path-vector-query 753 Content-Type: application/alto-endpointcost+json 755 { 756 "meta": { 757 "cost-type": { 758 "cost-mode": "array", 759 "cost-metric": "ane-path" 760 } 761 }, 762 "endpoint-cost-map": { 763 "ipv4:192.0.2.2": { 764 "ipv4:192.0.2.89": [ "ane:L001", "ane:L003", "ane:L004" ], 765 "ipv4:203.0.113.45": [ "ane:L001", "ane:L004", "ane:L005" ], 766 "ipv6:2001:db8::10": [ "ane:L001", "ane:L005", "ane:L007" ] 767 } 768 } 769 } 771 --path-vector-query 772 Content-Type: application/alto-propmap+json 774 { 775 "property-map": { 776 "ane:L001": { "availbw": 50 }, 777 "ane:L003": { "availbw": 48 }, 778 "ane:L004": { "availbw": 55 }, 779 "ane:L005": { "availbw": 60 }, 780 "ane:L007": { "availbw": 35 } 781 } 782 } 784 10. Compatibility 786 10.1. Compatibility with Legacy ALTO Clients/Servers 788 The multipart query service is a new ALTO service using the new media 789 type. So the legacy ALTO client cannot identify this service from 790 the IRD of the ALTO server supporting it. And the legacy ALTO server 791 also cannot interpret the request of a multipart query service sent 792 by the ALTO client. 794 10.2. Compatibility with Existing Protocol Extensions 796 The multipart query service can use any ALTO resources exchanging 797 JSON data in request/response mechanism. So all the known ALTO 798 extensions like ALTO Calendar [I-D.ietf-alto-cost-calendar], Multi- 799 Cost [RFC8189] and the Path Vector [I-D.ietf-alto-path-vector] 800 extension, which does not change the request/response mechanism, are 801 compatible with the multipart query service. 803 11. Misc Considerations 805 11.1. Support Incremental Update 807 Because the response body entry of the multipart query resource is 808 not a single JSON object, it may not be compatible with the current 809 incremental update representation used in 810 [I-D.ietf-alto-incr-update-sse]. 812 11.2. Anonymous Resources 814 Some use cases may need the server generates "anonymous" ALTO 815 resources for the on-demand information. The "anonymous" ALTO 816 resources usually cannot appear alone but need to bind with some 817 "non-anonymous" ALTO resources. 819 12. Security Considerations 821 Allow the ALTO clients to upload the query language script may not be 822 safe. The code injection and many potential attacks can be 823 conducted. The security issue should be discussed and considered. 825 To avoid the attacks like the code injection, this document 826 recommends the following approaches: 828 Database Isolation: Some clients may attempt to access the secure 829 database inside the server. Isolate the data into the different 830 databases can reduce the risk of the information leak. 832 Application Container Isolation: Attackers may inject harmful code 833 into the input query programs to attempt to access the system 834 control. To avoid this, each query process is recommended to be 835 isolated using the application container. 837 Resource Limit: Even attackers cannot get the permission to crack 838 the data or the system, they can still inject some heavy-load 839 programs to consume the server resources. Thus, limiting the 840 memory usage and execution time of each query process is highly 841 recommended. 843 13. IANA Considerations 845 13.1. application/alto-* Media Types 847 This document registers an additional ALTO media type, listed in 848 Table 1. 850 +-------------+--------------------------+---------------+ 851 | Type | Subtype | Specification | 852 +-------------+--------------------------+---------------+ 853 | application | alto-multipartquery+json | Section 6.4 | 854 +-------------+--------------------------+---------------+ 856 Table 1: Additional ALTO Media Type. 858 Type name: application 860 Subtype name: This document registers multiple subtypes, as listed 861 in Table 1. 863 Required parameters: n/a 865 Optional parameters: n/a 867 Encoding considerations: Encoding considerations are identical to 868 those specified for the "application/json" media type. See 869 [RFC8259]. 871 Security considerations: Security considerations related to the 872 generation and consumption of ALTO Protocol messages are discussed 873 in Section 15 of [RFC7285]. 875 Interoperability considerations: This document specifies formats of 876 conforming messages and the interpretation thereof. 878 Published specification: This document is the specification for 879 these media types; see Table 1 for the section documenting each 880 media type. 882 Applications that use this media type: ALTO servers and ALTO clients 883 either stand alone or are embedded within other applications. 885 Additional information: 887 Magic number(s): n/a 889 File extension(s): This document uses the mime type to refer to 890 protocol messages and thus does not require a file extension. 892 Macintosh file type code(s): n/a 894 Person & email address to contact for further information: See 895 Authors' Addresses section. 897 Intended usage: COMMON 899 Restrictions on usage: n/a 901 Author: See Authors' Addresses section. 903 Change controller: Internet Engineering Task Force 904 (mailto:iesg@ietf.org). 906 14. Acknowledgements 908 15. References 910 15.1. Normative References 912 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 913 Extensions (MIME) Part One: Format of Internet Message 914 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 915 . 917 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 918 Extensions (MIME) Part Two: Media Types", RFC 2046, 919 DOI 10.17487/RFC2046, November 1996, 920 . 922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 923 Requirement Levels", BCP 14, RFC 2119, 924 DOI 10.17487/RFC2119, March 1997, 925 . 927 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 928 RFC 2387, DOI 10.17487/RFC2387, August 1998, 929 . 931 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 932 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 933 "Application-Layer Traffic Optimization (ALTO) Protocol", 934 RFC 7285, DOI 10.17487/RFC7285, September 2014, 935 . 937 15.2. Informative References 939 [I-D.ietf-alto-cost-calendar] 940 Randriamasy, S., Yang, Y., Wu, Q., Lingli, D., and N. 941 Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost- 942 calendar-11 (work in progress), February 2019. 944 [I-D.ietf-alto-incr-update-sse] 945 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 946 Server-Sent Events (SSE)", draft-ietf-alto-incr-update- 947 sse-16 (work in progress), March 2019. 949 [I-D.ietf-alto-path-vector] 950 Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang, 951 "ALTO Extension: Path Vector Cost Type", draft-ietf-alto- 952 path-vector-05 (work in progress), March 2019. 954 [I-D.ietf-alto-unified-props-new] 955 Roome, W., Randriamasy, S., Yang, Y., and J. Zhang, 956 "Unified Properties for the ALTO Protocol", draft-ietf- 957 alto-unified-props-new-07 (work in progress), March 2019. 959 [JSONIQ] Robie, J., Fourny, G., Brantner, M., Florescu, D., 960 Westmann, T., and M. Zaharioudakis, "JSONiq - the SQL of 961 NoSQL 1.0", JSONiq , 2015. 963 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 964 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 965 DOI 10.17487/RFC8189, October 2017, 966 . 968 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 969 Interchange Format", STD 90, RFC 8259, 970 DOI 10.17487/RFC8259, December 2017, 971 . 973 [W3CXQUERY] 974 Robie, J., Chamberlin, D., Dyck, M., and J. Snelson, 975 "XQuery 3.0: An XML query language", W3C Recommendation, 976 W3C, 2014. 978 Appendix A. Figures 980 TODO: Put additional figures here if we have. 982 Author's Address 984 Jingxuan Jensen Zhang 985 Tongji University 986 4800 Cao'An Hwy 987 Shanghai 201804 988 China 990 Email: jingxuan.n.zhang@gmail.com