> Folks, I've been working (slowly) on updates to the Jingle specs so that we > can incorporate feedback, fix a few bugs, and track some of the more modern > RFCs and Internet-Drafts on these topics.
Thanks Peter for working on the Jingle specs! > Jingle (core definition): > http://xmpp.org/extensions/tmp/xep-0166-1.2.html Some additional items to consider: 1) Using content-add/content-accept before session-accept There is no guidance on how to use content-add and content-accept before the session itself has been accepted. For example: Romeo --- session-initiate ---> Juliet Romeo <--- content-add --- Juliet Should Romeo accept the content now, or does he need to wait for Juliet to send the session-accept first? The key issue here is content disposition. XEP-0269 (Jingle Early Media) explains how accepting contents before session-accept is doable, but only when the content disposition is "early-session". The question is thus: Is it allowed to accept a content with "session" disposition before the session itself has been accepted? If the answer is yes, we have the odd case where the responder could individually accept all offered contents (and start the application media flows), without ever accepting the session itself. And maybe that's OK, but it is something I ran across on accident while button mashing with a live system (it caused a crash as I had never considered this case when implementing). 2) content-reject vs content-remove These two actions are very similar in that they both result in expunging a content from the session. The main distinction between these actions is that content-reject is specifically used in response to a content-add. The question here is: If the responder does not want one of the contents in the session-initiate, which action should be used to get rid of it? The answer appears to be content-remove. Which means that a responder can "reject" content two different ways. This leads to a hidden state variable for contents: was the content included in the initial session-initiate, or did it come from a later content-add. Declining a content from the initial session-initiate is a content-remove action, and declining a content introduced via content-add is a content-reject action. Now, I know that the current text specifies this behaviour, but in a roundabout way; a more explicit note that the origin action of a content needs to be tracked would be good. I would suggest that we don't need content-reject, in the same way that we only have session-terminate for both rejecting and removing a session, but that would be a backwards incompatible change. However, should we just say that these are two names for the same action, and clients need to handle both equivalently? 3) Framed Transports Jingle currently classifies transports into two categories: Datagram and Streaming. These are of course meant to mirror the behaviors of UDP and TCP. However, I would like to propose a third category: Framed. A framed transport is packet based like a datagram transport, but also provides reliability. | Transmission Mode | Reliability =========================================== Datagram | Data packet | Unreliable Framed | Data packet | Reliable Streaming | Continuous Stream | Reliable There are several network transports that can fit the framed model: - WebSocket - BOSH! - WebRTC Data Channels (SCTP over DTLS) - "Raw" SCTP (eg. DTLS over SCTP) > Jingle RTP: > http://xmpp.org/extensions/tmp/xep-0167-1.1.html I don't think removing <active /> is worth a namespace version bump by itself. The <active /> info is easy enough to process as it is. > The primary TODO items now are adding some implementation notes to XEP-0166 > (which Lance Stout has volunteered to do) I am still working through writing up implementation notes. If you are interested in reading about implementation experiences, here is a link: https://gist.github.com/legastero/fa80e2366c448fd6e141 NB: This is still being written/edited, and is currently more of a blog post to flesh out thoughts before formalizing into updates for XEP-0166. /Lance
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
