FYI. -------- Original Message -------- Subject: [Council] meeting minutes, 2009-03-04 Date: Wed, 04 Mar 2009 15:56:20 -0700 From: Peter Saint-Andre <[email protected]> Reply-To: XMPP Council <[email protected]> To: XMPP Council <[email protected]>
Results of the XMPP Council meeting held 2009-03-04... Agenda: http://xmpp.org/council/agendas/2009-03-04.html Log: http://logs.jabber.org/[email protected]/2009-03-04.html Scribe: Peter Saint-Andre 0. Roll call Present: Dave Cridland, Jack Moffitt, Peter Saint-Andre, Kevin Smith. Absent: Ralph Meijer. Quorum achieved. 1. Agenda bashing None. 2. XEP-0047: In-Band Bytestreams (IBB) Approve version 1.2? Dave, Peter, and Kevin voted +1 in the meeting. Ralph and Jack to vote on the list. 3. Voice and video codecs The Council had a long discussion (with input from various attendees) and reached several rough conclusions: a. It makes sense to move the codec text out of XEP-0167. b. We are really trying to describe two things, which the early proposal labelled "jingle-rtp-mti" conflates: (1) recommended codecs for the sake of interoperability and (2) guidelines to Jingle implementors regarding the state of codec implementation and deployment on the Internet today. c. The voice landscape seems fairly clear, since Speex is fairly mature and widely available, and G.711 is patent-clear at this point. d. The video landscape is more murky, since Theora is not yet as mature or widely deployed as Speex is in the voice world, and H.264 is not patent-clear. e. Therefore one *possible* approach *at this time* is to make Speex and G.711 MUST, Theora SHOULD, and H.264 MAY. However, there is no settled consensus on this yet, and the consensus would change over time (in particular as Theora is more widely deployed). Peter will update / rewrite / rename the proposal currently called "jingle-rtp-mti" to reflect this very rough consensus, but the resulting proposal is best seen as a point of departure for further discussion. 4. Jingle security / e2e encryption The Council (with input mainly from Dirk Meyer) explored where the Jingle security definitions belong -- either in XEP-0166 or in an Internet-Draft. The main driver for this Jingle security work is end-to-end encryption of XMPP "conversations" (not necessarily between humans), but the work will result also in the ability to establish security for any Jingle application type and transport method, such as encrypted file transfer over a streaming transport or DTLS-SRTP over UDP. Peter posed the question of how we would proceed if we were not considering the formation of an XMPP WG. Dirk argued as follows: a. we would probably still define a separate Jingle Security spec (not put this into XEP-0166) to retain the same kind of modular approach that we already have in Jingle, where application types and transport methods are defined in separate specs, not in XEP-0166 b. we would update XEP-0166 by defining a "security-info" action and noting the potential inclusion of a <security/> element (on the same level as the <description/> and <transport/> elements for application types and transport methods) Very rough consensus that this seems reasonable, but that we will define "Jingle Security" in an Internet-Draft so that it can receive proper security review within the IETF if an XMPP WG is formed. Peter and Dirk to pursue this line of thinking further and perhaps update XEP-0166 and draft-meyer-xmpp-e2e-encryption accordingly. 5. Other business Brief mention was made of efforts by Marcus Lundblad and Olivier Goffart to update http://xmpp.org/extensions/inbox/file-preview.html using the Bits of Binary protocol (XEP-0221); they might have something ready for the Council to consider at the next meeting. 6. Next meeting Wednesday, March 11 @ 20:00 UTC in xmpp:[email protected] (visit http://xmpp.org/xsf/XSF.ics to load it into your calendar). Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
