doc: Add RFC documents

1 files changed, 465 insertions, 0 deletions

diff --git a/doc/rfc/rfc8850.txt b/doc/rfc/rfc8850.txt
new file mode 100644
index 0000000..e5a1e11
--- /dev/null
+++ b/doc/rfc/rfc8850.txt
@@ -0,0 +1,465 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       C. Holmberg
+Request for Comments: 8850                                      Ericsson
+Category: Experimental                                      January 2021
+ISSN: 2070-1721
+
+
+     Controlling Multiple Streams for Telepresence (CLUE) Protocol
+                              Data Channel
+
+Abstract
+
+   This document defines how to use the WebRTC data channel mechanism to
+   realize a data channel, referred to as a Controlling Multiple Streams
+   for Telepresence (CLUE) data channel, for transporting CLUE protocol
+   messages between two CLUE entities.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are candidates for any level of
+   Internet Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8850.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Conventions
+   3.  CLUE Data Channel
+     3.1.  General
+     3.2.  SCTP Considerations
+       3.2.1.  General
+       3.2.2.  SCTP Payload Protocol Identifier (PPID)
+       3.2.3.  Reliability
+       3.2.4.  Order
+       3.2.5.  Stream Reset
+       3.2.6.  SCTP Multihoming
+       3.2.7.  Closing the CLUE Data Channel
+     3.3.  SDP Considerations
+       3.3.1.  General
+       3.3.2.  SDP dcmap Attribute
+       3.3.3.  SDP dcsa Attribute
+       3.3.4.  Example
+   4.  Security Considerations
+   5.  IANA Considerations
+     5.1.  Subprotocol Identifier "clue"
+   6.  References
+     6.1.  Normative References
+     6.2.  Informative References
+   Acknowledgements
+   Author's Address
+
+1.  Introduction
+
+   This document defines how to use the WebRTC data channel mechanism
+   [RFC8831] to realize a data channel, referred to as a Controlling
+   Multiple Streams for Telepresence (CLUE) data channel, for
+   transporting CLUE protocol messages [RFC8847] between two CLUE
+   entities.
+
+   This document also defines how to describe the SCTPoDTLS association
+   [RFC8261] (also referred to as "SCTP over DTLS" in this document)
+   used to realize the CLUE data channel using the Session Description
+   Protocol (SDP) [RFC4566] and defines usage of the SDP-based "SCTP
+   over DTLS" data channel negotiation mechanism [RFC8864].  ("SCTP"
+   stands for "Stream Control Transmission Protocol".)  This includes
+   SCTP considerations specific to a CLUE data channel, the SDP media
+   description ("m=" line) values, and usage of SDP attributes specific
+   to a CLUE data channel.
+
+   Details and procedures associated with the CLUE protocol, and the SDP
+   Offer/Answer procedures [RFC3264] for negotiating usage of a CLUE
+   data channel, are outside the scope of this document.
+
+      |  NOTE: The usage of the Data Channel Establishment Protocol
+      |  (DCEP) [RFC8832] for establishing a CLUE data channel is
+      |  outside the scope of this document.
+
+2.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   SCTPoDTLS association
+      Refers to an SCTP association carried over a DTLS connection
+      [RFC8261].
+
+   WebRTC data channel
+      Refers to a pair of SCTP streams over an SCTPoDTLS association
+      that is used to transport non-media data between two entities, as
+      defined in [RFC8831].
+
+   CLUE data channel
+      Refers to a WebRTC data channel realization [RFC8831], with a
+      specific set of SCTP characteristics, with the purpose of
+      transporting CLUE protocol messages [RFC8847] between two CLUE
+      entities.
+
+   CLUE entity
+      Refers to a SIP User Agent (UA) [RFC3261] that supports the CLUE
+      data channel and the CLUE protocol.
+
+   CLUE session
+      Refers to a SIP session [RFC3261] between two SIP UAs, where a
+      CLUE data channel, associated with the SIP session, has been
+      established between the SIP UAs.
+
+   SCTP stream
+      Defined in [RFC4960] as a unidirectional logical channel
+      established from one to another associated SCTP endpoint, within
+      which all user messages are delivered in sequence except for those
+      submitted to the unordered delivery service.
+
+   SCTP stream identifier
+      Defined in [RFC4960] as an unsigned integer.  Identifies an SCTP
+      stream.
+
+3.  CLUE Data Channel
+
+3.1.  General
+
+   This section describes the realization of a CLUE data channel, using
+   the WebRTC data channel mechanism.  This includes a set of SCTP
+   characteristics specific to a CLUE data channel, the values of the
+   "m=" line describing the SCTPoDTLS association associated with the
+   WebRTC data channel, and the usage of the SDP-based "SCTP over DTLS"
+   data channel negotiation mechanism for creating the CLUE data
+   channel.
+
+   As described in [RFC8831], the SCTP streams realizing a WebRTC data
+   channel must be associated with the same SCTP association.  In
+   addition, both SCTP streams realizing the WebRTC data channel must
+   use the same SCTP stream identifier value.  These rules also apply to
+   a CLUE data channel.
+
+   Within a given CLUE session, a CLUE entity MUST use a single CLUE
+   data channel for transport of all CLUE messages towards its peer.
+
+3.2.  SCTP Considerations
+
+3.2.1.  General
+
+   As described in [RFC8831], different SCTP options (e.g., regarding
+   ordered delivery) can be used for a data channel.  This section
+   describes the SCTP options used for a CLUE data channel.  Section 3.3
+   describes how SCTP options are signaled using SDP.
+
+3.2.2.  SCTP Payload Protocol Identifier (PPID)
+
+   A CLUE entity MUST use the PPID value 51 when sending a CLUE message
+   on a CLUE data channel.
+
+      |  NOTE: As described in [RFC8831], the PPID value 51 indicates
+      |  that the SCTP message contains data encoded in UTF-8 format.
+      |  The PPID value 51 does not indicate which application protocol
+      |  the SCTP message is associated with -- only the format in which
+      |  the data is encoded.
+
+3.2.3.  Reliability
+
+   The usage of SCTP for the CLUE data channel ensures reliable
+   transport of CLUE protocol messages [RFC8847].
+
+   [RFC8831] requires the support of the partial reliability extension
+   defined in [RFC3758] and the limited retransmission policy defined in
+   [RFC7496].  A CLUE entity MUST NOT use these extensions, as messages
+   are required to always be sent reliably.  A CLUE entity MUST
+   terminate the session if it detects that the peer entity uses any of
+   the extensions.
+
+3.2.4.  Order
+
+   A CLUE entity MUST use the ordered delivery SCTP service, as
+   described in [RFC4960], for the CLUE data channel.
+
+3.2.5.  Stream Reset
+
+   A CLUE entity MUST support the stream reset extension defined in
+   [RFC6525].
+
+   Per [RFC8831], the dynamic address reconfiguration extension
+   parameter ('Supported Extensions Parameter') defined in [RFC5061]
+   must be used to signal the support of the stream reset extension
+   defined in [RFC6525].  Other features defined in [RFC5061] MUST NOT
+   be used for CLUE data channels.
+
+3.2.6.  SCTP Multihoming
+
+   SCTP multihoming is not supported for SCTPoDTLS associations and
+   therefore cannot be used for a CLUE data channel.
+
+3.2.7.  Closing the CLUE Data Channel
+
+   As described in [RFC8831], to close a data channel, an entity sends
+   an SCTP reset message [RFC6525] on its outgoing SCTP stream
+   associated with the data channel.  When the remote peer receives the
+   reset message, it also sends (unless already sent) a reset message on
+   its outgoing SCTP stream associated with the data channel.  The
+   SCTPoDTLS association, and other data channels established on the
+   same association, are not affected by the SCTP reset messages.
+
+3.3.  SDP Considerations
+
+3.3.1.  General
+
+   This section defines how to (1) construct the SDP media description
+   ("m=" line) for describing the SCTPoDTLS association used to realize
+   a CLUE data channel and (2) use the SDP-based "SCTP over DTLS" data
+   channel negotiation mechanism [RFC8864] for establishing a CLUE data
+   channel on the SCTPoDTLS association.
+
+      |  NOTE: Protocols other than SDP for negotiating usage of an
+      |  SCTPoDTLS association for realizing a CLUE data channel are
+      |  outside the scope of this specification.
+
+   [RFC8848] describes the SDP Offer/Answer procedures for negotiating a
+   CLUE session, including the CLUE-controlled media streams and the
+   CLUE data channel.
+
+3.3.1.1.  SDP Media Description Fields
+
+   [RFC8841] defines how to set the values of an "m=" line describing an
+   SCTPoDTLS association.  As defined in [RFC8841], for a CLUE data
+   channel the values are set as follows:
+
+     +===============+==========+============+======================+
+     |     media     |   port   |   proto    |         fmt          |
+     +===============+==========+============+======================+
+     | "application" | UDP port | "UDP/DTLS/ | "webrtc-datachannel" |
+     |               |  value   |   SCTP"    |                      |
+     +---------------+----------+------------+----------------------+
+     | "application" | TCP port | "TCP/DTLS/ | "webrtc-datachannel" |
+     |               |  value   |   SCTP"    |                      |
+     +---------------+----------+------------+----------------------+
+
+                    Table 1: SDP "proto" Field Values
+
+   CLUE entities SHOULD NOT transport the SCTPoDTLS association used to
+   realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP"
+   proto value), unless it is known that UDP/DTLS/SCTP will not work
+   (for instance, when the Interactive Connectivity Establishment (ICE)
+   mechanism [RFC8445] is used and the ICE procedures determine that TCP
+   transport is required).
+
+3.3.1.2.  SDP sctp-port Attribute
+
+   As defined in [RFC8841], the SDP sctp-port attribute value is set to
+   the SCTP port of the SCTPoDTLS association.  A CLUE entity can choose
+   any valid SCTP port value [RFC8841].
+
+3.3.2.  SDP dcmap Attribute
+
+   The values of the SDP dcmap attribute [RFC8864], associated with the
+   "m=" line describing the SCTPoDTLS association used to realize the
+   WebRTC data channel, are set as follows:
+
+   +===========+=============+=============+=======+========+==========+
+   | stream-id | subprotocol |    label    |ordered|max-retr| max-time |
+   +===========+=============+=============+=======+========+==========+
+   |  Value of |    "CLUE"   | Application | "true"|  N/A   |   N/A    |
+   |  the SCTP |             |   specific  |       |        |          |
+   |stream used|             |             |       |        |          |
+   | to realize|             |             |       |        |          |
+   |  the CLUE |             |             |       |        |          |
+   |    data   |             |             |       |        |          |
+   |  channel  |             |             |       |        |          |
+   +-----------+-------------+-------------+-------+--------+----------+
+
+                    Table 2: SDP dcmap Attribute Values
+
+      |  NOTE: As CLUE entities are required to use ordered SCTP message
+      |  delivery, with full reliability, according to the procedures in
+      |  [RFC8864] the max-retr and max-time attribute parameters are
+      |  not used when negotiating CLUE data channels.
+
+3.3.3.  SDP dcsa Attribute
+
+   The SDP dcsa attribute [RFC8864] is not used when establishing a CLUE
+   data channel.
+
+3.3.4.  Example
+
+   The example in Figure 1 shows an SDP media description for a CLUE
+   data channel.  Complete SDP examples can be found in [RFC8848].
+
+            m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
+            a=sctp-port: 5000
+            a=dcmap:2 subprotocol="CLUE";ordered=true
+
+          Figure 1: SDP Media Description for a CLUE Data Channel
+
+4.  Security Considerations
+
+   This specification relies on the security properties of the WebRTC
+   data channel described in [RFC8831], including reliance on DTLS.
+   Since CLUE sessions are established using SIP/SDP, protecting the
+   data channel against message modification and recovery requires the
+   use of SIP authentication and authorization mechanisms described in
+   [RFC3261] for session establishment prior to establishing the data
+   channel.
+
+5.  IANA Considerations
+
+5.1.  Subprotocol Identifier "clue"
+
+   This document adds the subprotocol identifier "clue" to the
+   "WebSocket Subprotocol Name Registry" as follows:
+
+                  +-------------------------+----------+
+                  | Subprotocol Identifier  | clue     |
+                  +-------------------------+----------+
+                  | Subprotocol Common Name | CLUE     |
+                  +-------------------------+----------+
+                  | Subprotocol Definition  | RFC 8850 |
+                  +-------------------------+----------+
+                  | Reference               | RFC 8850 |
+                  +-------------------------+----------+
+
+                  Table 3: Registration of 'clue' Value
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              DOI 10.17487/RFC3261, June 2002,
+              <https://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264,
+              DOI 10.17487/RFC3264, June 2002,
+              <https://www.rfc-editor.org/info/rfc3264>.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
+              July 2006, <https://www.rfc-editor.org/info/rfc4566>.
+
+   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
+              RFC 4960, DOI 10.17487/RFC4960, September 2007,
+              <https://www.rfc-editor.org/info/rfc4960>.
+
+   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
+              Kozuka, "Stream Control Transmission Protocol (SCTP)
+              Dynamic Address Reconfiguration", RFC 5061,
+              DOI 10.17487/RFC5061, September 2007,
+              <https://www.rfc-editor.org/info/rfc5061>.
+
+   [RFC6525]  Stewart, R., Tuexen, M., and P. Lei, "Stream Control
+              Transmission Protocol (SCTP) Stream Reconfiguration",
+              RFC 6525, DOI 10.17487/RFC6525, February 2012,
+              <https://www.rfc-editor.org/info/rfc6525>.
+
+   [RFC7496]  Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
+              "Additional Policies for the Partially Reliable Stream
+              Control Transmission Protocol Extension", RFC 7496,
+              DOI 10.17487/RFC7496, April 2015,
+              <https://www.rfc-editor.org/info/rfc7496>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8261]  Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
+              "Datagram Transport Layer Security (DTLS) Encapsulation of
+              SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
+              2017, <https://www.rfc-editor.org/info/rfc8261>.
+
+   [RFC8831]  Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
+              Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
+              <https://www.rfc-editor.org/info/rfc8831>.
+
+   [RFC8841]  Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo,
+              "Session Description Protocol (SDP) Offer/Answer
+              Procedures for Stream Control Transmission Protocol (SCTP)
+              over Datagram Transport Layer Security (DTLS) Transport",
+              RFC 8841, DOI 10.17487/RFC8841, January 2021,
+              <https://www.rfc-editor.org/info/rfc8841>.
+
+   [RFC8864]  Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R.
+              Even, Ed., "Negotiation Data Channels Using the Session
+              Description Protocol (SDP)", RFC 8864,
+              DOI 10.17487/RFC8864, January 2021,
+              <https://www.rfc-editor.org/info/rfc8864>.
+
+6.2.  Informative References
+
+   [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+              Conrad, "Stream Control Transmission Protocol (SCTP)
+              Partial Reliability Extension", RFC 3758,
+              DOI 10.17487/RFC3758, May 2004,
+              <https://www.rfc-editor.org/info/rfc3758>.
+
+   [RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
+              Connectivity Establishment (ICE): A Protocol for Network
+              Address Translator (NAT) Traversal", RFC 8445,
+              DOI 10.17487/RFC8445, July 2018,
+              <https://www.rfc-editor.org/info/rfc8445>.
+
+   [RFC8832]  Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channel
+              Establishment Protocol", RFC 8832, DOI 10.17487/RFC8832,
+              January 2021, <https://www.rfc-editor.org/info/rfc8832>.
+
+   [RFC8847]  Presta, R. and S P. Romano, "Protocol for Controlling
+              Multiple Streams for Telepresence (CLUE)", RFC 8847,
+              DOI 10.17487/RFC8847, January 2021,
+              <https://www.rfc-editor.org/info/rfc8847>.
+
+   [RFC8848]  Hanton, R., Kyzivat, P., Xiao, L., and C. Groves, "Session
+              Signaling for Controlling Multiple Streams for
+              Telepresence (CLUE)", RFC 8848, DOI 10.17487/RFC8848,
+              January 2021, <https://www.rfc-editor.org/info/rfc8848>.
+
+Acknowledgements
+
+   Thanks to Paul Kyzivat, Christian Groves, and Mark Duckworth for
+   comments on this document.
+
+Author's Address
+
+   Christer Holmberg
+   Ericsson
+   Hirsalantie 11
+   FI-02420 Jorvas
+   Finland
+
+   Email: christer.holmberg@ericsson.com