4. Requirements (Exigences)
Cette section liste les exigences pour les canaux de données pair-à-pair (Peer-to-Peer, P2P) entre deux navigateurs. Notez que cette section est fournie à titre informatif uniquement.
Req. 1 : Plusieurs canaux de données coexistants DOIVENT (MUST) être pris en charge. Notez que dans la même PeerConnection, il peut y avoir zéro ou plusieurs flux de médias SRTP en parallèle avec les canaux de données, et le nombre et l'état (actif/inactif) de ces flux de médias SRTP peuvent changer à tout moment.
Req. 2 : Les canaux de données fiables et non fiables DOIVENT (MUST) être pris en charge simultanément.
Req. 3 : Les canaux de données d'une PeerConnection DOIVENT (MUST) être soumis au contrôle de congestion, soit individuellement, soit en tant que classe, soit conjointement avec les flux de médias SRTP de la PeerConnection. Cela garantit que les canaux de données ne causent pas de problèmes de congestion pour ces flux de médias SRTP, et qu'une PeerConnection WebRTC ne cause pas de problèmes excessifs lorsqu'elle fonctionne en parallèle avec des connexions TCP.
Req. 4 : Les applications DEVRAIENT (SHOULD) pouvoir fournir des indications sur la priorité relative de chaque canal de données par rapport aux autres et par rapport aux flux de médias SRTP. Cela interagira avec les algorithmes de contrôle de congestion.
Req. 5 : Les canaux de données DOIVENT (MUST) être sécurisés, ce qui permet la confidentialité, l'intégrité et l'authentification de la source. Voir [RFC8826] et [RFC8827] pour plus de détails.
Req. 6 : Les canaux de données DOIVENT (MUST) fournir une prise en charge de la fragmentation des messages (Message Fragmentation), afin d'éviter la fragmentation au niveau de la couche IP quelle que soit la taille du message que l'application JavaScript transmet pour l'envoi. Ils DOIVENT (MUST) également garantir que les transferts importants sur les canaux de données ne retardent pas excessivement le trafic sur d'autres canaux de données.
Req. 7 : Le protocole de transport des canaux de données NE DOIT PAS (MUST NOT) encoder les adresses IP locales dans ses champs de protocole, car cela divulguerait des informations potentiellement privées et entraînerait des échecs si l'on s'appuie sur cette adresse.
Req. 8 : Le protocole de transport des canaux de données DEVRAIT (SHOULD) prendre en charge des « messages » de longueur illimitée au niveau de la couche application (c'est-à-dire des flux de socket virtuels), pour des usages tels que le transfert de fichiers image ; les implémentations peuvent imposer des limites raisonnables sur la taille des messages.
Req. 9 : Le protocole de transport des canaux de données DEVRAIT (SHOULD) éviter la fragmentation IP. Il DOIT (MUST) prendre en charge la découverte du MTU de chemin (Path MTU, PMTU) et NE DOIT PAS (MUST NOT) dépendre de la génération ou du retour de messages ICMP ou ICMPv6, notamment pour la découverte du PMTU.
Req. 10 : Il DOIT (MUST) être possible d'implémenter la pile de protocoles dans l'espace utilisateur de l'application.