draft-ietf-taps-interface-16.txt   draft-ietf-taps-interface-17.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: 5 March 2023 University of Oslo Expires: 31 March 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.
1 September 2022 27 September 2022
An Abstract Application Layer Interface to Transport Services An Abstract Application Layer Interface to Transport Services
draft-ietf-taps-interface-16 draft-ietf-taps-interface-17
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 5 March 2023. This Internet-Draft will expire on 31 March 2023.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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
skipping to change at page 2, line 44 skipping to change at page 2, line 44
3.1.1. Server Example . . . . . . . . . . . . . . . . . . . 9 3.1.1. Server Example . . . . . . . . . . . . . . . . . . . 9
3.1.2. Client Example . . . . . . . . . . . . . . . . . . . 10 3.1.2. Client Example . . . . . . . . . . . . . . . . . . . 10
3.1.3. Peer Example . . . . . . . . . . . . . . . . . . . . 12 3.1.3. Peer Example . . . . . . . . . . . . . . . . . . . . 12
4. Transport Properties . . . . . . . . . . . . . . . . . . . . 13 4. Transport Properties . . . . . . . . . . . . . . . . . . . . 13
4.1. Transport Property Names . . . . . . . . . . . . . . . . 14 4.1. Transport Property Names . . . . . . . . . . . . . . . . 14
4.2. Transport Property Types . . . . . . . . . . . . . . . . 15 4.2. Transport Property Types . . . . . . . . . . . . . . . . 15
5. Scope of the API Definition . . . . . . . . . . . . . . . . . 15 5. Scope of the API Definition . . . . . . . . . . . . . . . . . 15
6. Pre-Establishment Phase . . . . . . . . . . . . . . . . . . . 16 6. Pre-Establishment Phase . . . . . . . . . . . . . . . . . . . 16
6.1. Specifying Endpoints . . . . . . . . . . . . . . . . . . 17 6.1. Specifying Endpoints . . . . . . . . . . . . . . . . . . 17
6.1.1. Using Multicast Endpoints . . . . . . . . . . . . . . 19 6.1.1. Using Multicast Endpoints . . . . . . . . . . . . . . 19
6.1.2. Constraining Interfaces for Endpoints . . . . . . . . 19 6.1.2. Constraining Interfaces for Endpoints . . . . . . . . 20
6.1.3. Endpoint Aliases . . . . . . . . . . . . . . . . . . 20 6.1.3. Endpoint Aliases . . . . . . . . . . . . . . . . . . 21
6.1.4. Endpoint Examples . . . . . . . . . . . . . . . . . . 20 6.1.4. Endpoint Examples . . . . . . . . . . . . . . . . . . 21
6.1.5. Multicast Examples . . . . . . . . . . . . . . . . . 21 6.1.5. Multicast Examples . . . . . . . . . . . . . . . . . 22
6.2. Specifying Transport Properties . . . . . . . . . . . . . 23 6.2. Specifying Transport Properties . . . . . . . . . . . . . 25
6.2.1. Reliable Data Transfer (Connection) . . . . . . . . . 26 6.2.1. Reliable Data Transfer (Connection) . . . . . . . . . 28
6.2.2. Preservation of Message Boundaries . . . . . . . . . 27 6.2.2. Preservation of Message Boundaries . . . . . . . . . 28
6.2.3. Configure Per-Message Reliability . . . . . . . . . . 27 6.2.3. Configure Per-Message Reliability . . . . . . . . . . 28
6.2.4. Preservation of Data Ordering . . . . . . . . . . . . 27 6.2.4. Preservation of Data Ordering . . . . . . . . . . . . 28
6.2.5. Use 0-RTT Session Establishment with a Safely 6.2.5. Use 0-RTT Session Establishment with a Safely
Replayable Message . . . . . . . . . . . . . . . . . 27 Replayable Message . . . . . . . . . . . . . . . . . 29
6.2.6. Multistream Connections in Group . . . . . . . . . . 28 6.2.6. Multistream Connections in Group . . . . . . . . . . 29
6.2.7. Full Checksum Coverage on Sending . . . . . . . . . . 28 6.2.7. Full Checksum Coverage on Sending . . . . . . . . . . 29
6.2.8. Full Checksum Coverage on Receiving . . . . . . . . . 28 6.2.8. Full Checksum Coverage on Receiving . . . . . . . . . 29
6.2.9. Congestion control . . . . . . . . . . . . . . . . . 29 6.2.9. Congestion control . . . . . . . . . . . . . . . . . 30
6.2.10. Keep alive . . . . . . . . . . . . . . . . . . . . . 29 6.2.10. Keep alive . . . . . . . . . . . . . . . . . . . . . 30
6.2.11. Interface Instance or Type . . . . . . . . . . . . . 29 6.2.11. Interface Instance or Type . . . . . . . . . . . . . 30
6.2.12. Provisioning Domain Instance or Type . . . . . . . . 30 6.2.12. Provisioning Domain Instance or Type . . . . . . . . 31
6.2.13. Use Temporary Local Address . . . . . . . . . . . . . 31 6.2.13. Use Temporary Local Address . . . . . . . . . . . . . 32
6.2.14. Multipath Transport . . . . . . . . . . . . . . . . . 32 6.2.14. Multipath Transport . . . . . . . . . . . . . . . . . 33
6.2.15. Advertisement of Alternative Addresses . . . . . . . 33 6.2.15. Advertisement of Alternative Addresses . . . . . . . 34
6.2.16. Direction of communication . . . . . . . . . . . . . 33 6.2.16. Direction of communication . . . . . . . . . . . . . 34
6.2.17. Notification of ICMP soft error message arrival . . . 34 6.2.17. Notification of ICMP soft error message arrival . . . 35
6.2.18. Initiating side is not the first to write . . . . . . 34 6.2.18. Initiating side is not the first to write . . . . . . 35
6.3. Specifying Security Parameters and Callbacks . . . . . . 35 6.3. Specifying Security Parameters and Callbacks . . . . . . 36
6.3.1. Specifying Security Parameters on a Pre-Connection . 35 6.3.1. Specifying Security Parameters on a Pre-Connection . 36
6.3.2. Connection Establishment Callbacks . . . . . . . . . 37 6.3.2. Connection Establishment Callbacks . . . . . . . . . 38
7. Establishing Connections . . . . . . . . . . . . . . . . . . 37 7. Establishing Connections . . . . . . . . . . . . . . . . . . 38
7.1. Active Open: Initiate . . . . . . . . . . . . . . . . . . 38 7.1. Active Open: Initiate . . . . . . . . . . . . . . . . . . 39
7.2. Passive Open: Listen . . . . . . . . . . . . . . . . . . 39 7.2. Passive Open: Listen . . . . . . . . . . . . . . . . . . 40
7.3. Peer-to-Peer Establishment: Rendezvous . . . . . . . . . 40 7.3. Peer-to-Peer Establishment: Rendezvous . . . . . . . . . 41
7.4. Connection Groups . . . . . . . . . . . . . . . . . . . . 42 7.4. Connection Groups . . . . . . . . . . . . . . . . . . . . 43
7.5. Adding and Removing Endpoints on a Connection . . . . . . 44 7.5. Adding and Removing Endpoints on a Connection . . . . . . 45
8. Managing Connections . . . . . . . . . . . . . . . . . . . . 44 8. Managing Connections . . . . . . . . . . . . . . . . . . . . 45
8.1. Generic Connection Properties . . . . . . . . . . . . . . 46 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 . . . . . . . . . . . . . . . . . . . . . . 46 Receiving . . . . . . . . . . . . . . . . . . . . . . 47
8.1.2. Connection Priority . . . . . . . . . . . . . . . . . 47 8.1.2. Connection Priority . . . . . . . . . . . . . . . . . 48
8.1.3. Timeout for Aborting Connection . . . . . . . . . . . 47 8.1.3. Timeout for Aborting Connection . . . . . . . . . . . 48
8.1.4. Timeout for keep alive packets . . . . . . . . . . . 47 8.1.4. Timeout for keep alive packets . . . . . . . . . . . 48
8.1.5. Connection Group Transmission Scheduler . . . . . . . 48 8.1.5. Connection Group Transmission Scheduler . . . . . . . 49
8.1.6. Capacity Profile . . . . . . . . . . . . . . . . . . 48 8.1.6. Capacity Profile . . . . . . . . . . . . . . . . . . 49
8.1.7. Policy for using Multipath Transports . . . . . . . . 50 8.1.7. Policy for using Multipath Transports . . . . . . . . 51
8.1.8. Bounds on Send or Receive Rate . . . . . . . . . . . 50 8.1.8. Bounds on Send or Receive Rate . . . . . . . . . . . 51
8.1.9. Group Connection Limit . . . . . . . . . . . . . . . 51 8.1.9. Group Connection Limit . . . . . . . . . . . . . . . 52
8.1.10. Isolate Session . . . . . . . . . . . . . . . . . . . 51 8.1.10. Isolate Session . . . . . . . . . . . . . . . . . . . 52
8.1.11. Read-only Connection Properties . . . . . . . . . . . 52 8.1.11. Read-only Connection Properties . . . . . . . . . . . 53
8.2. TCP-specific Properties: User Timeout Option (UTO) . . . 53 8.2. TCP-specific Properties: User Timeout Option (UTO) . . . 54
8.2.1. Advertised User Timeout . . . . . . . . . . . . . . . 53 8.2.1. Advertised User Timeout . . . . . . . . . . . . . . . 54
8.2.2. User Timeout Enabled . . . . . . . . . . . . . . . . 53 8.2.2. User Timeout Enabled . . . . . . . . . . . . . . . . 54
8.2.3. Timeout Changeable . . . . . . . . . . . . . . . . . 54 8.2.3. Timeout Changeable . . . . . . . . . . . . . . . . . 55
8.3. Connection Lifecycle Events . . . . . . . . . . . . . . . 54 8.3. Connection Lifecycle Events . . . . . . . . . . . . . . . 55
8.3.1. Soft Errors . . . . . . . . . . . . . . . . . . . . . 54 8.3.1. Soft Errors . . . . . . . . . . . . . . . . . . . . . 55
8.3.2. Path change . . . . . . . . . . . . . . . . . . . . . 54 8.3.2. Path change . . . . . . . . . . . . . . . . . . . . . 55
9. Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . 54 9. Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1. Messages and Framers . . . . . . . . . . . . . . . . . . 55 9.1. Messages and Framers . . . . . . . . . . . . . . . . . . 56
9.1.1. Message Contexts . . . . . . . . . . . . . . . . . . 55 9.1.1. Message Contexts . . . . . . . . . . . . . . . . . . 56
9.1.2. Message Framers . . . . . . . . . . . . . . . . . . . 55 9.1.2. Message Framers . . . . . . . . . . . . . . . . . . . 56
9.1.3. Message Properties . . . . . . . . . . . . . . . . . 58 9.1.3. Message Properties . . . . . . . . . . . . . . . . . 59
9.2. Sending Data . . . . . . . . . . . . . . . . . . . . . . 64 9.2. Sending Data . . . . . . . . . . . . . . . . . . . . . . 65
9.2.1. Basic Sending . . . . . . . . . . . . . . . . . . . . 64 9.2.1. Basic Sending . . . . . . . . . . . . . . . . . . . . 65
9.2.2. Send Events . . . . . . . . . . . . . . . . . . . . . 65 9.2.2. Send Events . . . . . . . . . . . . . . . . . . . . . 66
9.2.3. Partial Sends . . . . . . . . . . . . . . . . . . . . 66 9.2.3. Partial Sends . . . . . . . . . . . . . . . . . . . . 67
9.2.4. Batching Sends . . . . . . . . . . . . . . . . . . . 67 9.2.4. Batching Sends . . . . . . . . . . . . . . . . . . . 68
9.2.5. Send on Active Open: InitiateWithSend . . . . . . . . 67 9.2.5. Send on Active Open: InitiateWithSend . . . . . . . . 68
9.2.6. Priority and the Transport Services API . . . . . . . 68 9.2.6. Priority and the Transport Services API . . . . . . . 69
9.3. Receiving Data . . . . . . . . . . . . . . . . . . . . . 68 9.3. Receiving Data . . . . . . . . . . . . . . . . . . . . . 69
9.3.1. Enqueuing Receives . . . . . . . . . . . . . . . . . 69 9.3.1. Enqueuing Receives . . . . . . . . . . . . . . . . . 70
9.3.2. Receive Events . . . . . . . . . . . . . . . . . . . 69 9.3.2. Receive Events . . . . . . . . . . . . . . . . . . . 70
9.3.3. Receive Message Properties . . . . . . . . . . . . . 72 9.3.3. Receive Message Properties . . . . . . . . . . . . . 73
10. Connection Termination . . . . . . . . . . . . . . . . . . . 73 10. Connection Termination . . . . . . . . . . . . . . . . . . . 74
11. Connection State and Ordering of Operations and Events . . . 75 11. Connection State and Ordering of Operations and Events . . . 76
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77
13. Privacy and Security Considerations . . . . . . . . . . . . . 76 13. Privacy and Security Considerations . . . . . . . . . . . . . 77
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 79
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 79
15.1. Normative References . . . . . . . . . . . . . . . . . . 78 15.1. Normative References . . . . . . . . . . . . . . . . . . 79
15.2. Informative References . . . . . . . . . . . . . . . . . 79 15.2. Informative References . . . . . . . . . . . . . . . . . 80
Appendix A. Implementation Mapping . . . . . . . . . . . . . . . 83 Appendix A. Implementation Mapping . . . . . . . . . . . . . . . 84
A.1. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 83 A.1. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.2. Events and Errors . . . . . . . . . . . . . . . . . . . . 84 A.2. Events and Errors . . . . . . . . . . . . . . . . . . . . 85
A.3. Time Duration . . . . . . . . . . . . . . . . . . . . . . 84 A.3. Time Duration . . . . . . . . . . . . . . . . . . . . . . 85
Appendix B. Convenience Functions . . . . . . . . . . . . . . . 84 Appendix B. Convenience Functions . . . . . . . . . . . . . . . 85
B.1. Adding Preference Properties . . . . . . . . . . . . . . 84 B.1. Adding Preference Properties . . . . . . . . . . . . . . 85
B.2. Transport Property Profiles . . . . . . . . . . . . . . . 84 B.2. Transport Property Profiles . . . . . . . . . . . . . . . 85
B.2.1. reliable-inorder-stream . . . . . . . . . . . . . . . 85 B.2.1. reliable-inorder-stream . . . . . . . . . . . . . . . 85
B.2.2. reliable-message . . . . . . . . . . . . . . . . . . 85 B.2.2. reliable-message . . . . . . . . . . . . . . . . . . 86
B.2.3. unreliable-datagram . . . . . . . . . . . . . . . . . 85 B.2.3. unreliable-datagram . . . . . . . . . . . . . . . . . 86
Appendix C. Relationship to the Minimal Set of Transport Services Appendix C. Relationship to the Minimal Set of Transport Services
for End Systems . . . . . . . . . . . . . . . . . . . . . 86 for End Systems . . . . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction 1. Introduction
This document specifies an abstract application programming interface This document specifies an abstract application programming interface
(API) that specifies the interface component of the high-level (API) that specifies the interface component of the high-level
Transport Services architecture defined in [I-D.ietf-taps-arch]. A Transport Services architecture defined in [I-D.ietf-taps-arch]. A
Transport Services system supports asynchronous, atomic transmission Transport Services system supports asynchronous, atomic transmission
of messages over transport protocols and network paths dynamically of messages over transport protocols and network paths dynamically
selected at runtime, in environments where an endpoint selects from selected at runtime, in environments where an endpoint selects from
multiple interfaces and potential transport protocols. multiple interfaces and potential transport protocols.
skipping to change at page 7, line 20 skipping to change at page 7, line 20
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Overview of the API Design 2. Overview of the API Design
The design of the API specified in this document is based on a set of The design of the API specified in this document is based on a set of
principles, themselves an elaboration on the architectural design principles, themselves an elaboration on the architectural design
principles defined in [I-D.ietf-taps-arch]. The API defined in this principles defined in [I-D.ietf-taps-arch]. The API defined in this
document provides: document provides:
* A Transport Services system can offer a variety of transport * A Transport Services system that can offer a variety of transport
protocols, independent of the Protocol Stacks that will be used at protocols, independent of the Protocol Stacks that will be used at
runtime. All common features of these protocol stacks are made runtime. To the degree possible, all common features of these
available to the application in a transport-independent way to the protocol stacks are made available to the application in a
degree possible. This enables applications written to a single transport-independent way. This enables applications written to a
API to make use of transport protocols in terms of the features single API to make use of transport protocols in terms of the
they provide. features they provide.
* A unified API to datagram and stream-oriented transports, allowing * A unified API to datagram and stream-oriented transports, allowing
use of a common API for connection establishment and closing. use of a common API for connection establishment and closing.
* Message-orientation, as opposed to stream-orientation, using * Message-orientation, as opposed to stream-orientation, using
application-assisted framing and deframing where the underlying application-assisted framing and deframing where the underlying
transport does not provide these. transport does not provide these.
* Asynchronous Connection establishment, transmission, and * Asynchronous Connection establishment, transmission, and
reception. This allows concurrent operations during establishment reception. This allows concurrent operations during establishment
and event-driven application interactions with the transport and event-driven application interactions with the transport
layer; layer.
* Selection between alternate network paths, using additional * Selection between alternate network paths, using additional
information about the networks over which a connection can operate information about the networks over which a connection can operate
(e.g. Provisioning Domain (PvD) information [RFC7556]) where (e.g. Provisioning Domain (PvD) information [RFC7556]) where
available. available.
* Explicit support for transport-specific features to be applied, * Explicit support for transport-specific features to be applied,
should that particular transport be part of a chosen Protocol should that particular transport be part of a chosen Protocol
Stack. Stack.
skipping to change at page 9, line 10 skipping to change at page 9, line 10
notifications also happen asynchronously on the Connection. It is notifications also happen asynchronously on the Connection. It is
not necessary for an application to handle all Events; some Events not necessary for an application to handle all Events; some Events
may have implementation-specific default handlers. The application may have implementation-specific default handlers. The application
should not assume that ignoring Events (e.g., Errors) is always safe. should not assume that ignoring Events (e.g., Errors) is always safe.
3.1. Usage Examples 3.1. Usage Examples
The following usage examples illustrate how an application might use The following usage examples illustrate how an application might use
the Transport Services API to: the Transport Services API to:
* Act as a server, by listening for incoming connections, receiving * Act as a server, by listening for incoming Connections, receiving
requests, and sending responses, see Section 3.1.1. requests, and sending responses, see Section 3.1.1.
* Act as a client, by connecting to a Remote Endpoint using * Act as a client, by connecting to a Remote Endpoint using
Initiate, sending requests, and receiving responses, see Initiate, sending requests, and receiving responses, see
Section 3.1.2. Section 3.1.2.
* Act as a peer, by connecting to a Remote Endpoint using Rendezvous * Act as a peer, by connecting to a Remote Endpoint using Rendezvous
while simultaneously waiting for incoming Connections, sending while simultaneously waiting for incoming Connections, sending
Messages, and receiving Messages, see Section 3.1.3. Messages, and receiving Messages, see Section 3.1.3.
The examples in this section presume that a transport protocol is The examples in this section presume that a transport protocol is
available between the Local and Remote Endpoints that provides available between the Local and Remote Endpoints that provides
Reliable Data Transfer, Preservation of Data Ordering, and Reliable Data Transfer, Preservation of Data Ordering, and
Preservation of Message Boundaries. In this case, the application Preservation of Message Boundaries. In this case, the application
can choose to receive only complete messages. can choose to receive only complete Messages.
If none of the available transport protocols provides Preservation of If none of the available transport protocols provides Preservation of
Message Boundaries, but there is a transport protocol that provides a Message Boundaries, but there is a transport protocol that provides a
reliable ordered byte stream, an application could receive this byte reliable ordered byte stream, an application could receive this byte
stream as partial Messages and transform it into application-layer stream as partial Messages and transform it into application-layer
Messages. Alternatively, an application might provide a Message Messages. Alternatively, an application might provide a Message
Framer, which can transform a sequence of Messages into a byte stream Framer, which can transform a sequence of Messages into a byte stream
and vice versa (Section 9.1.2). and vice versa (Section 9.1.2).
3.1.1. Server Example 3.1.1. Server Example
skipping to change at page 15, line 23 skipping to change at page 15, line 23
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 a one of the basic types described in Each Transport Property has one of the basic types described in
Section 1.1. Section 1.1.
Most Selection Properties (see Section 6.2) are of the Enumeration Most Selection Properties (see Section 6.2) are of the Enumeration
type, and use the Preference Enumeration, which takes one of five type, and use the Preference Enumeration, which takes one of five
possible values (Prohibit, Avoid, Ignore, Prefer, or Require) possible values (Prohibit, Avoid, Ignore, Prefer, or Require)
denoting the level of preference for a given property during protocol denoting the level of preference for a given property during protocol
selection. selection.
5. Scope of the API Definition 5. Scope of the API Definition
skipping to change at page 17, line 45 skipping to change at page 17, line 45
on a Preconnection allows applications to override this for more on a Preconnection allows applications to override this for more
detailed control. detailed control.
If Message Framers are used (see Section 9.1.2), they MUST be added If Message Framers are used (see Section 9.1.2), they MUST be added
to the Preconnection during pre-establishment. to the Preconnection during pre-establishment.
6.1. Specifying Endpoints 6.1. Specifying Endpoints
The transport services API uses the Local Endpoint and Remote The transport services API uses the Local Endpoint and Remote
Endpoint Objects to refer to the endpoints of a transport connection. Endpoint Objects to refer to the endpoints of a transport connection.
Endpoints can be created as either Remote or Local: Endpoints can be created as either remote or local:
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
LocalSpecifier := NewLocalEndpoint() LocalSpecifier := NewLocalEndpoint()
A single Endpoint Object represents the identity of a network host. A single Endpoint Object represents the identity of a network host.
That endpoint can be more or less specific depending on which That endpoint can be more or less specific depending on which
identifiers are set. For example, an Endpoint that only specifies a identifiers are set. For example, an Endpoint that only specifies a
hostname may in fact end up corresponding to several different IP hostname may in fact end up corresponding to several different IP
addresses on different hosts. addresses on different hosts.
An Endpoint Object can be configured with the following identifiers: An Endpoint Object can be configured with the following identifiers:
skipping to change at page 19, line 17 skipping to change at page 19, line 17
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).
6.1.1. Using Multicast Endpoints 6.1.1. Using Multicast Endpoints
Specifying a multicast group address on a Local Endpoint will To use multicast, a Preconnection is first created with the Local/
indicate to the Transport Services system that the resulting Remote Endpoint specifying the any-source multicast (ASM) or source-
connection will be used to receive multicast messages. The Remote specific multicast (SSM) multicast group and destination port number.
Endpoint can be used to filter incoming multicast from specific
senders. Such a Preconnection will only support calling Listen(),
not Initiate(). Calling Listen() will cause the Transport Services
system to register for receiving multicast, such as issuing an IGMP
join [RFC3376] or using MLD for IPV6 [RFC4604]. Any Connections that
are accepted from this Listener are receive-only.
Similarly, specifying a multicast group address on the Remote Calling Initiate() on that Preconnection creates a Connection that
Endpoint will indicate that the resulting connection will be used to can be used to send messages to the multicast group. The Connection
send multicast messages, and that the Preconnection will support object that is created will support Send() but not Receive(). Any
Initiate() but not Listen(). Any Connections created this way are Connections created this way are send-only, and do not join the
send-only. multicast group. The resulting Connection will have a Local Endpoint
indicating the local interface to which the connection is bound and a
Remote Endpoint indicating the multicast group.
A Rendezvous() call on Preconnections containing group addresses The following API calls can be used to configure a Preconnection
results in an EstablishmentError as described in Section 7.3. before calling Initiate():
RemoteSpecifier.WithMulticastGroupIPv4(GroupAddress)
RemoteSpecifier.WithMulticastGroupIPv6(GroupAddress)
RemoteSpecifier.WithPort(PortNumber)
RemoteSpecifier.WithTTL(TTL)
Calling Listen() on a Preconnection with a multicast group specified
on the Remote Endpoint will join the multicast group to receive
messages. This Listener will create one Connection for each Remote
Endpoint sending to the group, with the Local Endpoint set to the
group address. The set of Connection objects created forms a
Connection Group. The receiving interface can be restricted by
passing it as part of the LocalSpecifier or queried through the
MessagContext on the messages received (see Section 9.1.1 for further
details).
The following API calls can be used to configure a Preconnection
before calling Listen():
LocalSpecifier.WithSingleSourceMulticastGroupIPv4(GroupAddress, SourceAddress)
LocalSpecifier.WithSingleSourceMulticastGroupIPv6(GroupAddress, SourceAddress)
LocalSpecifier.WithAnySourceMulticastGroupIPv4(GroupAddress)
LocalSpecifier.WithAnySourceMulticastGroupIPv6(GroupAddress)
LocalSpecifier.WithPort(PortNumber)
Calling Rendezvous() on a Preconnection with an any-source multicast
group address as the Remote Endpoint will join the multicast group,
and also indicates that the resulting connection can be used to send
messages to the multicast group. The Rendezvous() call will return
both a Connection that can be used to send to the group, that acts
the same as a connection returned by calling Initiate() with a
multicast Remote Endpoint, and a Listener that acts as if Listen()
had been called with a multicast Remote Endpoint. Calling
Rendezvous() on a Preconnection with a source-specific multicast
group address as the Local Endpoint results in an EstablishmentError.
The following API calls can be used to configure a Preconnection
before calling Rendezvous():
RemoteSpecifier.WithMulticastGroupIPv4(GroupAddress)
RemoteSpecifier.WithMulticastGroupIPv6(GroupAddress)
RemoteSpecifier.WithPort(PortNumber)
RemoteSpecifier.WithTTL(TTL)
LocalSpecifier.WithAnySourceMulticastGroupIPv4(GroupAddress)
LocalSpecifier.WithAnySourceMulticastGroupIPv6(GroupAddress)
LocalSpecifier.WithPort(PortNumber)
LocalSpecifier.WithTTL(TTL)
See Section 6.1.5 for more examples. See Section 6.1.5 for more examples.
6.1.2. Constraining Interfaces for Endpoints 6.1.2. Constraining Interfaces for Endpoints
Note that this API has multiple ways to constrain and prioritize Note that this API has multiple ways to constrain and prioritize
endpoint candidates based on the network interface: endpoint candidates based on the network interface:
* Specifying an interface on a RemoteEndpoint qualifies the scope of * Specifying an interface on a RemoteEndpoint qualifies the scope of
the remote endpoint, e.g., for link-local addresses. the remote endpoint, e.g., for link-local addresses.
* Specifying an interface on a LocalEndpoint explicitly binds all * Specifying an interface on a LocalEndpoint explicitly binds all
candidates derived from this endpoint to use the specified candidates derived from this endpoint to use the specified
interface. interface.
* Specifying an interface using the interface Selection Property * Specifying an interface using the interface Selection Property
(Section 6.2.11) or indirectly via the pvd Selection Property (Section 6.2.11) or indirectly via the pvd Selection Property
(Section 6.2.12) influences the selection among the available (Section 6.2.12) influences the selection among the available
candidates. candidates.
While specifying an interface on an endpoint restricts the candidates While specifying an Interface on an Endpoint restricts the candidates
available for connection establishment in the Pre-Establishment available for connection establishment in the Pre-Establishment
Phase, the Selection Properties prioritize and constrain the Phase, the Selection Properties prioritize and constrain the
connection establishment. connection establishment.
6.1.3. Endpoint Aliases 6.1.3. Endpoint Aliases
An Endpoint can have an alternative definition when using different An Endpoint can have an alternative definition when using different
protocols. For example, a server that supports both TLS/TCP and QUIC protocols. For example, a server that supports both TLS/TCP and QUIC
may be accessible on two different port numbers depending on which may be accessible on two different port numbers depending on which
protocol is used. protocol is used.
skipping to change at page 20, line 32 skipping to change at page 21, line 27
To support this, Endpoint Objects can specify "aliases". An Endpoint To support this, Endpoint Objects can specify "aliases". An Endpoint
can have multiple aliases set. can have multiple aliases set.
RemoteSpecifier.AddAlias(AlternateRemoteSpecifier) RemoteSpecifier.AddAlias(AlternateRemoteSpecifier)
In order to scope an alias to a specific transport protocol, an In order to scope an alias to a specific transport protocol, an
Endpoint can specify a protocol identifier. Endpoint can specify a protocol identifier.
RemoteSpecifier.WithProtocol(QUIC) RemoteSpecifier.WithProtocol(QUIC)
The following example shows a case where "example.com" has a server The following example shows a case where example.com has a server
running on port 443, with an alternate port of 8443 for QUIC. running on port 443, with an alternate port of 8443 for QUIC.
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithHostname("example.com") RemoteSpecifier.WithHostname("example.com")
RemoteSpecifier.WithPort(443) RemoteSpecifier.WithPort(443)
QUICRemoteSpecifier := NewRemoteEndpoint() QUICRemoteSpecifier := NewRemoteEndpoint()
QUICRemoteSpecifier.WithHostname("example.com") QUICRemoteSpecifier.WithHostname("example.com")
QUICRemoteSpecifier.WithPort(8443) QUICRemoteSpecifier.WithPort(8443)
QUICRemoteSpecifier.WithProtocol(QUIC) QUICRemoteSpecifier.WithProtocol(QUIC)
skipping to change at page 21, line 42 skipping to change at page 22, line 36
result in an Error once the application attempts to open a result in an Error once the application attempts to open a
Connection. Connection.
Specify a Local Endpoint using a STUN server: Specify a Local Endpoint using a STUN server:
LocalSpecifier := NewLocalEndpoint() LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithStunServer(address, port, credentials) LocalSpecifier.WithStunServer(address, port, credentials)
6.1.5. Multicast Examples 6.1.5. Multicast Examples
Specify a Local Endpoint using an Any-Source Multicast group to join The following examples show how multicast groups can be used.
on a named local interface:
LocalSpecifier := NewLocalEndpoint() Join an Any-Source Multicast group in receive-only mode, bound to a
LocalSpecifier.WithIPv4Address(233.252.0.0) known port on a named local interface:
LocalSpecifier.WithInterface("en0")
Source-Specific Multicast requires setting both a Local and Remote RemoteSpecifier := NewRemoteEndpoint()
Endpoint:
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithAnySourceMulticastGroupIPv4(233.252.0.0)
LocalSpecifier.WithPort(5353)
LocalSpecifier.WithInterface("en0")
TransportProperties := ...
SecurityParameters := ...
Preconnection := newPreconnection(LocalSpecifier,
RemoteSpecifier,
TransportProperties,
SecurityProperties)
Listener := Preconnection.Listen()
Join an Source-Specific Multicast group in receive-only mode, bound
to a known port on a named local interface:
RemoteSpecifier := NewRemoteEndpoint()
LocalSpecifier := NewLocalEndpoint() LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithIPv4Address(232.1.1.1) LocalSpecifier.WithSingleSourceMulticastGroupIPv4(233.252.0.0, 198.51.100.10)
LocalSpecifier.WithPort(5353)
LocalSpecifier.WithInterface("en0") LocalSpecifier.WithInterface("en0")
RemoteSpecifier := NewRemoteEndpoint() TransportProperties := ...
RemoteSpecifier.WithIPv4Address(192.0.2.22) SecurityParameters := ...
One common pattern for multicast is to both send and receive Preconnection := newPreconnection(LocalSpecifier,
multicast. For such cases, an application can set up both a Listener RemoteSpecifier,
and a Connection. The Listener is only used to accept Connections TransportProperties,
that receive inbound multicast. The initiated Connection is only SecurityProperties)
used to send multicast. Listener := Preconnection.Listen()
// Prepare multicast Listener Create a Source-Specific Multicast group as a sender:
LocalMulticastSpecifier := NewLocalEndpoint()
LocalMulticastSpecifier.WithIPv4Address(233.252.0.0)
LocalMulticastSpecifier.WithPort(5353)
LocalMulticastSpecifier.WithInterface("en0")
TransportProperties := NewTransportProperties() RemoteSpecifier := NewRemoteEndpoint()
TransportProperties.Require(preserve-msg-boundaries) RemoteSpecifier.WithMulticastGroupIPv4(232.1.1.1)
// Reliable Data Transfer and Preserve Order are Required by default RemoteSpecifier.WithPort(5353)
RemoteSpecifier.WithTTL(8)
// Specifying a Remote Endpoint is optional when using Listen() LocalSpecifier := NewLocalEndpoint()
Preconnection := NewPreconnection(LocalMulticastSpecifier, LocalSpecifier.WithIPv4Address(192.0.2.22)
TransportProperties, LocalSpecifier.WithInterface("en0")
SecurityParameters)
MulticastListener := Preconnection.Listen() TransportProperties := ...
SecurityParameters := ...
// Handle inbound messages sent to the multicast group Preconnection := newPreconnection(LocalSpecifier,
MulticastListener -> ConnectionReceived<MulticastReceiverConnection> RemoteSpecifier,
MulticastReceiverConnection.Receive() TransportProperties,
MulticastReceiverConnection -> Received<messageDataRequest, messageContext> SecurityProperties)
Connection := Preconnection.Initiate()
// Prepare Connection to send multicast Join an any-source multicast group as both a sender and a receiver:
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithPort(5353)
LocalSpecifier.WithInterface("en0")
RemoteMulticastSpecifier := NewRemoteEndpoint()
RemoteMulticastSpecifier.WithIPv4Address(233.252.0.0)
RemoteMulticastSpecifier.WithPort(5353)
RemoteMulticastSpecifier.WithInterface("en0")
Preconnection2 := NewPreconnection(LocalSpecifier, RemoteSpecifier := NewRemoteEndpoint()
RemoteMulticastSpecifier, RemoteSpecifier.WithMulticastGroupIPv4(233.252.0.0)
TransportProperties, RemoteSpecifier.WithPort(5353)
SecurityParameters) RemoteSpecifier.WithTTL(8)
// Send outbound messages to the multicast group LocalSpecifier := NewLocalEndpoint()
MulticastSenderConnection := Preconnection.Initiate() LocalSpecifier.WithAnySourceMulticastGroupIPv4(233.252.0.0)
MulticastSenderConnection.Send(messageData) LocalSpecifier.WithIPv4Address(192.0.2.22)
LocalSpecifier.WithPort(5353)
LocalSpecifier.WithInterface("en0")
TransportProperties := ...
SecurityParameters := ...
Preconnection := newPreconnection(LocalSpecifier,
RemoteSpecifier,
TransportProperties,
SecurityProperties)
Connection, Listener := Preconnection.Rendezvous()
6.2. Specifying Transport Properties 6.2. Specifying Transport Properties
A Preconnection Object holds properties reflecting the application's A Preconnection Object holds properties reflecting the application's
requirements and preferences for the transport. These include requirements and preferences for the transport. These include
Selection Properties for selecting protocol stacks and paths, as well Selection Properties for selecting protocol stacks and paths, as well
as Connection Properties and Message Properties for configuration of as Connection Properties and Message Properties for configuration of
the detailed operation of the selected Protocol Stacks on a per- the detailed operation of the selected Protocol Stacks on a per-
Connection and Message level. Connection and Message level.
skipping to change at page 24, line 17 skipping to change at page 25, line 26
Since there could be paths over which some transport protocols are Since there could be paths over which some transport protocols are
unable to operate, or remote endpoints that support only specific unable to operate, or remote endpoints that support only specific
network addresses or transports, transport protocol selection is network addresses or transports, transport protocol selection is
necessarily tied to path selection. This may involve choosing necessarily tied to path selection. This may involve choosing
between multiple local interfaces that are connected to different between multiple local interfaces that are connected to different
access networks. access networks.
When additional information (such as Provisioning Domain (PvD) When additional information (such as Provisioning Domain (PvD)
information [RFC7556]) is available about the networks over which an information [RFC7556]) is available about the networks over which an
endpoint can operate, this can inform the selection between alternate endpoint can operate, this can inform the selection between alternate
network paths. Path information can include network segment PMTU, network paths. Path information can include PMTU, set of supported
set of supported DSCPs, expected usage, cost, etc. The usage of this DSCPs, expected usage, cost, etc. The usage of this information by
information by the Transport Services System is generally independent the Transport Services System is generally independent of the
of the specific mechanism/protocol used to receive the information specific mechanism/protocol used to receive the information (e.g.
(e.g. zero-conf, DHCP, or IPv6 RA). zero-conf, DHCP, or IPv6 RA).
Most Selection Properties are represented as Preferences, which can Most Selection Properties are represented as Preferences, which can
take one of five values: take one of five values:
+============+========================================+ +============+========================================+
| Preference | Effect | | Preference | Effect |
+============+========================================+ +============+========================================+
| Require | Select only protocols/paths providing | | Require | Select only protocols/paths providing |
| | the property, fail otherwise | | | the property, fail otherwise |
+------------+----------------------------------------+ +------------+----------------------------------------+
skipping to change at page 25, line 12 skipping to change at page 26, line 32
Table 1: Selection Property Preference Levels Table 1: Selection Property Preference Levels
The implementation MUST ensure an outcome that is consistent with all The implementation MUST ensure an outcome that is consistent with all
application requirements expressed using Require and Prohibit. While application requirements expressed using Require and Prohibit. While
preferences expressed using Prefer and Avoid influence protocol and preferences expressed using Prefer and Avoid influence protocol and
path selection as well, outcomes can vary given the same Selection path selection as well, outcomes can vary given the same Selection
Properties, because the available protocols and paths can differ Properties, because the available protocols and paths can differ
across systems and contexts. However, implementations are across systems and contexts. However, implementations are
RECOMMENDED to seek to provide a consistent outcome to an RECOMMENDED to seek to provide a consistent outcome to an
application, given the same set of Selection Properties. application, when provided with the same set of Selection Properties.
Note that application preferences can conflict with each other. For Note that application preferences can conflict with each other. For
example, if an application indicates a preference for a specific path example, if an application indicates a preference for a specific path
by specifying an interface, but also a preference for a protocol, a by specifying an interface, but also a preference for a protocol, a
situation might occur in which the preferred protocol is not situation might occur in which the preferred protocol is not
available on the preferred path. In such cases, applications can available on the preferred path. In such cases, applications can
expect properties that determine path selection to be prioritized expect properties that determine path selection to be prioritized
over properties that determine protocol selection. The transport over properties that determine protocol selection. The transport
system SHOULD determine the preferred path first, regardless of system SHOULD determine the preferred path first, regardless of
protocol preferences. This ordering is chosen to provide consistency protocol preferences. This ordering is chosen to provide consistency
skipping to change at page 26, line 24 skipping to change at page 27, line 41
established, Selection Properties can only be read to check the established, Selection Properties can only be read to check the
properties used by the Connection. Upon reading, the Preference type properties used by the Connection. Upon reading, the Preference type
of a Selection Property changes into Boolean, where true means that of a Selection Property changes into Boolean, where true means that
the selected Protocol Stack supports the feature or uses the path the selected Protocol Stack supports the feature or uses the path
associated with the Selection Property, and false means that the associated with the Selection Property, and false means that the
Protocol Stack does not support the feature or use the path. Protocol Stack does not support the feature or use the path.
Implementations of Transport Services systems may alternatively use Implementations of Transport Services systems may alternatively use
the two Preference values Require and Prohibit to represent true and the two Preference values Require and Prohibit to represent true and
false, respectively. false, respectively.
An implementation of the Transport Services API must provide sensible An implementation of the Transport Services API needs to provide
defaults for Selection Properties. The default values for each sensible defaults for Selection Properties. The default values for
property below represent a configuration that can be implemented over each property below represent a configuration that can be implemented
TCP. If these default values are used and TCP is not supported by a over TCP. If these default values are used and TCP is not supported
Transport Services system, then an application using the default set by a Transport Services system, then an application using the default
of Properties might not succeed in establishing a connection. Using set of Properties might not succeed in establishing a connection.
the same default values for independent Transport Services Using the same default values for independent Transport Services
implementations can be beneficial when applications are ported implementations can be beneficial when applications are ported
between different implementations/platforms, even if this default between different implementations/platforms, even if this default
could lead to a connection failure when TCP is not available. If could lead to a connection failure when TCP is not available. If
default values other than those suggested below are used, it is default values other than those suggested below are used, it is
RECOMMENDED to clearly document any differences. RECOMMENDED to clearly document any differences.
6.2.1. Reliable Data Transfer (Connection) 6.2.1. Reliable Data Transfer (Connection)
Name: reliability Name: reliability
skipping to change at page 27, line 38 skipping to change at page 28, line 52
6.2.4. Preservation of Data Ordering 6.2.4. Preservation of Data Ordering
Name: preserveOrder Name: preserveOrder
Type: Preference Type: Preference
Default: Require Default: Require
This property specifies whether the application wishes to use a This property specifies whether the application wishes to use a
transport protocol that can ensure that data is received by the transport protocol that can ensure that data is received by the
application on the other end in the same order as it was sent. application at the Remote Endpoint in the same order as it was sent.
6.2.5. Use 0-RTT Session Establishment with a Safely Replayable Message 6.2.5. Use 0-RTT Session Establishment with a Safely Replayable Message
Name: zeroRttMsg Name: zeroRttMsg
Type: Preference Type: Preference
Default: Ignore Default: Ignore
This property specifies whether an application would like to supply a This property specifies whether an application would like to supply a
Message to the transport protocol before Connection establishment Message to the transport protocol before Connection establishment
that will then be reliably transferred to the other side before or that will then be reliably transferred to the other side before or
during Connection establishment. This Message can potentially be during Connection establishment. This Message can potentially be
received multiple times (i.e., multiple copies of the message data received multiple times (i.e., multiple copies of the message data
may be passed to the Remote Endpoint). See also Section 9.1.3.4. may be passed to the Remote Endpoint). See also Section 9.1.3.4.
6.2.6. Multistream Connections in Group 6.2.6. Multistream Connections in Group
Name: multistreaming Name: multistreaming
skipping to change at page 30, line 23 skipping to change at page 31, line 23
available for each interface and interface type available on the available for each interface and interface type available on the
system. system.
The set of valid interface types is implementation- and system- The set of valid interface types is implementation- and system-
specific. For example, on a mobile device, there may be Wi-Fi and specific. For example, on a mobile device, there may be Wi-Fi and
Cellular interface types available; whereas on a desktop computer, Cellular interface types available; whereas on a desktop computer,
Wi-Fi and Wired Ethernet interface types might be available. An Wi-Fi and Wired Ethernet interface types might be available. An
implementation should provide all types that are supported on the implementation should provide all types that are supported on the
local system, to allow applications to be written generically. For local system, to allow applications to be written generically. For
example, if a single implementation is used on both mobile devices example, if a single implementation is used on both mobile devices
and desktop devices, it should define the Cellular interface type for and desktop devices, it ought to define the Cellular interface type
both systems, since an application might wish to always prohibit for both systems, since an application might wish to always prohibit
cellular. cellular.
The set of interface types is expected to change over time as new The set of interface types is expected to change over time as new
access technologies become available. The taxonomy of interface access technologies become available. The taxonomy of interface
types on a given Transport Services system is implementation- types on a given Transport Services system is implementation-
specific. specific.
Interface types should not be treated as a proxy for properties of Interface types should not be treated as a proxy for properties of
interfaces such as metered or unmetered network access. If an interfaces such as metered or unmetered network access. If an
application needs to prohibit metered interfaces, this should be application needs to prohibit metered interfaces, this should be
skipping to change at page 32, line 14 skipping to change at page 33, line 14
This property allows the application to express a preference for the This property allows the application to express a preference for the
use of temporary local addresses, sometimes called "privacy" use of temporary local addresses, sometimes called "privacy"
addresses [RFC8981]. Temporary addresses are generally used to addresses [RFC8981]. Temporary addresses are generally used to
prevent linking connections over time when a stable address, prevent linking connections over time when a stable address,
sometimes called "permanent" address, is not needed. There are some sometimes called "permanent" address, is not needed. There are some
caveats to note when specifying this property. First, if an caveats to note when specifying this property. First, if an
application Requires the use of temporary addresses, the resulting application Requires the use of temporary addresses, the resulting
Connection cannot use IPv4, because temporary addresses do not exist Connection cannot use IPv4, because temporary addresses do not exist
in IPv4. Second, temporary local addresses might involve trading off in IPv4. Second, temporary local addresses might involve trading off
privacy for performance. For instance, temporary addresses can privacy for performance. For instance, temporary addresses (e.g.,
interfere with resumption mechanisms that some protocols rely on to [RFC8981]) can interfere with resumption mechanisms that some
reduce initial latency. protocols rely on to reduce initial latency.
6.2.14. Multipath Transport 6.2.14. Multipath Transport
Name: multipath Name: multipath
Type: Enumeration Type: Enumeration
Default: Disabled for connections created through initiate and Default: Disabled for connections created through initiate and
rendezvous, Passive for listeners rendezvous, Passive for listeners
skipping to change at page 33, line 5 skipping to change at page 34, line 5
Passive: The connection will support the use of multiple paths if Passive: The connection will support the use of multiple paths if
the Remote Endpoint requests it. the Remote Endpoint requests it.
The policy for using multiple paths is specified using the separate The policy for using multiple paths is specified using the separate
multipathPolicy property, see Section 8.1.7 below. To enable the multipathPolicy property, see Section 8.1.7 below. To enable the
peer endpoint to initiate additional paths towards a local address peer endpoint to initiate additional paths towards a local address
other than the one initially used, it is necessary to set the other than the one initially used, it is necessary to set the
advertisesAltaddr property (see Section 6.2.15 below). advertisesAltaddr property (see Section 6.2.15 below).
Setting this property to "Active", can have privacy implications: It Setting this property to Active can have privacy implications: It
enables the transport to establish connectivity using alternate paths enables the transport to establish connectivity using alternate paths
that might result in users being linkable across the multiple paths, that might result in users being linkable across the multiple paths,
even if the advertisesAltaddr property (see Section 6.2.15 below) is even if the advertisesAltaddr property (see Section 6.2.15 below) is
set to false. set to false.
Note that Multipath Transport has no corresponding Selection Property Note that Multipath Transport has no corresponding Selection Property
of type Preference. Enumeration values other than "Disabled" are of type Preference. Enumeration values other than Disabled are
interpreted as a preference for choosing protocols that can make use interpreted as a preference for choosing protocols that can make use
of multiple paths. The "Disabled" value implies a requirement not to of multiple paths. The Disabled value implies a requirement not to
use multiple paths in parallel but does not prevent choosing a use multiple paths in parallel but does not prevent choosing a
protocol that is capable of using multiple paths, e.g., it does not protocol that is capable of using multiple paths, e.g., it does not
prevent choosing TCP, but prevents sending the MP_CAPABLE option in prevent choosing TCP, but prevents sending the MP_CAPABLE option in
the TCP handshake. the TCP handshake.
6.2.15. Advertisement of Alternative Addresses 6.2.15. Advertisement of Alternative Addresses
Name: advertisesAltaddr Name: advertisesAltaddr
Type: Boolean Type: Boolean
skipping to change at page 33, line 50 skipping to change at page 34, line 50
6.2.16. Direction of communication 6.2.16. Direction of communication
Name: direction Name: direction
Type: Enumeration Type: Enumeration
Default: Bidirectional Default: Bidirectional
This property specifies whether an application wants to use the This property specifies whether an application wants to use the
connection for sending and/or receiving data. Possible values are: Connection for sending and/or receiving data. Possible values are:
Bidirectional: The connection must support sending and receiving Bidirectional: The connection must support sending and receiving
data data
Unidirectional send: The connection must support sending data, and Unidirectional send: The connection must support sending data, and
the application cannot use the connection to receive any data the application cannot use the connection to receive any data
Unidirectional receive: The connection must support receiving data, Unidirectional receive: The connection must support receiving data,
and the application cannot use the connection to send any data and the application cannot use the connection to send any data
skipping to change at page 35, line 5 skipping to change at page 36, line 5
receiving them [RFC8085]. receiving them [RFC8085].
6.2.18. Initiating side is not the first to write 6.2.18. Initiating side is not the first to write
Name: activeReadBeforeSend Name: activeReadBeforeSend
Type: Preference Type: Preference
Default: Ignore Default: Ignore
The most common client-server communication pattern involves the The most common client-server communication pattern involves the
client actively opening a connection, then sending data to the client actively opening a Connection, then sending data to the
server. The server listens (passive open), reads, and then answers. server. The server listens (passive open), reads, and then answers.
This property specifies whether an application wants to diverge from This property specifies whether an application wants to diverge from
this pattern -- either by actively opening with Initiate(), this pattern -- either by actively opening with Initiate(),
immediately followed by reading, or passively opening with Listen(), immediately followed by reading, or passively opening with Listen(),
immediately followed by writing. This property is ignored when immediately followed by writing. This property is ignored when
establishing connections using Rendezvous(). Requiring this property establishing connections using Rendezvous(). Requiring this property
limits the choice of mappings to underlying protocols, which can limits the choice of mappings to underlying protocols, which can
reduce efficiency. For example, it prevents the Transport Services reduce efficiency. For example, it prevents the Transport Services
system from mapping Connections to SCTP streams, where the first system from mapping Connections to SCTP streams, where the first
transmitted data takes the role of an active open signal transmitted data takes the role of an active open signal
skipping to change at page 39, line 41 skipping to change at page 40, line 41
reused, e.g., to create another Listener. reused, e.g., to create another Listener.
Listener.Stop() Listener.Stop()
Listening continues until the global context shuts down, or until the Listening continues until the global context shuts down, or until the
Stop action is performed on the Listener object. Stop action is performed on the Listener object.
Listener -> ConnectionReceived<Connection> Listener -> ConnectionReceived<Connection>
The ConnectionReceived Event occurs when a Remote Endpoint has The ConnectionReceived Event occurs when a Remote Endpoint has
established a transport-layer connection to this Listener (for established or cloned (e.g., by creating a new stream in a multi-
Connection-oriented transport protocols), or when the first Message stream transport; see Section 7.4) a transport-layer connection to
has been received from the Remote Endpoint (for Connectionless this Listener (for Connection-oriented transport protocols), or when
protocols), causing a new Connection to be created. The resulting the first Message has been received from the Remote Endpoint (for
Connection is contained within the ConnectionReceived Event, and is Connectionless protocols or streams of a multi-streaming transport),
ready to use as soon as it is passed to the application via the causing a new Connection to be created. The resulting Connection is
event. contained within the ConnectionReceived Event, and is ready to use as
soon as it is passed to the application via the event.
Listener.SetNewConnectionLimit(value) Listener.SetNewConnectionLimit(value)
If the caller wants to rate-limit the number of inbound Connections If the caller wants to rate-limit the number of inbound Connections
that will be delivered, it can set a cap using that will be delivered, it can set a cap using
SetNewConnectionLimit(). This mechanism allows a server to protect SetNewConnectionLimit(). This mechanism allows a server to protect
itself from being drained of resources. Each time a new Connection itself from being drained of resources. Each time a new Connection
is delivered by the ConnectionReceived Event, the value is is delivered by the ConnectionReceived Event, the value is
automatically decremented. Once the value reaches zero, no further automatically decremented. Once the value reaches zero, no further
Connections will be delivered until the caller sets the limit to a Connections will be delivered until the caller sets the limit to a
higher value. By default, this value is Infinite. The caller is higher value. By default, this value is Infinite. The caller is
skipping to change at page 41, line 21 skipping to change at page 42, line 21
action on the Preconnection can be used to discover these bindings: action on the Preconnection can be used to discover these bindings:
[]LocalEndpoint, []RemoteEndpoint := Preconnection.Resolve() []LocalEndpoint, []RemoteEndpoint := Preconnection.Resolve()
The Resolve() call returns lists of Local Endpoints and Remote The Resolve() call returns lists of Local Endpoints and Remote
Endpoints, that represent the concrete addresses, local and server Endpoints, that represent the concrete addresses, local and server
reflexive, on which a Rendezvous() for the Preconnection will listen reflexive, on which a Rendezvous() for the Preconnection will listen
for incoming Connections, and to which it will attempt to establish for incoming Connections, and to which it will attempt to establish
connections. connections.
Note that the set of LocalEndpoints returned by Resolve() might or Note that the set of Local Endpoints returned by Resolve() might or
might not contain information about all possible local interfaces; it might not contain information about all possible local interfaces; it
is valid only for a Rendezvous happening at the same time as the is valid only for a Rendezvous happening at the same time as the
resolution. Care should be taken in using these values in any other resolution. Care should be taken in using these values in any other
context. context.
An application that uses Rendezvous() to establish a peer-to-peer An application that uses Rendezvous() to establish a peer-to-peer
connection in the presence of NATs will configure the Preconnection connection in the presence of NATs will configure the Preconnection
object with at least one a Local Endpoint that supports NAT binding object with at least one a Local Endpoint that supports NAT binding
discovery. It will then Resolve() the Preconnection, and pass the discovery. It will then Resolve() the Preconnection, and pass the
resulting list of Local Endpoint candidates to the peer via a resulting list of Local Endpoint candidates to the peer via a
skipping to change at page 42, line 28 skipping to change at page 43, line 28
7.4. Connection Groups 7.4. Connection Groups
Connection Groups can be created using the Clone Action: Connection Groups can be created using the Clone Action:
Connection := Connection.Clone(framer?, connectionProperties?) Connection := Connection.Clone(framer?, connectionProperties?)
Calling Clone on a Connection yields a Connection Group containing Calling Clone on a Connection yields a Connection Group containing
two Connections: the parent Connection on which Clone was called, and two Connections: the parent Connection on which Clone was called, and
a resulting cloned Connection. The new Connection is actively a resulting cloned Connection. The new Connection is actively
openend, and it will send a Ready Event or an EstablishmentError openend, and it will locally send a Ready Event or an
Event. Calling Clone on any of these Connections adds another EstablishmentError Event. Calling Clone on any of these Connections
Connection to the Connection Group. Connections in a Connection adds another Connection to the Connection Group. Connections in a
Group share all Connection Properties except connPriority (see Connection Group share all Connection Properties except connPriority
Section 8.1.2), and these Connection Properties are entangled: (see Section 8.1.2), and these Connection Properties are entangled:
Changing one of the Connection Properties on one Connection in the Changing one of the Connection Properties on one Connection in the
Connection Group automatically changes the Connection Property for Connection Group automatically changes the Connection Property for
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.
skipping to change at page 43, line 28 skipping to change at page 44, line 28
Connections will belong to the same group if the application Connections will belong to the same group if the application
previously called Clone. Passive Connections can also be added to previously called Clone. Passive Connections can also be added to
the same group -- e.g., when a Listener receives a new Connection the same group -- e.g., when a Listener receives a new Connection
that is just a new stream of an already active multi-streaming that is just a new stream of an already active multi-streaming
protocol instance. protocol instance.
If the underlying protocol supports multi-streaming, it is natural to If the underlying protocol supports multi-streaming, it is natural to
use this functionality to implement Clone. In that case, Connections use this functionality to implement Clone. In that case, Connections
in a Connection Group are multiplexed together, giving them similar in a Connection Group are multiplexed together, giving them similar
treatment not only inside endpoints, but also across the end-to-end treatment not only inside Endpoints, but also across the end-to-end
Internet path. Internet path.
Note that calling Clone() can result in on-the-wire signaling, e.g., Note that calling Clone() can result in on-the-wire signaling, e.g.,
to open a new transport connection, depending on the underlying to open a new transport connection, depending on the underlying
Protocol Stack. When Clone() leads to the opening of multiple such Protocol Stack. When Clone() leads to the opening of multiple such
connections, the Transport Services system will ensure consistency of connections, the Transport Services system will ensure consistency of
Connection Properties by uniformly applying them to all underlying Connection Properties by uniformly applying them to all underlying
connections in a group. Even in such a case, there are possibilities connections in a group. Even in such a case, there are possibilities
for a Transport Services system to implement prioritization within a for a Transport Services system to implement prioritization within a
Connection Group [TCP-COUPLING] [RFC8699]. Connection Group [TCP-COUPLING] [RFC8699].
skipping to change at page 44, line 19 skipping to change at page 45, line 19
communicating with, and the paths to those endpoints. A PathChange<> communicating with, and the paths to those endpoints. A PathChange<>
event, described in Section 8.3.2, will be generated when the path event, described in Section 8.3.2, will be generated when the path
changes. changes.
In some cases, however, it is necessary to explicitly indicate to a In some cases, however, it is necessary to explicitly indicate to a
Connection that a new remote endpoint has become available for use, Connection that a new remote endpoint has become available for use,
or to indicate that some remote endpoint is no longer available. or to indicate that some remote endpoint is no longer available.
This is most common in the case of peer to peer connections using This is most common in the case of peer to peer connections using
Trickle ICE [RFC8838]. Trickle ICE [RFC8838].
The AddRemote() action can be used to add one or more new remote The AddRemote() action can be used to add one or more new Remote
endpoints to a Connection: Endpoints to a Connection:
Connection.AddRemote([]RemoteEndpoint) Connection.AddRemote([]RemoteEndpoint)
Endpoints that are already known to the Connection are ignored. A Endpoints that are already known to the Connection are ignored. A
call to AddRemote() makes the new remote endpoints available to the call to AddRemote() makes the new Remote Endpoints available to the
connection, but whether the Connection makes use of those endpoints Connection, but whether the Connection makes use of those endpoints
will depend on the underlying transport protocol. will depend on the underlying transport protocol.
Similarly, the RemoveRemote() action can be used to tell a connection Similarly, the RemoveRemote() action can be used to tell a connection
to stop using one or more remote endpoints: to stop using one or more Remote Endpoints:
Connection.RemoveRemote([]RemoteEndpoint) Connection.RemoveRemote([]RemoteEndpoint)
Removing all known remote endpoints can have the effect of aborting Removing all known remote endpoints can have the effect of aborting
the connection. The effect of removing the active remote endpoint(s) the connection. The effect of removing the active Remote Endpoint(s)
depends on the underlying transport: multipath aware transports might depends on the underlying transport: multipath aware transports might
be able to switch to a new path if other reachable remote endpoints be able to switch to a new path if other reachable Remote Endpoints
exist, or the connection might abort. exist, or the connection might abort.
Similarly, the AddLocal() and RemoveLocal() actions can be used to Similarly, the AddLocal() and RemoveLocal() actions can be used to
add and remove local endpoints to/from a Connection. add and remove local endpoints to/from a Connection.
8. Managing Connections 8. Managing Connections
During pre-establishment and after establishment, connections can be During pre-establishment and after establishment, connections can be
configured and queried using Connection Properties, and asynchronous configured and queried using Connection Properties, and asynchronous
information may be available about the state of the connection via information may be available about the state of the connection via
skipping to change at page 46, line 25 skipping to change at page 47, line 25
application specified on the Preconnection. Selection Properties application specified on the Preconnection. Selection Properties
of type Preference will be exposed as boolean values indicating of type Preference will be exposed as boolean values indicating
whether or not the property applies to the selected transport. whether or not the property applies to the selected transport.
Note that the instantiated protocol stack might not match all Note that the instantiated protocol stack might not match all
Protocol Selection Properties that the application specified on Protocol Selection Properties that the application specified on
the Preconnection. the Preconnection.
* For Connections that are Established: information concerning the * For Connections that are Established: information concerning the
path(s) used by the Protocol Stack. This can be derived from path(s) used by the Protocol Stack. This can be derived from
local PVD information, measurements by the Protocol Stack, or local PVD information, measurements by the Protocol Stack, or
other sources. For example, a TAPS system that is configured to other sources. For example, a Transport System that is configured
receive and process PVD information [RFC7556] could also provide to receive and process PVD information [RFC7556] could also
network configuration information for the chosen path(s). provide network configuration information for the chosen path(s).
8.1. Generic Connection Properties 8.1. Generic Connection Properties
Generic Connection Properties are defined independent of the chosen Generic Connection Properties are defined independent of the chosen
protocol stack and therefore available on all Connections. protocol stack and therefore available on all Connections.
Many Connection Properties have a corresponding Selection Property Many Connection Properties have a corresponding Selection Property
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.
skipping to change at page 77, line 30 skipping to change at page 78, line 30
intended for path exposure, e.g., a DiffServ codepoint setting, that intended for path exposure, e.g., a DiffServ codepoint setting, that
is either provided directly by the application or indirectly is either provided directly by the application or indirectly
configured for a traffic profile. configured for a traffic profile.
Applications should be aware that communication attempts can lead to Applications should be aware that communication attempts can lead to
more than one connection establishment. This is the case, for more than one connection establishment. This is the case, for
example, when the Transport Services system also executes name example, when the Transport Services system also executes name
resolution, when support mechanisms such as TURN or ICE are used to resolution, when support mechanisms such as TURN or ICE are used to
establish connectivity, if protocols or paths are raised, or if a establish connectivity, if protocols or paths are raised, or if a
path fails and fallback or re-establishment is supported in the path fails and fallback or re-establishment is supported in the
Transport Services system. Transport Services system. Applications should take special care
when using 0-RTT session resumption (see Section 6.2.5), as early
data sent across multiple paths during connection establishment may
reveal information that can be used to correlate endpoints on these
paths.
Applications should also take care to not assume that all data Applications should also take care to not assume that all data
received using the Transport Services API is always complete or well- received using the Transport Services API is always complete or well-
formed. Specifically, messages that are received partially formed. Specifically, messages that are received partially
Section 9.3.2.2 could be a source of truncation attacks if Section 9.3.2.2 could be a source of truncation attacks if
applications do not distinguish between partial messages and complete applications do not distinguish between partial messages and complete
messages. messages.
The Transport Services API explicitly does not require the The Transport Services API explicitly does not require the
application to resolve names, though there is a tradeoff between application to resolve names, though there is a tradeoff between
skipping to change at page 79, line 51 skipping to change at page 80, line 51
15.2. Informative References 15.2. Informative References
[I-D.ietf-httpbis-priority] [I-D.ietf-httpbis-priority]
Oku, K. and L. Pardue, "Extensible Prioritization Scheme Oku, K. and L. Pardue, "Extensible Prioritization Scheme
for HTTP", Work in Progress, Internet-Draft, draft-ietf- for HTTP", Work in Progress, Internet-Draft, draft-ietf-
httpbis-priority-12, 17 January 2022, httpbis-priority-12, 17 January 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
priority-12>. priority-12>.
[I-D.ietf-taps-impl] [I-D.ietf-taps-impl]
Brunstrom, A., Pauly, T., Enghardt, T., 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-12, Work in Progress, Internet-Draft, draft-ietf-taps-impl-13,
7 March 2022, <https://datatracker.ietf.org/doc/html/ 31 August 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-taps-impl-12>. draft-ietf-taps-impl-13>.
[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,
skipping to change at page 80, line 31 skipping to change at page 81, line 31
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<https://www.rfc-editor.org/rfc/rfc3246>. <https://www.rfc-editor.org/rfc/rfc3246>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/rfc/rfc3261>. <https://www.rfc-editor.org/rfc/rfc3261>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/rfc/rfc3376>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006, DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/rfc/rfc4594>. <https://www.rfc-editor.org/rfc/rfc4594>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
August 2006, <https://www.rfc-editor.org/rfc/rfc4604>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010, DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/rfc/rfc5245>. <https://www.rfc-editor.org/rfc/rfc5245>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
 End of changes. 62 change blocks. 
231 lines changed or deleted 288 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/