]>

China jiang.7369@163.com

General WebRTC URI Scheme This document registers the "wr://" and "wrs://" URI schemes to aid in the connect of WebRTC. Note to Readers RFC EDITOR: please remove this section before publication The issues list for this draft can be found at https://github.com/jiang7369/I-D/issues/. The most recent (unpublished) draft and demos is at https://jiang7369.github.io/I-D/. Recent changes are listed at https://github.com/jiang7369/I-D/commits/gh-pages/. See also the draft's current status in the IETF datatracker, at https://datatracker.ietf.org/doc/draft-jiang7369-webrtc-uri-scheme/.

Introduction URI is short and compact, convenient for transmission. You can even send it offline to others without using any server, for example, you can generate a QR Code for use. WebRTC is a widely used real-time connection protocol, but unlike WebSocket, it has no URI scheme. This document registers the "wr://" and "wrs://" URI schemes to supplement such gaps. When use the URI quickly open the connection, you can immediately to realize communication between two clients. Use this URI Scheme to easily open a connection. You can open a data channel, then the connection can be used as a file transfer or signalling server, etc. You can also directly open a stable and complex connection by passing more parameters. WebRTC URI Scheme defines one endpoint of the connection, rather than one port of the device. It defines the connection mode of WebRTC in the Internet/LAN that conforms to human intuition. One device can open multiple connections, corresponding to multiple endpoints, without paying special attention to which port is currently used for connection. WebRTC URI Scheme may look like a compressed version of the SDP file. It avoids the trouble of inconvenient transmission of SDP newline characters, and does not expose more information in the first connection. In addition, the WebRTC URI Scheme facilitates communication between two computers through browser application under the premise of light server or no server. Changing connections on the network connect pairs of endpoints. WebRTC endpoints are characterized by great variability and fast variability. We can dynamically connect these points to form a dynamic network.

Notational 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 when, and only when, they appear in all capitals, as shown here. This document uses ABNF , Base64 . It also uses the pchar rule from .

WebRTC URIs This specification defines two URI schemes, using the ABNF syntax defined in RFC 5234 , and terminology and ABNF productions defined by the URI specification RFC 3986 . port = endpoint = basehash pwd ufrag query = basehash = 44 pwd = *255 ufrag = *255 ]]> See for a definition of pchar. Disallowed characters -- including non-ASCII characters -- MUST be encoded into UTF-8 and then percent-encoded (). The hostport component is OPTIONAL; By default, WebRTC connection without STUN or TURN. The port component is OPTIONAL; By default, "wr" runs on the same ports as STUN and TURN: 3478 for "wr" over UDP and TCP, and 5349 for "wrs" over TLS. The ufrag component, pwd component and fingerprint used in basehash component below can be find in attributes (, Section 5.12) of SDP (, Section 5.12). The basehash component MUST be calculated by the following steps:

1. get the length of pwd component
2. convert length of pwd component to hexadecimal (1 Byte)
3. get the fingerprint hexadecimal (32 Byte)
4. connect the length hexadecimal after the fingerprint hexadecimal
5. Calculate the Base64(, Section 2.1) of the result
   (33 Byte)

The advantage of this is to take endpoint component as a whole while taking readability into consideration. Fragment identifiers are meaningless in the context of WebRTC URIs and MUST NOT be used on these URIs. As with any URI scheme, the character "#", when not indicating the start of a fragment, MUST be escaped as %23. Example URIs are listed in Appendix A.

IANA Considerations

Registration of New URI Schemes

Registration of "wr" Scheme A |wr| URI identifies a WebRTC offer and answer name.

Scheme name:

wr

Status:

Permanent

Applications/protocols that use this scheme:

none yet

Security considerations:

See "Security Considerations" section.

Contact:

IETF <iesg@ietf.org>

Change controller:

IETF <iesg@ietf.org>

References:

(this document)

Registration of "wrs" Scheme A |wrs| URI identifies a WebRTC offer and answer name and indicates that traffic over that connection is to be protected via TLS (including standard benefits of TLS such as data confidentiality and integrity and endpoint authentication).

Scheme name:

wrs

Status:

Permanent

Applications/protocols that use this scheme:

none yet

Security considerations:

See "Security Considerations" section.

Contact:

IETF <iesg@ietf.org>

Change controller:

IETF <iesg@ietf.org>

References:

(this document)

Security Considerations The token ABNF rule allows tokens as small as 0 character. This is not recommended practice; applications should evaluate their requirements for entropy and issue tokens correspondingly. See for more information. This document not solve the problem that attackers can flood stun/turn servers. Too many open ports may cause network layer rejection. Although the WebRTC URI Scheme makes connections easy to open, you may connect untrusted nodes in static pages, just like click the link of a phishing website. Before connecting, you must confirm whether the URI provider is trusted. If the stun/turn server is not trusted, man-in-the-middle attack may occur on the "ws://" connection. "wrs://" is intended to reduce the incidence of man-in-the-middle attack; it cannot prevent man-in-the-middle attack on client to client connections. And The server side of "wrs://" protocol SHALL ensure the security of each link and the handling of blacklist.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session Description Protocol (SDP) attributes when SDP is used to negotiate the usage of a single 5-tuple for sending and receiving media associated with multiple media descriptions. This specification also categorizes the existing SDP attributes based on the framework described herein. Data channel setup can be done using either the in-band Data Channel Establishment Protocol (DCEP) or some out-of-band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel. Informative References This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. This document registers the "secret-token" URI scheme to aid in the identification of authentication tokens.

Example URIs The content of sdp is as follows: The ufrag component is "Yb1d".
The pwd component is "uCiLWVRLVIKkrl14SzyO4TMF"
The basehash component before Base64 is
0xB69EF3DD8B838DF6954E7640AFF2780BCA78DA0B73211E28934F70DA47B4417E18,
The basehash component is
"tp7z3YuDjfaVTnZAr/J4C8p42gtzIR4ok09w2ke0QX4Y" So, the endpoint component is
"tp7z3YuDjfaVTnZAr/J4C8p42gtzIR4ok09w2ke0QX4YuCiLWVRLVIKk
rl14SzyO4TMFYb1d" Without STUN or TURN: o  If no STUN or TURN, expressed in "wr:///". For example: o  Or omit "//", expressed in "wr:/". For example: With STUN or TURN: o  Use STUN or TURN server, For example: o  Use STUNs or TURNs server, For example:

Acknowledgements Frankly speaking, the document format refers to when writing.
Thank you~