Summit 15 Minutes

Day 1

IQ Bugs

It was discovered that quite a few clients (and servers) were not checking the FROM JID to match up the response

issues

• clients that are sending the session establishment to the wrong JID
• servers are happily accepting this and answering
• servers are responding to a bare JID with a full JID

takeaway

• Kev will mail the IETF list about this being a core security issue
• internet draft to working group -- ter will replace 6120 and others
• we need to come up with server and client test flows to allow testing and we need to be clear that you will encounter a server that responds in a way that breaks your code

xmpp for the web

currently we have two projects - xmpp-ftw, stanza.io

Lloyd is giving an overview about xmpp-ftw

• used by Surevine and also by chinese and other asian devs

Lance is giving a demo of stanza.io and otalk.im

• had to update 156 for alternate discovery method
• Joe mentioned that the ietf is agitating on discovery methods and we will need to track that

webrtc

webrtc mandates encryption (DTLS) for both RTP (audio/video) and SCTP (datachannels). question - can we decide to not require encryption

• the IETF is pushing to make encryption required for all things (because snowden)
• do we need to have a conversation about having the same level of encryption as IETF (because snowden)

is it more important to have as much security as possible even to the detriment of interoperability or do we ensure interoperability

• show of hands called by kev: snowden-level of security (vast majority)

have people noticed the new XEP for srtp for doing file transfer over jingle (dwd question) -- no

discussion talked about file transfer and if we have enough client interop that works in both enterprise and consumer layers of firewalls

• deferred to tomorrow to talk about the interop issue

takeaway

• Simon will write up a quick how the buddycloud-media server works and share it.
• Files will be hosted and retrieved via https
• We might upload with https or with the sctp-dtls stuff that we will be using for 1:1 file transfer

editorial team

Dave is talking about the editorial team and Ralph is talking about how we have too many jobs being done by one or two folk and that we need more people to help with this

• we discussed it and had 5 people volunteer for the job. they were asked to post to the list so Peter can be aware.

upnp liason

Peter needs to describe the exact info for this. Dave is giving a description of what a liason is and how different technical groups work with each other

mam search

rfc313 which is a not broken version of archiving

discussion about whether or why archiving all IQ's for an entity make sense or is even needed - no real consensus as it may be too implementation enironment specific

discussion about using xep55 for search

• it returns an xdata form but that would require form field standardized
  • oh, it would use xep55 for the search request

question is how this interacts with RSM and do it exactly like RSM is done now and how you would distinguish the result

• is it sufficient to submit the form once and get all the results with RSM

discussion about having a sentinal stanza to mark the end of the result stream and how that could impact server to server karma throttling

• it was requested that wording be added to 313 such that sending of the results be paced to not cause flooding

discussion about doing message searching via pubsub and that it would become a subscription requirement

• Joe is asking for the same element between mam and pubsub to mark that the result stream is completed
• Ralph will document the changes required for pubsub
• MattW will document the changes required for MAM

conversation if changing 313 to have the filter language be expanded to include what is required for search

• push back from others that it could run down the path that we have two places to do search
• council needs to talk about how to work 55 and 313 and if search needs to be a seperate xep
• replace all of the search text in 313 and replace it with predefined fields from 68

consensus is clearing up that 55 is no longer required

• 313 currently has some non form field and MattW is going to get rid of those and repace those with defined fields and that it is suggested that we add an additional field that can only be queried - if you request the form and that it has this field you know that it can do a search

conferencing

two aspects of conferencing

• huge number of software that does many-to-many - webex, skype, gotomeeting - xmpp has all of the bits to cover these use cases
• remote participation aspect that allows for reliable remote conference participation

question was raised if this was an appropriate use of the XSF time - why not let the companies who are already working in this space do it

• response was that we need to "eat our own dogfood" and "it needs to be open source"

what concrete steps can we take as a group to help guide this project - the question is if there is a project that the XSF needs to be involved in

• this could be solved by making sure that how xmpp protocols can be used to make the tools to do the project
• making sure the process is documented and having reference implementations
• getting the story out of how to do this - via a whitepaper that describes how to do this. Some will be writing whitepapers on how this is done

POSH

Joe is describing what POSH is and about how we have made a consensus call that we need more folks to respond within the mailing list. If we don't do posh in the working group, it will go away

Joe will put the mailing list url into the summit muc room

whiteboarding

