draft-ietf-taps-interface-18.txt		draft-ietf-taps-interface-19.txt
	TAPS Working Group B. Trammell, Ed.		TAPS Working Group B. Trammell, Ed.
	Internet-Draft Google Switzerland GmbH		Internet-Draft Google Switzerland GmbH
	Intended status: Standards Track M. Welzl, Ed.		Intended status: Standards Track M. Welzl, Ed.
	Expires: 27 April 2023 University of Oslo		Expires: 10 September 2023 University of Oslo
	T. Enghardt		T. Enghardt
	Netflix		Netflix
	G. Fairhurst		G. Fairhurst
	University of Aberdeen		University of Aberdeen
	M. Kuehlewind		M. Kuehlewind
	Ericsson		Ericsson
	C. Perkins		C. Perkins
	University of Glasgow		University of Glasgow
	P. Tiesel		P. Tiesel
	SAP SE		SAP SE
	T. Pauly		T. Pauly
	Apple Inc.		Apple Inc.
	24 October 2022		9 March 2023
	An Abstract Application Layer Interface to Transport Services		An Abstract Application Layer Interface to Transport Services
	draft-ietf-taps-interface-18		draft-ietf-taps-interface-19
	Abstract		Abstract
	This document describes an abstract application programming		This document describes an abstract application programming
	interface, API, to the transport layer that enables the selection of		interface, API, to the transport layer that enables the selection of
	transport protocols and network paths dynamically at runtime. This		transport protocols and network paths dynamically at runtime. This
	API enables faster deployment of new protocols and protocol features		API enables faster deployment of new protocols and protocol features
	without requiring changes to the applications. The specified API		without requiring changes to the applications. The specified API
	follows the Transport Services architecture by providing		follows the Transport Services architecture by providing
	asynchronous, atomic transmission of messages. It is intended to		asynchronous, atomic transmission of messages. It is intended to
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 27 April 2023.		This Internet-Draft will expire on 10 September 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2023 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 38 ¶
	8. Managing Connections . . . . . . . . . . . . . . . . . . . . 45		8. Managing Connections . . . . . . . . . . . . . . . . . . . . 45
	8.1. Generic Connection Properties . . . . . . . . . . . . . . 47		8.1. Generic Connection Properties . . . . . . . . . . . . . . 47
	8.1.1. Required Minimum Corruption Protection Coverage for		8.1.1. Required Minimum Corruption Protection Coverage for
	Receiving . . . . . . . . . . . . . . . . . . . . . . 47		Receiving . . . . . . . . . . . . . . . . . . . . . . 47
	8.1.2. Connection Priority . . . . . . . . . . . . . . . . . 48		8.1.2. Connection Priority . . . . . . . . . . . . . . . . . 48
	8.1.3. Timeout for Aborting Connection . . . . . . . . . . . 48		8.1.3. Timeout for Aborting Connection . . . . . . . . . . . 48
	8.1.4. Timeout for keep alive packets . . . . . . . . . . . 48		8.1.4. Timeout for keep alive packets . . . . . . . . . . . 48
	8.1.5. Connection Group Transmission Scheduler . . . . . . . 49		8.1.5. Connection Group Transmission Scheduler . . . . . . . 49
	8.1.6. Capacity Profile . . . . . . . . . . . . . . . . . . 49		8.1.6. Capacity Profile . . . . . . . . . . . . . . . . . . 49
	8.1.7. Policy for using Multipath Transports . . . . . . . . 51		8.1.7. Policy for using Multipath Transports . . . . . . . . 51
	8.1.8. Bounds on Send or Receive Rate . . . . . . . . . . . 51		8.1.8. Bounds on Send or Receive Rate . . . . . . . . . . . 52
	8.1.9. Group Connection Limit . . . . . . . . . . . . . . . 52		8.1.9. Group Connection Limit . . . . . . . . . . . . . . . 52
	8.1.10. Isolate Session . . . . . . . . . . . . . . . . . . . 52		8.1.10. Isolate Session . . . . . . . . . . . . . . . . . . . 52
	8.1.11. Read-only Connection Properties . . . . . . . . . . . 53		8.1.11. Read-only Connection Properties . . . . . . . . . . . 53
	8.2. TCP-specific Properties: User Timeout Option (UTO) . . . 54		8.2. TCP-specific Properties: User Timeout Option (UTO) . . . 54
	8.2.1. Advertised User Timeout . . . . . . . . . . . . . . . 54		8.2.1. Advertised User Timeout . . . . . . . . . . . . . . . 54
	8.2.2. User Timeout Enabled . . . . . . . . . . . . . . . . 54		8.2.2. User Timeout Enabled . . . . . . . . . . . . . . . . 54
	8.2.3. Timeout Changeable . . . . . . . . . . . . . . . . . 55		8.2.3. Timeout Changeable . . . . . . . . . . . . . . . . . 55
	8.3. Connection Lifecycle Events . . . . . . . . . . . . . . . 55		8.3. Connection Lifecycle Events . . . . . . . . . . . . . . . 55
	8.3.1. Soft Errors . . . . . . . . . . . . . . . . . . . . . 55		8.3.1. Soft Errors . . . . . . . . . . . . . . . . . . . . . 55
	8.3.2. Path change . . . . . . . . . . . . . . . . . . . . . 55		8.3.2. Path change . . . . . . . . . . . . . . . . . . . . . 55
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 16 ¶
	Selection Properties can be queried on Connections and Messages.		Selection Properties can be queried on Connections and Messages.
	Connection Properties can be set on Connections and Preconnections;		Connection Properties can be set on Connections and Preconnections;
	when set on Preconnections, they act as an initial default for the		when set on Preconnections, they act as an initial default for the
	resulting Connections. Message Properties can be set on Messages,		resulting Connections. Message Properties can be set on Messages,
	Connections, and Preconnections; when set on the latter two, they act		Connections, and Preconnections; when set on the latter two, they act
	as an initial default for the Messages sent over those Connections,		as an initial default for the Messages sent over those Connections,
	Note that configuring Connection Properties and Message Properties on		Note that configuring Connection Properties and Message Properties on
	Preconnections is preferred over setting them later. Early		Preconnections is preferred over setting them later. Early
	specification of Connection Properties allows their use as additional		specification of Connection Properties allows their use as additional
	input to the selection process. Protocol Specific Properties, which		input to the selection process. Protocol-specific Properties, which
	enable configuration of specialized features of a specific protocol,		enable configuration of specialized features of a specific protocol,
	see Section 3.2 of [I-D.ietf-taps-arch], are not used as an input to		see Section 3.2 of [I-D.ietf-taps-arch], are not used as an input to
	the selection process, but only support configuration if the		the selection process, but only support configuration if the
	respective protocol has been selected.		respective protocol has been selected.
	4.1. Transport Property Names		4.1. Transport Property Names
	Transport Properties are referred to by property names. For the		Transport Properties are referred to by property names. For the
	purposes of this document, these names are alphanumeric strings in		purposes of this document, these names are alphanumeric strings in
	which words may be separated by hyphens. Specifically, the following		which words may be separated by hyphens. Specifically, the following
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 5 ¶
	the consistency resulting from the use of visually similar		the consistency resulting from the use of visually similar
	symbols.		symbols.
	Transport Property Names are hierarchically organized in the form		Transport Property Names are hierarchically organized in the form
	[<Namespace>.]<PropertyName>.		[<Namespace>.]<PropertyName>.
	* The Namespace component MUST be empty for well-known, generic		* The Namespace component MUST be empty for well-known, generic
	properties, i.e., for properties that are not specific to a		properties, i.e., for properties that are not specific to a
	protocol and are defined in an RFC.		protocol and are defined in an RFC.
	* Protocol Specific Properties MUST use the protocol acronym as the		* Protocol-specific Properties MUST use the protocol acronym as the
	Namespace, e.g., tcp for TCP specific Transport Properties. For		Namespace (e.g., a tcp Connection could support a TCP-specific
	IETF protocols, property names under these namespaces SHOULD be		Transport Property, such as the user timeout value, in a Protocol-
	defined in an RFC.		specific Property called tcp.userTimeoutValue (see Section 8.2).
	* Vendor or implementation specific properties MUST use a string		* Vendor or implementation specific properties MUST use a string
	identifying the vendor or implementation as the Namespace.		identifying the vendor or implementation as the Namespace.
			* For IETF protocols, the name of a Protocol-specific Property
			SHOULD be specified in an IETF document published in the RFC
			Series.
	Namespaces for each of the keywords provided in the IANA protocol		Namespaces for each of the keywords provided in the IANA protocol
	numbers registry (see https://www.iana.org/assignments/protocol-		numbers registry (see https://www.iana.org/assignments/protocol-
	numbers/protocol-numbers.xhtml) are reserved for Protocol Specific		numbers/protocol-numbers.xhtml) are reserved for Protocol-specific
	Properties and MUST NOT be used for vendor or implementation-specific		Properties and MUST NOT be used for vendor or implementation-specific
	properties. Avoid using any of the terms listed as keywords in the		properties. Avoid using any of the terms listed as keywords in the
	protocol numbers registry as any part of a vendor- or implementation-		protocol numbers registry as any part of a vendor- or implementation-
	specific property name.		specific property name.
	4.2. Transport Property Types		4.2. Transport Property Types
	Each Transport Property has one of the basic types described in		Each Transport Property has one of the basic types described in
	Section 1.1.		Section 1.1.
	skipping to change at page 18, line 40 ¶		skipping to change at page 18, line 40 ¶
	* Interface name (string), e.g., to qualify link-local or multicast		* Interface name (string), e.g., to qualify link-local or multicast
	addresses (see Section 6.1.2 for details):		addresses (see Section 6.1.2 for details):
	LocalSpecifier.WithInterface("en0")		LocalSpecifier.WithInterface("en0")
	Note that an IPv6 address specified with a scope (e.g.		Note that an IPv6 address specified with a scope (e.g.
	2001:db8:4920:e29d:a420:7461:7073:0a%en0) is equivalent to		2001:db8:4920:e29d:a420:7461:7073:0a%en0) is equivalent to
	WithIPv6Address with an unscoped address and WithInterface together.		WithIPv6Address with an unscoped address and WithInterface together.
	An Endpoint cannot have multiple identifiers of a same type set.		An Endpoint MUST NOT be configured with multiple identifiers of the
	That is, an endpoint cannot have two IP addresses specified. Two		same type. For example, an endpoint cannot have two IP addresses
	separate IP addresses are represented as two Endpoint Objects. If a		specified. Two separate IP addresses are represented as two Endpoint
	Preconnection specifies a Remote Endpoint with a specific IP address		Objects. If a Preconnection specifies a Remote Endpoint with a
	set, it will only establish Connections to that IP address. If, on		specific IP address set, it will only establish Connections to that
	the other hand, the Remote Endpoint specifies a hostname but no		IP address. If, on the other hand, the Remote Endpoint specifies a
	addresses, the Connection can perform name resolution and attempt		hostname but no addresses, the Connection can perform name resolution
	using any address derived from the original hostname of the Remote		and attempt using any address derived from the original hostname of
	Endpoint. Note that multiple Remote Endpoints can be added to a		the Remote Endpoint. Note that multiple Remote Endpoints can be
	Preconnection, as discussed in Section 7.5.		added to a Preconnection, as discussed in Section 7.5.
	The Transport Services system resolves names internally, when the		The Transport Services system resolves names internally, when the
	Initiate(), Listen(), or Rendezvous() method is called to establish a		Initiate(), Listen(), or Rendezvous() method is called to establish a
	Connection. Privacy considerations for the timing of this resolution		Connection. Privacy considerations for the timing of this resolution
	are given in Section 13.		are given in Section 13.
	The Resolve() action on a Preconnection can be used by the		The Resolve() action on a Preconnection can be used by the
	application to force early binding when required, for example with		application to force early binding when required, for example with
	some Network Address Translator (NAT) traversal protocols (see		some Network Address Translator (NAT) traversal protocols (see
	Section 7.3).		Section 7.3).
	skipping to change at page 43, line 45 ¶		skipping to change at page 43, line 45 ¶
	all others. For example, changing connTimeout (see Section 8.1.3) on		all others. For example, changing connTimeout (see Section 8.1.3) on
	one Connection in a Connection Group will automatically make the same		one Connection in a Connection Group will automatically make the same
	change to this Connection Property for all other Connections in the		change to this Connection Property for all other Connections in the
	Connection Group. Like all other Properties, connPriority is copied		Connection Group. Like all other Properties, connPriority is copied
	to the new Connection when calling Clone(), but in this case, a later		to the new Connection when calling Clone(), but in this case, a later
	change to the connPriority on one Connection does not change it on		change to the connPriority on one Connection does not change it on
	the other Connections in the same Connection Group.		the other Connections in the same Connection Group.
	The optional connectionProperties parameter allows passing Transport		The optional connectionProperties parameter allows passing Transport
	Properties that control the behavior of the underlying stream or		Properties that control the behavior of the underlying stream or
	connection to be created, e.g., protocol-specific properties to		connection to be created, e.g., Protocol-specific Properties to
	request specific stream IDs for SCTP or QUIC.		request specific stream IDs for SCTP or QUIC.
	Message Properties set on a Connection also apply only to that		Message Properties set on a Connection also apply only to that
	Connection.		Connection.
	A new Connection created by Clone can have a Message Framer assigned		A new Connection created by Clone can have a Message Framer assigned
	via the optional framer parameter of the Clone Action. If this		via the optional framer parameter of the Clone Action. If this
	parameter is not supplied, the stack of Message Framers associated		parameter is not supplied, the stack of Message Framers associated
	with a Connection is copied to the cloned Connection when calling		with a Connection is copied to the cloned Connection when calling
	Clone. Then, a cloned Connection has the same stack of Message		Clone. Then, a cloned Connection has the same stack of Message
	skipping to change at page 46, line 8 ¶		skipping to change at page 46, line 8 ¶
	information may be available about the state of the connection via		information may be available about the state of the connection via
	Soft Errors.		Soft Errors.
	Connection Properties represent the configuration and state of the		Connection Properties represent the configuration and state of the
	selected Protocol Stack(s) backing a Connection. These Connection		selected Protocol Stack(s) backing a Connection. These Connection
	Properties may be Generic, applying regardless of transport protocol,		Properties may be Generic, applying regardless of transport protocol,
	or Specific, applicable to a single implementation of a single		or Specific, applicable to a single implementation of a single
	transport protocol stack. Generic Connection Properties are defined		transport protocol stack. Generic Connection Properties are defined
	in Section 8.1 below.		in Section 8.1 below.
	Protocol Specific Properties are defined in a transport- and		Protocol-specific Properties are defined in a transport- and
	implementation-specific way to permit more specialized protocol		implementation-specific way to permit more specialized protocol
	features to be used. Too much reliance by an application on Protocol		features to be used. Too much reliance by an application on
	Specific Properties can significantly reduce the flexibility of a		Protocol-specific Properties can significantly reduce the flexibility
	transport services implementation to make appropriate selection and		of a transport services implementation to make appropriate selection
	configuration choices. Therefore, it is RECOMMENDED that Protocol		and configuration choices. Therefore, it is RECOMMENDED that
	Properties are used for properties common across different protocols		Protocol-specific Properties are used for properties common across
	and that Protocol Specific Properties are only used where specific		different protocols and that Protocol-specific Properties are only
	protocols or properties are necessary.		used where specific protocols or properties are necessary.
	The application can set and query Connection Properties on a per-		The application can set and query Connection Properties on a per-
	Connection basis. Connection Properties that are not read-only can		Connection basis. Connection Properties that are not read-only can
	be set during pre-establishment (see Section 6.2), as well as on		be set during pre-establishment (see Section 6.2), as well as on
	connections directly using the SetProperty action:		connections directly using the SetProperty action:
	Connection.SetProperty(property, value)		Connection.SetProperty(property, value)
	Note that changing one of the Connection Properties on one Connection		Note that changing one of the Connection Properties on one Connection
	in a Connection Group will also change it for all other Connections		in a Connection Group will also change it for all other Connections
	skipping to change at page 47, line 45 ¶		skipping to change at page 48, line 4 ¶
	that enables applications to express their preference for protocols		that enables applications to express their preference for protocols
	providing a supporting transport feature.		providing a supporting transport feature.
	8.1.1. Required Minimum Corruption Protection Coverage for Receiving		8.1.1. Required Minimum Corruption Protection Coverage for Receiving
	Name: recvChecksumLen		Name: recvChecksumLen
	Type: Integer (non-negative) or Full Coverage		Type: Integer (non-negative) or Full Coverage
	Default: Full Coverage		Default: Full Coverage
	If this property is an Integer, it specifies the minimum number of		If this property is an Integer, it specifies the minimum number of
	bytes in a received message that need to be covered by a checksum. A		bytes in a received message that need to be covered by a checksum. A
	receiving endpoint will not forward messages that have less coverage		receiving endpoint will not forward messages that have less coverage
	to the application. The application is responsible for handling any		to the application. The application is responsible for handling any
	corruption within the non-protected part of the message [RFC8085]. A		corruption within the non-protected part of the message [RFC8085]. A
	special value of 0 means that a received packet may also have a zero		special value of 0 means that a received packet may also have a zero
	checksum field.		checksum field, and the enumerated value Full Coverage means that the
			entire Message needs to be protected by a checksum.
	8.1.2. Connection Priority		8.1.2. Connection Priority
	Name: connPriority		Name: connPriority
	Type: Integer (non-negative)		Type: Integer (non-negative)
	Default: 100		Default: 100
	This property is a non-negative integer representing the priority of		This property is a non-negative integer representing the priority of
	skipping to change at page 48, line 44 ¶		skipping to change at page 49, line 4 ¶
	deliver data to the Remote Endpoint. Adjusting this property will		deliver data to the Remote Endpoint. Adjusting this property will
	only take effect when the underlying stack supports reliability. If		only take effect when the underlying stack supports reliability. If
	this property has the enumerated value Disabled, it means that no		this property has the enumerated value Disabled, it means that no
	timeout is scheduled.		timeout is scheduled.
	8.1.4. Timeout for keep alive packets		8.1.4. Timeout for keep alive packets
	Name: keepAliveTimeout		Name: keepAliveTimeout
	Type: Numeric (non-negative) or Disabled		Type: Numeric (non-negative) or Disabled
			Default: Disabled
	Default: Implementation-defined
	A Transport Services API can request a protocol that supports sending		A Transport Services API can request a protocol that supports sending
	keep alive packets Section 6.2.10. If this property is Numeric, it		keep alive packets Section 6.2.10. If this property is Numeric, it
	specifies the maximum length of time an idle connection (one for		specifies the maximum length of time an idle connection (one for
	which no transport packets have been sent) should wait before the		which no transport packets have been sent) should wait before the
	Local Endpoint sends a keep-alive packet to the Remote Endpoint.		Local Endpoint sends a keep-alive packet to the Remote Endpoint.
	Adjusting this property will only take effect when the underlying		Adjusting this property will only take effect when the underlying
	stack supports sending keep-alive packets. Guidance on setting this		stack supports sending keep-alive packets. Guidance on setting this
	value for connection-less transports is provided in [RFC8085]. A		value for connection-less transports is provided in [RFC8085]. A
	value greater than the connection timeout (Section 8.1.3) or the		value greater than the connection timeout (Section 8.1.3) or the
	skipping to change at page 49, line 34 ¶		skipping to change at page 49, line 42 ¶
	Name: connCapacityProfile		Name: connCapacityProfile
	Type: Enumeration		Type: Enumeration
	Default: Default Profile (Best Effort)		Default: Default Profile (Best Effort)
	This property specifies the desired network treatment for traffic		This property specifies the desired network treatment for traffic
	sent by the application and the tradeoffs the application is prepared		sent by the application and the tradeoffs the application is prepared
	to make in path and protocol selection to receive that desired		to make in path and protocol selection to receive that desired
	treatment. When the capacity profile is set to a value other than		treatment. When the capacity profile is set to a value other than
	Default, z Transport Services system SHOULD select paths and		Default, the Transport Services system SHOULD select paths and
	configure protocols to optimize the tradeoff between delay, delay		configure protocols to optimize the tradeoff between delay, delay
	variation, and efficient use of the available capacity based on the		variation, and efficient use of the available capacity based on the
	capacity profile specified. How this is realized is implementation-		capacity profile specified. How this is realized is implementation-
	specific. The Capacity Profile MAY also be used to set markings on		specific. The Capacity Profile MAY also be used to set markings on
	the wire for Protocol Stacks supporting this. Recommendations for		the wire for Protocol Stacks supporting this. Recommendations for
	use with DSCP are provided below for each profile; note that when a		use with DSCP are provided below for each profile; note that when a
	Connection is multiplexed, the guidelines in Section 6 of [RFC7657]		Connection is multiplexed, the guidelines in Section 6 of [RFC7657]
	apply.		apply.
	The following values are valid for the Capacity Profile:		The following values are valid for the Capacity Profile:
	skipping to change at page 51, line 44 ¶		skipping to change at page 52, line 5 ¶
	the scheduling might choose to use a higher-latency path. Traffic		the scheduling might choose to use a higher-latency path. Traffic
	can be scheduled such that data may be transmitted on multiple		can be scheduled such that data may be transmitted on multiple
	paths in parallel to achieve a lower latency. The specific		paths in parallel to achieve a lower latency. The specific
	scheduling algorithm is implementation-specific.		scheduling algorithm is implementation-specific.
	Aggregate: The connection ought to attempt to use multiple paths in		Aggregate: The connection ought to attempt to use multiple paths in
	parallel to maximize available capacity and possibly overcome the		parallel to maximize available capacity and possibly overcome the
	capacity limitations of the individual paths. The actual strategy		capacity limitations of the individual paths. The actual strategy
	is implementation specific.		is implementation specific.
	Note that this is a local choice - the Remote Endpoint can choose a		Note that this is a local choice – the Remote Endpoint can choose a
	different policy.		different policy.
	8.1.8. Bounds on Send or Receive Rate		8.1.8. Bounds on Send or Receive Rate
	Name: minSendRate / minRecvRate / maxSendRate / maxRecvRate		Name: minSendRate / minRecvRate / maxSendRate / maxRecvRate
	Type: Numeric (non-negative) or Unlimited / Numeric (non-negative)		Type: Numeric (non-negative) or Unlimited / Numeric (non-negative)
	or Unlimited / Numeric (non-negative) or Unlimited / Numeric (non-		or Unlimited / Numeric (non-negative) or Unlimited / Numeric (non-
	negative) or Unlimited		negative) or Unlimited
	skipping to change at page 56, line 27 ¶		skipping to change at page 56, line 27 ¶
	meta-data of the message, including Message Properties (see		meta-data of the message, including Message Properties (see
	Section 9.1.3) and framing meta-data (see Section 9.1.2.2).		Section 9.1.3) and framing meta-data (see Section 9.1.2.2).
	Therefore, a MessageContext object can be passed to the Send action		Therefore, a MessageContext object can be passed to the Send action
	and is returned by each Send and Receive related event.		and is returned by each Send and Receive related event.
	Message Properties can be set and queried using the Message Context:		Message Properties can be set and queried using the Message Context:
	MessageContext.add(property, value)		MessageContext.add(property, value)
	PropertyValue := MessageContext.get(property)		PropertyValue := MessageContext.get(property)
	These Message Properties may be generic properties or Protocol		These Message Properties may be generic properties or Protocol-
	Specific Properties.		specific Properties.
	For MessageContexts returned by send Events (see Section 9.2.2) and		For MessageContexts returned by send Events (see Section 9.2.2) and
	receive Events (see Section 9.3.2), the application can query		receive Events (see Section 9.3.2), the application can query
	information about the Local and Remote Endpoint:		information about the Local and Remote Endpoint:
	RemoteEndpoint := MessageContext.GetRemoteEndpoint()		RemoteEndpoint := MessageContext.GetRemoteEndpoint()
	LocalEndpoint := MessageContext.GetLocalEndpoint()		LocalEndpoint := MessageContext.GetLocalEndpoint()
	9.1.2. Message Framers		9.1.2. Message Framers
	skipping to change at page 60, line 25 ¶		skipping to change at page 60, line 25 ¶
	The following Message Properties are supported:		The following Message Properties are supported:
	9.1.3.1. Lifetime		9.1.3.1. Lifetime
	Name: msgLifetime		Name: msgLifetime
	Type: Numeric (non-negative)		Type: Numeric (non-negative)
	Default: infinite		Default: infinite
	The Lifetime specifies how long a particular Message can wait to be		The Lifetime specifies how long a particular Message can wait in the
	sent to the Remote Endpoint before it is irrelevant and no longer		Transport Services system before it is sent to the Remote Endpoint.
	needs to be (re-)transmitted. This is a hint to the Transport		After this time, it is irrelevant and no longer needs to be
	Services implementation -- it is not guaranteed that a Message will		(re-)transmitted. This is a hint to the Transport Services
	not be sent when its Lifetime has expired.		implementation -- it is not guaranteed that a Message will not be
			sent when its Lifetime has expired.
	Setting a Message's Lifetime to infinite indicates that the		Setting a Message's Lifetime to infinite indicates that the
	application does not wish to apply a time constraint on the		application does not wish to apply a time constraint on the
	transmission of the Message, but it does not express a need for		transmission of the Message, but it does not express a need for
	reliable delivery; reliability is adjustable per Message via the		reliable delivery; reliability is adjustable per Message via the
	perMsgReliability property (see Section 9.1.3.7). The type and units		perMsgReliability property (see Section 9.1.3.7). The type and units
	of Lifetime are implementation-specific.		of Lifetime are implementation-specific.
	9.1.3.2. Priority		9.1.3.2. Priority
	skipping to change at page 66, line 6 ¶		skipping to change at page 66, line 6 ¶
	9.2.1. Basic Sending		9.2.1. Basic Sending
	The most basic form of sending on a connection involves enqueuing a		The most basic form of sending on a connection involves enqueuing a
	single Data block as a complete Message with default Message		single Data block as a complete Message with default Message
	Properties.		Properties.
	messageData := "hello"		messageData := "hello"
	Connection.Send(messageData)		Connection.Send(messageData)
	The interpretation of a Message to be sent is dependent on the		The interpretation of a Message to be sent is dependent on the
	implementation, and on the constraints on the Protocol Stacks implied		implementation, and on the constraints on the Protocol Stacks implied
	by the Connection's transport properties. For example, a Message may		by the Connection’s transport properties. For example, a Message may
	be a single datagram for UDP Connections; or an HTTP Request for HTTP		be a single datagram for UDP Connections; or an HTTP Request for HTTP
	Connections.		Connections.
	Some transport protocols can deliver arbitrarily sized Messages, but		Some transport protocols can deliver arbitrarily sized Messages, but
	other protocols constrain the maximum Message size. Applications can		other protocols constrain the maximum Message size. Applications can
	query the Connection Property sendMsgMaxLen (Section 8.1.11.3) to		query the Connection Property sendMsgMaxLen (Section 8.1.11.3) to
	determine the maximum size allowed for a single Message. If a		determine the maximum size allowed for a single Message. If a
	Message is too large to fit in the Maximum Message Size for the		Message is too large to fit in the Maximum Message Size for the
	Connection, the Send will fail with a SendError event		Connection, the Send will fail with a SendError event
	(Section 9.2.2.3). For example, it is invalid to send a Message over		(Section 9.2.2.3). For example, it is invalid to send a Message over
	skipping to change at page 79, line 50 ¶		skipping to change at page 79, line 50 ¶
	good questions based on implementation experience and for		good questions based on implementation experience and for
	contributing text, e.g., on multicast.		contributing text, e.g., on multicast.
	15. References		15. References
	15.1. Normative References		15.1. Normative References
	[I-D.ietf-taps-arch]		[I-D.ietf-taps-arch]
	Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and		Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and
	C. Perkins, "An Architecture for Transport Services", Work		C. Perkins, "An Architecture for Transport Services", Work
	in Progress, Internet-Draft, draft-ietf-taps-arch-15, 20		in Progress, Internet-Draft, draft-ietf-taps-arch-16, 9
	October 2022, <https://datatracker.ietf.org/doc/html/		March 2023, <https://datatracker.ietf.org/doc/html/draft-
	draft-ietf-taps-arch-15>.		ietf-taps-arch-16>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2119>.		<https://www.rfc-editor.org/rfc/rfc2119>.
	[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,		[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
	RFC 2914, DOI 10.17487/RFC2914, September 2000,		RFC 2914, DOI 10.17487/RFC2914, September 2000,
	<https://www.rfc-editor.org/rfc/rfc2914>.		<https://www.rfc-editor.org/rfc/rfc2914>.
	skipping to change at page 80, line 41 ¶		skipping to change at page 80, line 41 ¶
	"Temporary Address Extensions for Stateless Address		"Temporary Address Extensions for Stateless Address
	Autoconfiguration in IPv6", RFC 8981,		Autoconfiguration in IPv6", RFC 8981,
	DOI 10.17487/RFC8981, February 2021,		DOI 10.17487/RFC8981, February 2021,
	<https://www.rfc-editor.org/rfc/rfc8981>.		<https://www.rfc-editor.org/rfc/rfc8981>.
	15.2. Informative References		15.2. Informative References
	[I-D.ietf-taps-impl]		[I-D.ietf-taps-impl]
	Brunstrom, A., Pauly, T., Enghardt, R., Tiesel, P. S., and		Brunstrom, A., Pauly, T., Enghardt, R., Tiesel, P. S., and
	M. Welzl, "Implementing Interfaces to Transport Services",		M. Welzl, "Implementing Interfaces to Transport Services",
	Work in Progress, Internet-Draft, draft-ietf-taps-impl-14,		Work in Progress, Internet-Draft, draft-ietf-taps-impl-15,
	20 October 2022, <https://datatracker.ietf.org/doc/html/		9 March 2023, <https://datatracker.ietf.org/doc/html/
	draft-ietf-taps-impl-14>.		draft-ietf-taps-impl-15>.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	"Definition of the Differentiated Services Field (DS		"Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		Field) in the IPv4 and IPv6 Headers", RFC 2474,
	DOI 10.17487/RFC2474, December 1998,		DOI 10.17487/RFC2474, December 1998,
	<https://www.rfc-editor.org/rfc/rfc2474>.		<https://www.rfc-editor.org/rfc/rfc2474>.
	[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,		[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
	"Assured Forwarding PHB Group", RFC 2597,		"Assured Forwarding PHB Group", RFC 2597,
	DOI 10.17487/RFC2597, June 1999,		DOI 10.17487/RFC2597, June 1999,
End of changes. 24 change blocks.
	51 lines changed or deleted		55 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/