rfc9569v5.txt		rfc9569.txt
	skipping to change at line 441 ¶		skipping to change at line 441 ¶
	Version 0 is reserved as the initial state (empty/null).		Version 0 is reserved as the initial state (empty/null).
	* A tag identifies the content of a node. A tag has the same format		* A tag identifies the content of a node. A tag has the same format
	as the "tag" field in Section 10.3 of [RFC7285] and is valid only		as the "tag" field in Section 10.3 of [RFC7285] and is valid only
	within the scope of the resource.		within the scope of the resource.
	* Each edge is an update item. In particular, the edge from i to j		* Each edge is an update item. In particular, the edge from i to j
	is the update item to transit from version i to version j.		is the update item to transit from version i to version j.
	* The version is path independent, i.e., different paths arriving at		* The version is path independent, i.e., different paths arriving at
	the node associated with the same version have the same content).		the node associated with the same version have the same content.
	A concrete example is shown in Figure 2. There are seven nodes in		A concrete example is shown in Figure 2. There are seven nodes in
	the graph, representing seven different versions of the resource.		the graph, representing seven different versions of the resource.
	Edges in the figure represent the updates from the source version to		Edges in the figure represent the updates from the source version to
	the target version. Thick lines represent mandatory incremental		the target version. Thick lines represent mandatory incremental
	updates (e.g., ID103-104), dotted lines represent optional		updates (e.g., ID103-104), dotted lines represent optional
	incremental updates (e.g., ID103-105), and thin lines represent		incremental updates (e.g., ID103-105), and thin lines represent
	snapshots (e.g., ID0-103). Note that node content is path		snapshots (e.g., ID0-103). Note that node content is path
	independent: the content of node v can be obtained by applying the		independent: the content of node v can be obtained by applying the
	updates from any path that ends at v. For example, assume the latest		updates from any path that ends at v. For example, assume the latest
	skipping to change at line 504 ¶		skipping to change at line 504 ¶
	ID105-106 ||		ID105-106 ||
	\/		\/
	+======+		+======+
	tag: 6470983 -> | 106 |		tag: 6470983 -> | 106 |
	+======+		+======+
	Figure 2: TIPS Model Example		Figure 2: TIPS Model Example
	3.2. Updates Graph Modification Invariants		3.2. Updates Graph Modification Invariants
	A server may change its updates graph (to compact it, to add nodes,		A server might change its updates graph (to compact it, to add nodes,
	etc.), but it must ensure that any resource state that it makes		etc.), but it will need to ensure that any resource state that it
	available is reachable by clients, either directly via a snapshot		makes available is reachable by clients, either directly via a
	(that is, relative to 0) or indirectly by requesting an earlier		snapshot (that is, relative to 0) or indirectly by requesting an
	snapshot and a contiguous set of incremental updates. Additionally,		earlier snapshot and a contiguous set of incremental updates.
	to allow clients to proactively construct URIs for future update		Additionally, to allow clients to proactively construct URIs for
	items, the ID of each added node in the updates graph must increment		future update items, the ID of each added node in the updates graph
	contiguously by 1. More specifically, the updates graph MUST satisfy		will need to increment contiguously by 1. More specifically, the
	the following invariants:		updates graph MUST satisfy the following invariants:
	Continuity: At any time, let ns denote the smallest non-zero version		Continuity: At any time, let ns denote the smallest non-zero version
	(i.e., <start-seq>) in the updates graph and let ne denote the		(i.e., <start-seq>) in the updates graph and let ne denote the
	latest version (i.e., <end-seq>). Then, any version in between ns		latest version (i.e., <end-seq>). Then, any version in between ns
	and ne MUST also exist. This implies that the incremental update		and ne MUST also exist. This implies that the incremental update
	from ni to ni + 1 exists for any ns <= ni <= ne, and all the		from ni to ni + 1 exists for any ns <= ni <= ne, and all the
	version numbers in the updates graph (except 0) constitute exactly		version numbers in the updates graph (except 0) constitute exactly
	the integer interval [ns, ne].		the integer interval [ns, ne].
	Feasibility: Let ns denote <start-seq> in the updates graph. The		Feasibility: Let ns denote <start-seq> in the updates graph. The
	skipping to change at line 566 ¶		skipping to change at line 566 ¶
	the request from the client to monitor the updates of an ALTO		the request from the client to monitor the updates of an ALTO
	resource, it creates a TIPS view resource and returns the		resource, it creates a TIPS view resource and returns the
	corresponding information to the client. The URI points to that		corresponding information to the client. The URI points to that
	specific TIPS-V instance, and the summary contains the <start-seq>		specific TIPS-V instance, and the summary contains the <start-seq>
	and <end-seq> of the updates graph and a server-recommended edge to		and <end-seq> of the updates graph and a server-recommended edge to
	consume first (e.g., from i to j).		consume first (e.g., from i to j).
	An ALTO client can then continuously pull each additional update with		An ALTO client can then continuously pull each additional update with
	the information. For example, the client in Figure 3 first fetches		the information. For example, the client in Figure 3 first fetches
	the update from i to j and then from j to j+1. Note that the update		the update from i to j and then from j to j+1. Note that the update
	item at "<tips-view-uri>/ug/<j>/<j+1>" may not yet exist, so the		item at "<tips-view-uri>/ug/<j>/<j+1>" might not yet exist, so the
	server holds the request until the update becomes available (i.e.,		server holds the request until the update becomes available (i.e.,
	long polling).		long polling).
	A server MAY close a TIPS view at any time (e.g., under high system		A server MAY close a TIPS view at any time (e.g., under high system
	load or due to client inactivity). In the event that a TIPS view is		load or due to client inactivity). In the event that a TIPS view is
	closed, an edge request will receive error code 404 (Not Found) in		closed, an edge request will receive error code 404 (Not Found) in
	response, and the client will have to request a new TIPS view URI.		response, and the client will have to request a new TIPS view URI.
	If resources allow, a server SHOULD avoid closing TIPS views that		If resources allow, a server SHOULD avoid closing TIPS views that
	have active polling edge requests or have recently served responses		have active polling edge requests or have recently served responses
	skipping to change at line 839 ¶		skipping to change at line 839 ¶
	support concurrent retrieval of multiple resources such as "my-		support concurrent retrieval of multiple resources such as "my-
	network-map" and "my-routingcost-map" using multiple HTTP/2 streams.		network-map" and "my-routingcost-map" using multiple HTTP/2 streams.
	The resource "update-my-costs-tips" provides an ALTO TIPS information		The resource "update-my-costs-tips" provides an ALTO TIPS information
	resource, and this is indicated by the media type "application/alto-		resource, and this is indicated by the media type "application/alto-
	tips+json".		tips+json".
	6. TIPS Management		6. TIPS Management
	Upon request, a server sends a TIPS view to a client. This TIPS view		Upon request, a server sends a TIPS view to a client. This TIPS view
	may be created at the time of the request or may already exist		might be created at the time of the request or might already exist
	(either because another client has already created a TIPS view for		(either because another client has already created a TIPS view for
	the same requested network resource or because the server perpetually		the same requested network resource or because the server perpetually
	maintains a TIPS view for an often-requested resource).		maintains a TIPS view for an often-requested resource).
	6.1. Open Request		6.1. Open Request
	An ALTO client requests that the server provide a TIPS view for a		An ALTO client requests that the server provide a TIPS view for a
	given resource by sending an HTTP POST body with the media type		given resource by sending an HTTP POST body with the media type
	"application/alto-tipsparams+json". That body contains a JSON object		"application/alto-tipsparams+json". That body contains a JSON object
	of the TIPSReq type, where:		of the TIPSReq type, where:
	skipping to change at line 941 ¶		skipping to change at line 941 ¶
	A server MUST NOT use the same URI for different TIPS views,		A server MUST NOT use the same URI for different TIPS views,
	either for different resources or for different request bodies to		either for different resources or for different request bodies to
	the same resource. URI generation is implementation specific; for		the same resource. URI generation is implementation specific; for
	example, one may compute a Universally Unique Identifier (UUID)		example, one may compute a Universally Unique Identifier (UUID)
	[RFC4122] or a hash value based on the request and append it to a		[RFC4122] or a hash value based on the request and append it to a
	base URL. For performance considerations, it is NOT RECOMMENDED		base URL. For performance considerations, it is NOT RECOMMENDED
	to use properties that are not included in the request body to		to use properties that are not included in the request body to
	determine the URI of a TIPS view, such as cookies or the client's		determine the URI of a TIPS view, such as cookies or the client's
	IP address, which may result in duplicated TIPS views in cases		IP address, which may result in duplicated TIPS views in cases
	such as mobile clients. However, this is not mandatory as a		such as mobile clients. However, this is not mandatory as a
	server may intentionally use client information to compute the		server might intentionally use client information to compute the
	TIPS view URI to provide service isolation between clients.		TIPS view URI to provide service isolation between clients.
	tips-view-summary: Contains an updates-graph-summary.		tips-view-summary: Contains an updates-graph-summary.
	The "updates-graph-summary" field contains the <start-seq> of the		The "updates-graph-summary" field contains the <start-seq> of the
	updates graph (in the "start-seq" field) and the <end-seq> that is		updates graph (in the "start-seq" field) and the <end-seq> that is
	currently available (in the "end-seq" field), along with a		currently available (in the "end-seq" field), along with a
	recommended edge to consume (in the "start-edge-rec" field). If		recommended edge to consume (in the "start-edge-rec" field). If
	the client does not provide a version tag, the server MUST		the client does not provide a version tag, the server MUST
	recommend the edge of the latest available snapshot. If the		recommend the edge of the latest available snapshot. If the
	skipping to change at line 1125 ¶		skipping to change at line 1125 ¶
	{....}		{....}
	Figure 12: Open Example with Digest Authentication		Figure 12: Open Example with Digest Authentication
	6.3.3. Example Using ALTO/SSE		6.3.3. Example Using ALTO/SSE
	This section gives an example of receiving incremental updates of the		This section gives an example of receiving incremental updates of the
	TIPS view summary using ALTO/SSE [RFC8895]. Consider the "tips-sse"		TIPS view summary using ALTO/SSE [RFC8895]. Consider the "tips-sse"
	resource, as announced by the IRD in Figure 6, which provides ALTO/		resource, as announced by the IRD in Figure 6, which provides ALTO/
	SSE for the "update-my-cost-tips" resource; a client may send the		SSE for the "update-my-cost-tips" resource; a client might send the
	following request to receive updates of the TIPS view (authentication		following request to receive updates of the TIPS view (authentication
	is omitted for simplicity).		is omitted for simplicity).
	POST /updates/tips HTTP/1.1		POST /updates/tips HTTP/1.1
	Host: alto.example.com		Host: alto.example.com
	Accept: text/event-stream,application/alto-error+json		Accept: text/event-stream,application/alto-error+json
	Content-Type: application/alto-updatestreamparams+json		Content-Type: application/alto-updatestreamparams+json
	Content-Length: 76		Content-Length: 76
	{		{
	skipping to change at line 1210 ¶		skipping to change at line 1210 ¶
	Section 7.3 for a concrete example.		Section 7.3 for a concrete example.
	7.2. Response		7.2. Response
	If the request is valid (i.e., "ug/<i>/<j>" exists), the response is		If the request is valid (i.e., "ug/<i>/<j>" exists), the response is
	encoded as a JSON object whose data format is indicated by the media		encoded as a JSON object whose data format is indicated by the media
	type.		type.
	A client MAY conduct proactive fetching of future updates, by long		A client MAY conduct proactive fetching of future updates, by long
	polling updates that have not been provided in the directory yet.		polling updates that have not been provided in the directory yet.
	For such updates, the client MUST indicate all media types that may		For such updates, the client MUST indicate all media types that might
	appear. It is RECOMMENDED that the server allow for at least the		appear. It is RECOMMENDED that the server allow for at least the
	long polling of <end-seq> -> <end-seq + 1>.		long polling of <end-seq> -> <end-seq + 1>.
	Hence, the server processing logic MUST be:		Hence, the server processing logic MUST be:
	* If a resource with path "ug/<i>/<j>" exists, return content using		* If a resource with path "ug/<i>/<j>" exists, return content using
	encoding.		encoding.
	* Else, if long polling "ug/<i>/<j>" is acceptable, put request in a		* Else, if long polling "ug/<i>/<j>" is acceptable, put request in a
	backlog queue, then either a response is triggered when the		backlog queue, then either a response is triggered when the
	skipping to change at line 1277 ¶		skipping to change at line 1277 ¶
	Figure 15: Response to a GET Request		Figure 15: Response to a GET Request
	7.4. New Next Edge Recommendation		7.4. New Next Edge Recommendation
	While intended TIPS usage is for the client to receive a recommended		While intended TIPS usage is for the client to receive a recommended
	starting edge in the TIPS summary, consume that edge, and then		starting edge in the TIPS summary, consume that edge, and then
	construct all future URIs by incrementing the sequence count by one,		construct all future URIs by incrementing the sequence count by one,
	there may be cases in which the client needs to request a new next		there may be cases in which the client needs to request a new next
	edge to consume. For example, if a client has an open TIPS view but		edge to consume. For example, if a client has an open TIPS view but
	has not polled in a while, the client may request the next logical		has not polled in a while, the client might request the next logical
	incremental URI; however, the server has compacted the updates graph,		incremental URI; however, the server has compacted the updates graph,
	so it no longer exists. Thus, the client MAY request a new next edge		so it no longer exists. Thus, the client MAY request a new next edge
	to consume based on its current version of the resource.		to consume based on its current version of the resource.
	7.4.1. Request		7.4.1. Request
	An ALTO client requests that the server provide a next edge		An ALTO client requests that the server provide a next edge
	recommendation for a given TIPS view by sending an HTTP POST request		recommendation for a given TIPS view by sending an HTTP POST request
	with the media type "application/alto-tipsparams+json". The URL of		with the media type "application/alto-tipsparams+json". The URL of
	the request MUST have the following format:		the request MUST have the following format:
	skipping to change at line 1403 ¶		skipping to change at line 1403 ¶
	application layer or at the infrastructure layer. For example, an		application layer or at the infrastructure layer. For example, an
	ALTO server MAY set <tips-view-host> to different subdomains to		ALTO server MAY set <tips-view-host> to different subdomains to
	distribute TIPS views or simply use the same host of the TIPS		distribute TIPS views or simply use the same host of the TIPS
	information resource and rely on load balancers to distribute the		information resource and rely on load balancers to distribute the
	load.		load.
	TIPS allows a client to make concurrent pulls of incremental updates		TIPS allows a client to make concurrent pulls of incremental updates
	for the same TIPS view, potentially through different HTTP		for the same TIPS view, potentially through different HTTP
	connections. As a consequence, TIPS introduces additional		connections. As a consequence, TIPS introduces additional
	complexities when the ALTO server balances the load by distributing		complexities when the ALTO server balances the load by distributing
	the requests to a set of backend servers. For example, a request may		the requests to a set of backend servers. For example, a request
	be directed to the wrong backend server and get processed incorrectly		might be directed to the wrong backend server and get processed
	if the following two conditions both hold:		incorrectly if the following two conditions both hold:
	* these backend servers are stateful (i.e., the TIPS view is created		* these backend servers are stateful (i.e., the TIPS view is created
	and stored only on a single server); and		and stored only on a single server); and
	* the ALTO server is using Layer 4 load balancing (i.e., the		* the ALTO server is using Layer 4 load balancing (i.e., the
	requests are distributed based on the TCP 5-tuple).		requests are distributed based on the TCP 5-tuple).
	Thus, additional considerations are required to enable correct load		Thus, additional considerations are required to enable correct load
	balancing for TIPS, including:		balancing for TIPS, including:
	skipping to change at line 1561 ¶		skipping to change at line 1561 ¶
	service.		service.
	To avoid such attacks, the server MAY choose to limit the number of		To avoid such attacks, the server MAY choose to limit the number of
	active views and reject new requests when that threshold is reached.		active views and reject new requests when that threshold is reached.
	TIPS allows predictive fetching and the server MAY also choose to		TIPS allows predictive fetching and the server MAY also choose to
	limit the number of pending requests. If a new request exceeds the		limit the number of pending requests. If a new request exceeds the
	threshold, the server MAY log the event and return the HTTP status		threshold, the server MAY log the event and return the HTTP status
	429 (Too Many Requests).		429 (Too Many Requests).
	It is important to note that the preceding approaches are not the		It is important to note that the preceding approaches are not the
	only possibilities. For example, it may be possible for a TIPS		only possibilities. For example, it might be possible for a TIPS
	server to use somewhat more clever logic involving TIPS view eviction		server to use somewhat more clever logic involving TIPS view eviction
	policies, IP reputation, rate-limiting, and compartmentalization of		policies, IP reputation, rate-limiting, and compartmentalization of
	the overall threshold into smaller thresholds that apply to subsets		the overall threshold into smaller thresholds that apply to subsets
	of potential clients. If service availability is a concern, ALTO		of potential clients. If service availability is a concern, ALTO
	clients MAY establish service level agreements with the ALTO server.		clients MAY establish service level agreements with the ALTO server.
	9.2. ALTO Client: Update Overloading or Instability		9.2. ALTO Client: Update Overloading or Instability
	The availability of continuous updates can also cause overload for an		The availability of continuous updates can also cause overload for an
	ALTO client, in particular, an ALTO client with limited processing		ALTO client, in particular, an ALTO client with limited processing
	capabilities. The current design does not include any flow control		capabilities. The current design does not include any flow control
	mechanisms for the client to reduce the update rates from the server.		mechanisms for the client to reduce the update rates from the server.
	For example, TCP, HTTP/2, and QUIC provide stream and connection flow		For example, TCP, HTTP/2, and QUIC provide stream and connection flow
	control data limits, which might help prevent the client from being		control data limits, which might help prevent the client from being
	overloaded. Under overloading, the client MAY choose to remove the		overloaded. Under overloading, the client MAY choose to remove the
	information resources with high update rates.		information resources with high update rates.
	Also, under overloading, the client may no longer be able to detect		Also, under overloading, the client might no longer be able to detect
	whether information is still fresh or has become stale. In such a		whether information is still fresh or has become stale. In such a
	case, the client should be careful in how it uses the information to		case, the client should be careful in how it uses the information to
	avoid stability or efficiency issues.		avoid stability or efficiency issues.
	10. IANA Considerations		10. IANA Considerations
	IANA has registered the following media types from the registry		IANA has registered the following media types from the registry
	available at [IANA-Media-Type]:		available at [IANA-Media-Type]:
	* application/alto-tips+json: as described in Section 6.2;		* application/alto-tips+json: as described in Section 6.2;
	skipping to change at line 1808 ¶		skipping to change at line 1808 ¶
	Design 3 (Dir + Data): R2 and R3 must remain together, though R1		Design 3 (Dir + Data): R2 and R3 must remain together, though R1
	might not be on the same server.		might not be on the same server.
	This document supports Designs 1 and 3. For Design 1, the ALTO		This document supports Designs 1 and 3. For Design 1, the ALTO
	server simply needs to always use the same host for the TIPS views.		server simply needs to always use the same host for the TIPS views.
	For Design 3, the ALTO server can set tips-view-host to a different		For Design 3, the ALTO server can set tips-view-host to a different
	server. Note that the deployment flexibility is at the logical		server. Note that the deployment flexibility is at the logical
	level, as these services can be distinguished by different paths and		level, as these services can be distinguished by different paths and
	potentially be routed to different physical servers by Layer 7 load		potentially be routed to different physical servers by Layer 7 load
	balancing. See Section 8.1 for a discussion on load balancing		balancing. See Section 8.1 for a discussion on load balancing
	considerations. Future documents may extend the protocol to support		considerations. Future documents could extend the protocol to
	Design 2.		support Design 2.
	Appendix B. Conformance with "Building Protocols with HTTP" (RFC 9205)		Appendix B. Conformance with "Building Protocols with HTTP" (RFC 9205)
	Best Current Practices		Best Current Practices
	This specification adheres fully to [RFC9205] as further elaborated		This specification adheres fully to [RFC9205] as further elaborated
	below:		below:
	* TIPS does not (as described in Section 3.1 of [RFC9205]):		* TIPS does not (as described in Section 3.1 of [RFC9205]):
	| ...redefine, refine, or overlay the semantics of generic		| ...redefine, refine, or overlay the semantics of generic
	skipping to change at line 1868 ¶		skipping to change at line 1868 ¶
	(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 of
	| the assumptions of HTTP as a stateless protocol and will cause		| the assumptions of HTTP as a stateless protocol and will cause
	| problems in interoperability, security, operability, and		| problems in interoperability, security, operability, and
	| evolution.		| evolution.
	The only relationship between requests is that a client must first		The only relationship between requests is that a client has to
	discover where a TIPS view of a resource will be served, which is		first discover where a TIPS view of a resource will be served,
	consistent with the URI discovery in Section 4.4.1 of [RFC9205].		which is consistent with the URI discovery in Section 4.4.1 of
			[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
	current best practice of building such a service using basic HTTP.		current best practice of building such a service using basic HTTP.
	Earlier versions of this document had investigated the possibility of		Earlier versions of this document had investigated the possibility of
	enabling push-mode TIPS (i.e., by taking advantage of the server push		enabling push-mode TIPS (i.e., by taking advantage of the server push
	feature in HTTP/2 and HTTP/3).		feature in HTTP/2 and HTTP/3).
	skipping to change at line 1898 ¶		skipping to change at line 1899 ¶
	Appendix D. Persistent HTTP Connections		Appendix D. Persistent HTTP Connections
	Previous draft versions of this document use persistent HTTP		Previous draft versions of this document use persistent HTTP
	connections to detect the liveness of clients. However, this design		connections to detect the liveness of clients. However, this design
	does not conform well with the best current practices of HTTP. For		does not conform well with the best current practices of HTTP. For
	example, if an ALTO client is accessing a TIPS view over an HTTP		example, if an ALTO client is accessing a TIPS view over an HTTP
	proxy, the connection is not established directly between the ALTO		proxy, the connection is not established directly between the ALTO
	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 may 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 Adoba, 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,
End of changes. 14 change blocks.
	27 lines changed or deleted		28 lines changed or added
This html diff was produced by rfcdiff 1.48.