--- 1/draft-ietf-rtcweb-data-protocol-00.txt 2013-10-21 13:14:44.949424413 -0700 +++ 2/draft-ietf-rtcweb-data-protocol-01.txt 2013-10-21 13:14:44.973424996 -0700 @@ -1,47 +1,48 @@ RTCWeb Working Group R. Jesup Internet-Draft Mozilla Intended status: Standards Track S. Loreto -Expires: January 16, 2014 Ericsson +Expires: April 24, 2014 Ericsson M. Tuexen Muenster Univ. of Appl. Sciences - July 15, 2013 + October 21, 2013 - WebRTC Data Channel Protocol - draft-ietf-rtcweb-data-protocol-00.txt + RTCWeb Data Channel Protocol + draft-ietf-rtcweb-data-protocol-01.txt Abstract The Web Real-Time Communication (WebRTC) working group is charged to provide protocols to support for direct interactive rich communication using audio, video, and data between two peers' web- - browsers. This document specifies an actual (minor) protocol for how - the JS-layer DataChannel objects provide the data channels between - the peers. + browsers. This document specifies a simple protocol for establishing + symmetric data channels between the peers. It uses a two way + handshake and allows sending of user data without waiting for the + handshake to complete. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 16, 2014. + This Internet-Draft will expire on April 24, 2014. Copyright Notice Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -50,135 +51,122 @@ 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 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 - 5. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 4 - 6. Control Messages . . . . . . . . . . . . . . . . . . . . . . 4 - 6.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4 - 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 7.1. Adding a Channel (in-band open) . . . . . . . . . . . . . 6 - 7.2. Adding a Channel (external negotiation) . . . . . . . . . 7 - 7.3. Closing a Channel . . . . . . . . . . . . . . . . . . . . 7 - 7.4. Sending and Receiving Data . . . . . . . . . . . . . . . 8 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 - 11.2. Informational References . . . . . . . . . . . . . . . . 10 + 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4 + 5.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4 + 5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 6 + 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 7 + 8.2. New Message Type Registry . . . . . . . . . . . . . . . . 8 + 8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 8 + 8.4. New Protocol Registry . . . . . . . . . . . . . . . . . . 9 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 10.2. Informational References . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction - The DataChannel Protocol is designed to provide, in the WebRTC - context [I-D.ietf-rtcweb-overview], a generic transport service - allowing a Web Browser to exchange generic data in a bidirectional - peer to peer fashion. As discussed in [I-D.ietf-rtcweb-data-channel] - the protocol uses Stream Control Transmission Protocol (SCTP) - [RFC4960] encapsulated on Datagram Transport Layer Security (DTLS) - [RFC6347] as described in [I-D.ietf-tsvwg-sctp-dtls-encaps] to - benefit from their already standardized transport and security - features. + The data channel protocol is designed to provide, in the WebRTC data + channel context [I-D.ietf-rtcweb-data-channel], a simple in-band + method to open symmetric data channels. As discussed in + [I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control + Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram + Transport Layer Security (DTLS) [RFC6347] as described in + [I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already + standardized transport and security features. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology This document uses the following terms: Association: An SCTP association. Stream: A unidirectional stream of an SCTP association. It is - uniquely identified by a stream identifier (0-65535). + uniquely identified by a stream identifier (0-65534). Note: + stream identifier 65535 is reserved due to SCTP Init messages + allowing a maximum of 65535 streams to be negotiated (0-65534). Channel: Two Streams with the same identifier, one in each - direction, that are managed together. + direction, which are managed together. 4. Protocol Overview This protocol is a simple, low-overhead way to establish bidirectional Channels over an SCTP association with a consistent set of properties. - Channels are created by sending an optional DATA_CHANNEL_OPEN message - on an unused Stream. There is no handshake, and the channel is - available to send on as soon as the DATA_CHANNEL_OPEN has been sent. - Alternatively, both sides make externally agree to a set of - parameters for a Channel, in which case no DATA_CHANNEL_OPEN message - is required. + The set of consistent properties includes - To avoid glare in opening Channels, each side must use either even or + o whether the messages are transmitted reliable or unreliable. In + case of unreliable transmissions, the same level of unreliability + is used. + + o whether the messages are delivered in-order or out-of order. + + o an optional label for the Channel. + + o an optional protocol for the Channel. + + o the outgoing SCTP stream. + + The data channel protocol uses a two way handshake to open a data + channel. The side wanting to open a data channel selects an unused + Stream and sends a DATA_CHANNEL_OPEN message. The peer responds with + a DATA_CHANNEL_ACK message. Then the data channel is open. Please + note that the opening side can send user messages before the + DATA_CHANNEL_ACK is received. These data channel messages are sent + on the same Stream as the user messages belonging to the data + channel. The demultiplexing is based on the SCTP payload protocol + identifier. + + To avoid glare in opening Channels, each side MUST use either even or odd Streams when sending a DATA_CHANNEL_OPEN message. The method used to determine which side uses odd or even is based on the - underlying DTLS connection role when used in rtcweb, with the side + underlying DTLS connection role when used in RTCWeb, with the side acting as the DTLS client using even stream identifiers. Note: There is no attempt to resolve label glare; if both sides open - a Channel labelled "x" at the same time, there will be two Channels - labelled "x" - one on an even Stream pair, one on an odd pair. + a Channel labeled "x" at the same time, there will be two Channels + labeled "x" - one on an even Stream pair, one on an odd pair. The protocol field is to ease cross-application interoperation ("federation") by identifying the data being passed with an IANA- - registered string, and may also be useful for homogenous applications + registered string, and may be useful for homogenous applications which may create more than one type of Channel. - Data that arrives which on an unused Stream MUST be held for a period - TBD until a DATA_CHANNEL_OPEN arrived for that Channel, or until the - protocol stack has been told to expect data on that Stream (via - external negotiation), or until [TBD - report error]. This allows - for external negotiation of streams (or assumption of negotiation by - cooperating applications). If a later DATA_CHANNEL_OPEN arrives that - conflicts with the pre-set properties of the Channel, an error should - be signaled to higher levels. - - Channels are closed by an SCTP reset of the Stream. - -5. Opening Handshake - - The opening handshake is based on the multimedia session description - exchange that happens between the browsers, typically through a Web - Server acting as the signaling service. - - [I-D.ietf-mmusic-sctp-sdp] defines the protocol identifier, 'DTLS/ - SCTP', and defines how to establish an SCTP association over DTLS - using the Session Description Protocol (SDP). - - The SCTP association is created with the number of streams specified - by the application, and if not specified, then it SHOULD default to - 16 streams. - - It is recommended that additional streams be available dynamically - based on [RFC6525]. - -6. Control Messages - - Control Messages are sent to manage opening bidirectional channels. +5. Message Formats - A DATA_CHANNEL_OPEN message is sent on the Stream that is intended to - be used for a new Channel, and this creates a bidirectional Channel - that may be used by both sides to send data. + Every data channel protocol message starts with a one byte field + called "Message Type" which indicates the type of the message. The + corresponding values are managed by IANA (see Section 8.2). -6.1. DATA_CHANNEL_OPEN Message +5.1. DATA_CHANNEL_OPEN Message This message is sent initially on the stream used for user messages - using the channel. All DATA_CHANNEL_OPEN messages MUST be sent using - SCTP options for reliable in-order delivery. + using the channel. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Channel Type | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reliability Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Length | Protocol Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -187,26 +175,25 @@ / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ / | Protocol | / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type: 1 byte (unsigned integer) This field holds the IANA defined message type for the the DATA_CHANNEL_OPEN message. The suggested value of this field for - IANA is 0x03. NOTE: values 0x00-0x02 were used in an older draft - with incompatible structures. Any future incompatible message - changes should define new message types. + IANA is 0x03. Channel Type: 1 byte (unsigned integer) - This field specifies the type of the channel to be opened: + This field specifies the type of the channel to be opened and the + values are managed by IANA (see Section 8.3): DATA_CHANNEL_RELIABLE (0x00): The channel provides a reliable in- order bi-directional communication channel. DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The channel provides a reliable unordered bi-directional communication channel. DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The channel provides a partially-reliable in-order bi-directional Communication channel. User messages will not be retransmitted more times @@ -248,194 +235,248 @@ The length of the label field in bytes. Protocol Length: 2 bytes (unsigned integer) The length of the protocol field in bytes. Label: Variable Length (sequence of characters) The name of the channel. This may be an empty string. Protocol: Variable Length (sequence of characters) The protocol for the channel. This may be an empty string. If - used, it SHOULD be an IANA-registered protocol. + used, it is an IANA-registered protocol (see Section 8.4). -7. Procedures +5.2. DATA_CHANNEL_ACK Message -7.1. Adding a Channel (in-band open) - When one side wants to add a channel using in-band declaration, it - picks an unused outgoing Stream (even stream identifier for DTLS - clients, or odd for DTLS servers); if no unused streams are available - a negotiation to increase the number is done via [RFC6525], or - failure is returned. It should also check that the other side has - the same channel available, and if not then initiate an increase in - the number of streams. It then sends a DATA_CHANNEL_OPEN control - message on the outgoing stream. + This message is sent in response to an DATA_CHANNEL_OPEN_RESPONSE + message on the stream used for user messages using the channel. + Reception of this message tells the opener that the channel setup + handshake is complete. - When an DATA_CHANNEL_OPEN is received on an incoming Stream, the - Stream is associated with a newly-created Channel (unless the Stream - was already part of an externally-negotiated Channel). If any data - had arrived on the Stream before the Open arrives and had been - buffered, it is now delivered on the new Channel. + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message Type | + +-+-+-+-+-+-+-+-+ - The channel_type and reliability_parameters fields of the - DATA_CHANNEL_OPEN message MUST be used to set up the reverse side of - the Channel so that both directions use the same options by default. + Message Type: 1 byte (unsigned integer) + This field holds the IANA defined message type for the the + DATA_CHANNEL_ACK message. The suggested value of this field for + IANA is 0x02. -7.2. Adding a Channel (external negotiation) +6. Procedures - When one side wants to add a channel using external negotiation, it - picks a Stream. This can be done by asking the protocol to select an - unused Stream (of the approriate even or odd type), or by simply - telling the protocol what Stream to use. In the latter case, the - application is responsible for avoiding collisions with existing - Streams. If it attempts to re-use a Stream which is part of an - existing Channel, the addition should fail. + All data channel protocol messages MUST be sent requesting ordered + delivery and using reliable transmission. They MUST be sent on the + same outgoing SCTP stream as the user messages belonging to the + corresponding data channel. Multiplexing and demultiplexing is done + by using the SCTP payload protocol identifier (PPID). Therefore data + channel protocol message MUST be sent with the assigned PPID for the + data channel protocol (see Section 8.1). Other message MUST NOT be + sent using this PPID. - In addition to choosing a Stream, the application should also inform - the protocol of the options to use for sending messages. Note that - there is no requirement for both sides to have the same options for - an externally-negotiated stream, though typically this will be the - case. + If one sides wants to open a data channel, it chooses a free outgoing + SCTP stream. If the side is the DTLS client, it MUST choose an even + stream identifier, if the side is the DTLS server, it MUST choose an + odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message + and sends it on the chosen SCTP stream. - The application must now ensure in an application-specific manner - that the other side will also inform the protocol that the selected - Stream is to be used, and the parameters for sending data from that - side. + After the DATA_CHANNEL_OPEN message has been sent, the sender of it + can start sending messages containing user data without waiting for + the reception of the corresponding DATA_CHANNEL_ACK message. + However, before the DATA_CHANNEL_ACK message or any other message has + been received on the data channel, all other messages containing user + data and belonging to the data channel MUST be sent ordered, not + matter whether the data channel is ordered or not. After the + DATA_CHANNEL_ACK or any other message has been received on the data + channel, messages containing user data MUST be send ordered on + ordered data channels and MUST be sent unordered on unordered data + channels. Therefore receiving a message containing user data on an + unused SCTP stream indicates an error. The corresponding outgoing + SCTP stream MUST be reset using [RFC6525]. -7.3. Closing a Channel + If a DATA_CHANNEL_OPEN message is received on an unused stream, the + stream identifier corresponds to the role of the peer and all + parameters in the DATA_CHANNEL_OPEN message are valid, then a + corresponding DATA_CHANNEL_ACK message is sent on the stream with the + same stream identifier as the one the DATA_CHANNEL_OPEN message was + received on. - Channels MUST be closed by and SCTP reset of the outgoing Stream. If - an incoming Stream is reset by the peer, an corresponding outgoing - stream reset SHOULD be issued. If the streams in both directions of - a Channel are reset, the Channel is considered fully closed and the - Streams are available for reuse for new channel opens. + If a DATA_CHANNEL_OPEN message is received on an already used SCTP + stream or there are any problems with parameters within the + DATA_CHANNEL_OPEN message or the DATA_CHANNEL_OPEN message itself is + not well-formed, the receiver MUST reset the corresponding outgoing + SCTP stream using [RFC6525] and MUST NOT send a DATA_CHANNEL_ACK + message in response to the received message. Therefore, receiving an + SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK + message has been received indicates to the sender of the + corresponding DATA_CHANNEL_OPEN message the failure of the data + channel setup procedure. -7.4. Sending and Receiving Data +7. Security Considerations - Data shall be sent using PPID's other than the Data Channel Control - PPID. These PPID's should be registered with IANA via (TBD). The - meaning of these data PPIDs and the format of the data shall be - specific to the usage of this protocol, and typically shall be - provided to the higher layers to allow proper decoding of the data. + This document does not add any additional considerations to the ones + given in [I-D.ietf-rtcweb-security] and + [I-D.ietf-rtcweb-security-arch]. - It is RECOMMENDED that higher layers wishing to transfer large - messages fragment them using PPIDs or other mechanisms to avoid - monopolization of the SCTP association by the transfer of a single - large message, unless a future SCTP draft relaxes this concern. If - fragmented solely with PPID values, then transmission MUST occur on a - reliable in-order channel. If in-band application framing is used, - then other options may be possible. +8. IANA Considerations - For WebRTC, data PPID's for DOMStrings and binary data (and - fragmentation thereof) shall be created. + [NOTE to RFC-Editor: - All data sent on a Channel in both directions MUST be sent over the - underlying Stream using the reliability defined when the Channel was - opened unless the options are changed, or per-message options are - specified by a higher level. + "RFCXXXX" is to be replaced by the RFC number you assign this + document. - Data may be sent immediately after sending or receiving a - DATA_CHANNEL_OPEN message, or after creating an externally-negotiated - Channel. + ] - It is recommended that message size be kept within certain size - bounds (TBD) as applications will not be able to support arbitrarily- - large single messages. + IANA is asked to update the reference of an already existing SCTP + PPID assignment and to create three new registries for the data + channel protocol. -8. Security Considerations +8.1. SCTP Payload Protocol Identifier + This document uses one already registered SCTP Payload Protocol + Identifier (PPID). [RFC4960] creates the registry "SCTP Payload + Protocol Identifiers" from which this identifier was assigned. IANA + is requested to update the reference of this assignment to point to + this document. Therefore this assignment should be updated to read: - To be done. + +----------------+-----------+-----------+ + | Value | SCTP PPID | Reference | + +----------------+-----------+-----------+ + | WebRTC Control | 50 | [RFCXXXX] | + +----------------+-----------+-----------+ -9. IANA Considerations +8.2. New Message Type Registry - [NOTE to RFC-Editor: + IANA is requested to create a new registration table "Message Type + Registry" for the data channel protocol to manage the one byte + "Message Type" field in data channel messages (see Section 5). - "RFCXXXX" is to be replaced by the RFC number you assign this - document. + The assignment of new message types is done through an RFC required + action, as defined in [RFC5226]. Documentation of the new message + type MUST contain the following information: - ] + 1. A name for the new message type; - [NOTE to RFC-Editor: + 2. A detailed procedural description of the use of messages with the + new type within the operation of the data channel protocol. - The suggested values for the Payload Protocol Identifiers are - tentative and to be confirmed by IANA. + Initially the following values need to be registered: - ] + +-------------------+-----------+-----------+ + | Name | Type | Reference | + +-------------------+-----------+-----------+ + | Reserved | 0x00 | [RFCXXXX] | + | Reserved | 0x01 | [RFCXXXX] | + | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | + | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | + | Unassigned | 0x04-0xfe | | + | Reserved | 0xff | [RFCXXXX] | + +-------------------+-----------+-----------+ - This document defines five new SCTP Payload Protocol Identifiers - (PPIDs). [RFC4960] creates the registry "SCTP Payload Protocol - Identifiers" from which these identifiers need to be assigned. The - following values are suggested: +8.3. New Channel Type Registry - +---------------------+-----------+-----------+ - | Value | SCTP PPID | Reference | - +---------------------+-----------+-----------+ - | WebRTC Control | 50 | [RFCXXXX] | - | DOMString Last | 51 | [RFCXXXX] | - | Binary Data Partial | 52 | [RFCXXXX] | - | Binary Data Last | 53 | [RFCXXXX] | - | DOMString Partial | 54 | [RFCXXXX] | - +---------------------+-----------+-----------+ + IANA is requested to create a new registration table "Channel Type + Registry" for the data channel protocol to manage the one byte + "Channel Type" field in DATA_CHANNEL_OPEN messages (see Section 5.1). -10. Acknowledgments + The assignment of new message types is done through an RFC required + action, as defined in [RFC5226]. Documentation of the new channel + type MUST contain the following information: + + 1. A name for the new channel type; + + 2. A detailed procedural description of the user message handling + for data channels using this new channel type. + Please note that if new channel types support ordered and unordered + message delivery, the high order bit SHOULD be used to indicated + whether the message delivery is unordered or not. + + Initially the following values need to be registered: + + +------------------------------------------------+------+-----------+ + | Name | Type | Reference | + +------------------------------------------------+------+-----------+ + | DATA_CHANNEL_RELIABLE | 0x00 | [RFCXXXX] | + | DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] | + | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] | + | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] | + | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] | + | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] | + | Reserved | 0x7f | [RFCXXXX] | + | Reserved | 0xff | [RFCXXXX] | + | Unassigned | rest | | + +------------------------------------------------+------+-----------+ + +8.4. New Protocol Registry + + IANA is requested to create a new registration table "Protocol + Registry" for the data channel protocol to manage the "Protocol" + field of type string in DATA_CHANNEL_OPEN messages (see Section 5.1). + + The assignment of new message types is done through an First Come + First Served action, as defined in [RFC5226]. Documentation of the + new protocol MUST contain the following information: + + 1. A name for the protocol; + + 2. A reference for the protocol indicated by the registered string. + + Initially this registry is empty. + +9. Acknowledgments The authors wish to thank Martin Thompson, Cullen Jennings, Harald Alvestrand, Peter Thatcher, Adam Bergkvist, Justin Uberti, Randall Stewart, Stefan Haekansson and many others for their invaluable comments. -11. References +10. References -11.1. Normative References +10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. - Conrad, "Stream Control Transmission Protocol (SCTP) - Partial Reliability Extension", RFC 3758, May 2004. - [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, February 2012. - [I-D.ietf-mmusic-sctp-sdp] - Loreto, S. and G. Camarillo, "Stream Control Transmission - Protocol (SCTP)-Based Media Transport in the Session - Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-04 - (work in progress), June 2013. - [I-D.ietf-tsvwg-sctp-dtls-encaps] - Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS - Encapsulation of SCTP Packets for RTCWEB", draft-ietf- - tsvwg-sctp-dtls-encaps-00 (work in progress), February - 2013. - -11.2. Informational References + Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS + Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- + dtls-encaps-02 (work in progress), October 2013. - [I-D.ietf-rtcweb-overview] - Alvestrand, H., "Overview: Real Time Protocols for Brower- - based Applications", draft-ietf-rtcweb-overview-06 (work - in progress), February 2013. +10.2. Informational References [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data - Channels", draft-ietf-rtcweb-data-channel-04 (work in - progress), February 2013. + Channels", draft-ietf-rtcweb-data-channel-05 (work in + progress), July 2013. -Authors' Addresses + [I-D.ietf-rtcweb-security] + Rescorla, E., "Security Considerations for WebRTC", draft- + ietf-rtcweb-security-05 (work in progress), July 2013. + [I-D.ietf-rtcweb-security-arch] + Rescorla, E., "WebRTC Security Architecture", draft-ietf- + rtcweb-security-arch-07 (work in progress), July 2013. + +Authors' Addresses Randell Jesup Mozilla US Email: randell-ietf@jesup.org Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420