rfc9569v8.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
	August 2024		September 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 1836 ¶		skipping to change at line 1836 ¶
	* There are no statically defined URI components (Section 3.2 of		* There are no statically defined URI components (Section 3.2 of
	[RFC9205]).		[RFC9205]).
	* No minimum version of HTTP is specified by TIPS, which is		* No minimum version of HTTP is specified by TIPS, which is
	recommended (in Section 4.1 of [RFC9205]).		recommended (in Section 4.1 of [RFC9205]).
	* The TIPS design follows the advice (in Section 4.1 of [RFC9205])		* The TIPS design follows the advice (in Section 4.1 of [RFC9205])
	that:		that:
	| When specifying examples of protocol interactions, applications		| When specifying examples of protocol interactions, applications
	| should document both the request and response messages with		| should document both the request and response messages with
	| complete header sections, preferably in HTTP/1.1 format...		| complete header sections, preferably in HTTP/1.1 format...
	* TIPS uses URI templates, which is recommended (in Section 4.2 of		* TIPS uses URI templates, which is recommended (in Section 4.2 of
	[RFC9205]).		[RFC9205]).
	* TIPS follows the pattern (in Section 4.4.1 of [RFC9205]) that:		* TIPS follows the pattern (in Section 4.4.1 of [RFC9205]) that:
	| Generally, a client will begin interacting with a given		| Generally, a client will begin interacting with a given
	| application server by requesting an initial document that contains		| application server by requesting an initial document that
	| information about that particular deployment, potentially		| contains information about that particular deployment,
	| including links to other relevant resources. Doing so ensures		| potentially including links to other relevant resources. Doing
	| that the deployment is as flexible as possible (potentially		| so ensures that the deployment is as flexible as possible
	| spanning multiple servers), allows evolution, and also gives the		| (potentially spanning multiple servers), allows evolution, and
	| application the opportunity to tailor the "discovery document" to		| also gives the application the opportunity to tailor the
	| the client.		| "discovery document" to the client.
	* TIPS uses existing HTTP schemes (Section 4.4.2 of [RFC9205]).		* TIPS uses existing HTTP schemes (Section 4.4.2 of [RFC9205]).
	* TIPS defines its errors "to use the most applicable status code"		* TIPS defines its errors "to use the most applicable status code"
	(Section 4.6 of [RFC9205]).		(Section 4.6 of [RFC9205]).
	* TIPS does not (as in Section 4.11 of [RFC9205]):		* TIPS does not (as in Section 4.11 of [RFC9205]):
	| ...make assumptions about the relationship between separate		| ...make assumptions about the relationship between separate
	| requests on a single transport connection; doing so breaks many of		| requests on a single transport connection; doing so breaks many
	| the assumptions of HTTP as a stateless protocol and will cause		| of the assumptions of HTTP as a stateless protocol and will
	| problems in interoperability, security, operability, and		| cause problems in interoperability, security, operability, and
	| evolution.		| evolution.
	The only relationship between requests is that a client has to		The only relationship between requests is that a client has to
	first discover where a TIPS view of a resource will be served,		first discover where a TIPS view of a resource will be served,
	which is consistent with the URI discovery in Section 4.4.1 of		which is consistent with the URI discovery in Section 4.4.1 of
	[RFC9205].		[RFC9205].
	Appendix C. Push-Mode TIPS Using HTTP Server Push		Appendix C. Push-Mode TIPS Using HTTP Server Push
	TIPS allows ALTO clients to subscribe to incremental updates of an		TIPS allows ALTO clients to subscribe to incremental updates of an
	ALTO resource, and the specification in this document is based on the		ALTO resource, and the specification in this document is based on the
	skipping to change at line 1906 ¶		skipping to change at line 1906 ¶
	client and the ALTO server, but between the ALTO client and the proxy		client and the ALTO server, but between the ALTO client and the proxy
	and between the proxy and the ALTO server. Thus, using persistent		and between the proxy and the ALTO server. Thus, using persistent
	connections might not correctly detect the right liveness state.		connections might not correctly detect the right liveness state.
	Acknowledgments		Acknowledgments
	The authors of this document would like to thank Mark Nottingham and		The authors of this document would like to thank Mark Nottingham and
	Spencer Dawkins for providing invaluable reviews of earlier draft		Spencer Dawkins for providing invaluable reviews of earlier draft
	versions of this document; Adrian Farrel, Qin Wu, and Jordi Ros		versions of this document; Adrian Farrel, Qin Wu, and Jordi Ros
	Giralt for their continuous feedback; Russ White, Donald Eastlake		Giralt for their continuous feedback; Russ White, Donald Eastlake
	3rd, Martin Thomson, Bernard Adoba, Spencer Dawkins, Linda Dunbar,		3rd, Martin Thomson, Bernard Aboba, Spencer Dawkins, Linda Dunbar,
	and Sheng Jiang for the directorate reviews; Martin Duke for the area		and Sheng Jiang for the directorate reviews; Martin Duke for the area
	director review; Francesca Palombini, Wesley Eddy, Roman Danyliw,		director review; Francesca Palombini, Wesley Eddy, Roman Danyliw,
	Murray Kucherawy, and Zaheduzzaman Sarker for the telechat and IESG		Murray Kucherawy, and Zaheduzzaman Sarker for the telechat and IESG
	reviews; and Mohamed Boucadair for shepherding the document.		reviews; and Mohamed Boucadair for shepherding the document.
	Authors' Addresses		Authors' Addresses
	Kai Gao		Kai Gao
	Sichuan University		Sichuan University
	No.24 South Section 1, Yihuan Road		No.24 South Section 1, Yihuan Road
End of changes. 5 change blocks.
	18 lines changed or deleted		18 lines changed or added
This html diff was produced by rfcdiff 1.48.