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. |