currently their is a spec for it but we are not aware of any deployments, two years ago a gsoc student did whiteboarding in swift using a different protocol. We need to discuss about implementation of the spec and if any work needs to be done with it

XMPP-IoT

Joachim Lindborg made a walk through of the current extensions xep-323, xep-324, xep-325, xep-326

• There was a long discussion on the complexity of the xeps and a need for an easy to grasp introduction
• The new xmpp.org site will contain a IoT area so that's a good place for such information Joachim to work with Laura on that.
• There was a consensus that the effort of using XMPP in IoT is good and fully supported by the community
• A demo with philips hue lamps using XMPP, was also prepared during the summit an later shown at the FOSDEM XMPP realtime lounge

Day 2

mobile on xmpp

Simon lists the problems of mobile

• battery life - because of the constant network uses keep alive, presence, chattyness
• switching networks
• OS issues, background limitations
• quick connections/reconnect
• message queuing even if online on a different resource
• registering the push delivery endpoint
• don't send push notifications even if already connected

Push

Lance gives a presentation on push.otalk.im: https://cloudup.com/c223kt48cGZ

issues:

• what to send from the xmpp server to backend services
  • could be a xep 50 commands - could have well defined form fields
• be able to track what notifications a device wants - token/guid/??

basic format from xmpp server to push server

• message push wrapper with context xdata form for the push data - sending server controls data
• number of unread messages on this device (estimate only if 198 is not implemented)
• push service will not maintain unread count state and the xmpp server will need to maintain unread count per push service
• xep 50 command to register there will be a jid - the device client will generate a guid to make it unique

client needs to tell the xmpp server that it is going offline -- handled by sending xep 50 unregister command for that device or by hitting 198 zombie mode

client needs to tell the xmpp server that it is going online and that the presence needs to be explicit

need a way for the push service to tell the xmpp server when a registered jid/token is no longer allowing push notifications

• the push service will send a message type back to the xmpp server when the jid/token is not allowed

use case where everything is offline

• there is no 198, nothing - all of the registered clients that have registered to receive push notifications

the xmpp server will send to all registered push services whenever it will send a push

• the jid it sends to is the same (full) jid that the component passed during registration for the device

registration of the client to the xmpp server

• it will need the jid that it received from the push service - the target JID
• it will need a cient id that it used to identify to the push service
• xep 50 - it may need more information to help craft how the notifications are performed

on client start it must always send the registration message

• client implementation detail when the form presented to the user
• the initial registration and the restart registration commands can be different

commands

• start (initial registration),
• pause (stop sending me push notifications i'm online)
• restart (it can fail to force a new start)
• reset (I am up to date and all device pending pushes should be cleared)
• stop

note -- that we may have created a spam method because we do no verification of the push target JID

Joe called for a brainstorm of the messages that could go between the xmpp server to the push service

• subscription/follow requests
• jingle/call identification
• xep pre-subscribe - notification of join event
• muc message
• chat message
• pubsub message
• role change - muc/pubsub
• freetext payload
• structured payload
• presence change
• roster change
• xmpp server status change - server up/down
• file transfer request
• pubsub/other authorization request

xep 322

Akari and Yusuke gave a presentation on their work with 322 and how they are using EXI in their research.

https://www.dropbox.com/s/o2rffakg6s37de3/XMPP_Summit_2014.pdf

They also talked about the implementation of their EXI proxy so that low power devices could communicate with an XMPP network directly via the EXI proxy layer.

throttling

you need to be able to say what is suppressed, what is to trigger a flush takeaway

• Dave will update the sift xep to create a new not-sift xep

compliance suite

lots of discussion about how or if this would be useful and about how the XSF may not want to get into the business of doing compliance testing. The consensus was that if a list of profiles could be generated and that it could either be automated or self-tested, then maybe the XSF would look into it.

takeaway

• Bear will come up with a list of profiles to have suite/tests to allow someone to label their client or server as supporting

websockets

Lance reports that the various players have finally reached consensus on framing and protocol issues

ietf working group summary

• London will have a WG meeting
• inband encryption work is in progress - Matt Miller is working on it
• websockets - new draft of the above consensus is needed before deadline in 2 weeks
• posh - POSH will be discussed as part of the XMPP WG
• ter draft work is being done by peter behind the scenes so they can be moved forward
• precis 6122 (split from 6120) because 6122 will be updated sooner than 6120 - it is the replacement for stringprep