| rfc9569v4.txt | rfc9569.txt | |||
|---|---|---|---|---|
| Internet Engineering Task Force (IETF) K. Gao | Internet Engineering Task Force (IETF) K. Gao | |||
| Request for Comments: 9569 Sichuan University | Request for Comments: 9569 Sichuan University | |||
| Category: Standards Track R. Schott | Category: Standards Track R. Schott | |||
| ISSN: 2070-1721 Deutsche Telekom | ISSN: 2070-1721 Deutsche Telekom | |||
| Y. R. Yang | Y. R. Yang | |||
| L. Delwiche | L. Delwiche | |||
| L. Keller | L. Keller | |||
| Yale University | Yale University | |||
| May 2024 | June 2024 | |||
| The Application-Layer Traffic Optimization (ALTO) Transport Information | The Application-Layer Traffic Optimization (ALTO) Transport Information | |||
| Publication Service (TIPS) | Publication Service (TIPS) | |||
| Abstract | Abstract | |||
| "Application-Layer Traffic Optimization (ALTO) Protocol" (RFC 7285) | "Application-Layer Traffic Optimization (ALTO) Protocol" (RFC 7285) | |||
| leverages HTTP/1.1 and is designed for the simple, sequential | leverages HTTP/1.1 and is designed for the simple, sequential | |||
| request-reply use case, in which an ALTO client requests a sequence | request-reply use case, in which an ALTO client requests a sequence | |||
| of information resources and the server responds with the complete | of information resources and the server responds with the complete | |||
| skipping to change at line 707 ¶ | skipping to change at line 707 ¶ | |||
| merge-patch+json,application/json-patch+json", unless defined by a | merge-patch+json,application/json-patch+json", unless defined by a | |||
| future extension. | future extension. | |||
| When choosing the media types to encode incremental updates for a | When choosing the media types to encode incremental updates for a | |||
| resource, the server MUST consider the limitations of the | resource, the server MUST consider the limitations of the | |||
| encoding. For example, when a JSON merge patch specifies that the | encoding. For example, when a JSON merge patch specifies that the | |||
| value of a field is null, its semantics are that the field is | value of a field is null, its semantics are that the field is | |||
| removed from the target; hence, the field is no longer defined | removed from the target; hence, the field is no longer defined | |||
| (i.e., undefined). However, this may not be the intended result | (i.e., undefined). However, this may not be the intended result | |||
| for the resource, when null and undefined have different semantics | for the resource, when null and undefined have different semantics | |||
| for the resource. In such a case, the server MUST choose a JSON | for the resource. In such a case, the server MUST choose JSON | |||
| patch over a JSON merge patch if the JSON patch is indicated as a | patch encoding over JSON merge patch encoding for the incremental | |||
| capability of the TIPS information resource. If the server does | update if both media types "application/json-patch+json" and | |||
| not support a JSON patch to handle such a case, the server then | "application/merge-patch" are supported by the TIPS information | |||
| needs to send a full replacement. | resource. | |||
| 5.3. Uses | 5.3. Uses | |||
| The "uses" attribute MUST be an array with the resource IDs of every | The "uses" attribute MUST be an array with the resource IDs of every | |||
| network information resource for which this TIPS information resource | network information resource for which this TIPS information resource | |||
| can provide service. | can provide service. | |||
| This set MAY be any subset of the ALTO server's network information | This set MAY be any subset of the ALTO server's network information | |||
| resources and MAY include resources defined in linked IRDs. However, | resources and MAY include resources defined in linked IRDs. However, | |||
| it is RECOMMENDED that the ALTO server selects a set that is closed | it is RECOMMENDED that the ALTO server selects a set that is closed | |||
| under the resource dependency relationship. That is, if a TIPS | under the resource dependency relationship. That is, if a TIPS | |||
| information resource's "uses" set includes resource R1, and resource | information resource's "uses" set includes resource R1, and resource | |||
| R1 depends on ("uses") resource R0, then the "uses" set should | R1 depends on ("uses") resource R0, then the "uses" set should | |||
| include R0 as well as R1. For example, if a TIPS information | include R0 as well as R1. For example, if a TIPS information | |||
| resource provides a TIPS view for a cost map, it should also provide | resource provides a TIPS view for a cost map, it should also provide | |||
| a TIPS view for the network map upon which that cost map depends. | a TIPS view for the network map upon which that cost map depends. | |||
| If the set is not closed, at least one resource R1 in the "uses" | If the set is not closed, at least one resource R1 in the "uses" | |||
| field of a TIPS information resource depends on another resource R0 | field of a TIPS information resource depends on another resource R0 | |||
| that is not in the "uses" field of the same TIPS information | that is not in the "uses" field of the same TIPS information | |||
| resource. Thus, a client cannot receive incremental updates for R0 | resource. Thus, a client cannot receive incremental updates for | |||
| from the same TIPS information resource. If the client observes in | another resource R0 that is not in the "uses" field of the same TIPS | |||
| an update of R1 that the version tag for R0 has changed, it must | information resource. If the client observes in an update of R1 that | |||
| request the full content of R0, which is likely to be less efficient | the version tag for R0 has changed, it must request the full content | |||
| than receiving the incremental updates of R0. | of R0, which is likely to be less efficient than receiving the | |||
| incremental updates of R0. | ||||
| 5.4. An Example | 5.4. An Example | |||
| Extending the IRD example in Section 8.1 of [RFC8895], Figure 6 is | Extending the IRD example in Section 8.1 of [RFC8895], Figure 6 is | |||
| the IRD of an ALTO server supporting the ALTO base protocol, ALTO/ | the IRD of an ALTO server supporting the ALTO base protocol, ALTO/ | |||
| SSE, and ALTO TIPS. | SSE, and ALTO TIPS. | |||
| "my-network-map": { | "my-network-map": { | |||
| "uri": "https://alto.example.com/networkmap", | "uri": "https://alto.example.com/networkmap", | |||
| "media-type": "application/alto-networkmap+json" | "media-type": "application/alto-networkmap+json" | |||
| skipping to change at line 1947 ¶ | skipping to change at line 1948 ¶ | |||
| 51 Prospect Street | 51 Prospect Street | |||
| New Haven, CT 06511 | New Haven, CT 06511 | |||
| United States of America | United States of America | |||
| Email: lauren.delwiche@yale.edu | Email: lauren.delwiche@yale.edu | |||
| Lachlan Keller | Lachlan Keller | |||
| Yale University | Yale University | |||
| 51 Prospect Street | 51 Prospect Street | |||
| New Haven, CT 06511 | New Haven, CT 06511 | |||
| United States of America | United States of America | |||
| Email: lachlan.keller@yale.edu | Email: lachlan.keller@aya.yale.edu | |||
| End of changes. 4 change blocks. | ||||
| 11 lines changed or deleted | 12 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||