50 likes | 168 Vues
This document outlines key assumptions and considerations for implementing end-to-end (e2e) encryption within XMPP, particularly focusing on JID string comparisons and the specifics of user, host, and resource preparations. It discusses the structure of encrypted messages and raises open issues such as ID tracking, timestamp requirements, and XML parser considerations. Furthermore, it introduces TINS (Transport for Initiating and Negotiating Sessions) and poses significant questions regarding media stream initiations and potential integrations with SDPng.
E N D
IETF 56 – XMPP WG *prep e2e TINS
*prep • Assumption: JIDs are the only place where we do string compares • JID: user@host/resource • User: nodeprep (case insensitve, no @, etc.) • Host: IDNA (case insensitive, DNS restrictions) • Resource: resourceprep (case sensitive)
e2e – Example: <message> <x xmlns='http://.../e2e'>gpg --encrypt( <payload xmlns='http://.../e2e#payload'> <id>1234</id> <body>msg</body> </payload> ) </x></message>
e2e - Open issues • What is the ID? Is this something that a UA should keep track of? • Should there be a date/time stamp instead? • Is it OK to require spinning up a new XML parser for these messages?
TINS: draft-hildebrand-xmpp-sdpng NOTE: NOT A WG ITEM • SDPng is an MMUSIC I-D for XML flavor of SDP • TINS = Transport for Initiating and Negotiating Sessions • SIP-style exchange of SDPng documents for initiating OOB sessions • Problem statement: • Assume: XMPP infrastructure • Question: How to initiate media streams? • Can this just move to SDPng Appendix A, along with bindings for SAP, SIP, RTSP, MEGACOP?