Re: [Standards] Move Carbons to Last Call (Proposed)
On 12 Aug 2015, at 15:44, Ralph Meijer ral...@ik.nu wrote: * Could your envisioned changes be add-on instead? I.e. is there a chance of future proofing this (now)? Ralph’s mail led to me thinking what the minimum necessary change would be to allow future proofing, so thanks to Ralph for asking the right question. There are two basic issues I see: 1) type=normal needs to be carboned too in various circumstances (but not blindly, because of IBB and things). 2) There has to be scope for the rules being changed in the future (without negotiation) as new specs are written that may influence what should and shouldn’t be carboned. As 280 stands, one could implement a client by the letter of the spec that later had interop issues if what was carboned changed. For example, we need to have a path to mamsub-style carbons in the future. I believe the answer is this (and have run it past Ralph, Sam, Dave, Georg and others already). I think we say The server should carbonise chat and IM-related messages, definition of which is an implementation detail, but is expected to be something like type=chat and those type=normal with a body, maybe not from a MUC. It is possible for future specs to define rules that override these, and such new schemes will be defined, including a negotiation mechanism, in other specs such that a client doing vanilla 280 can expect this to be IM-only. Without further negotiation a client can't rely on precisely what will be carbonised. and we're largely covered. I think that leaves the door wide open for mamsub, and also for any tweaks needed to support the other things going on, like MUC2 or PubsubAccount, or just trying to silently fix MUC1 PMs. If there are other schemes like mamsub in the future, it is reasonable to enable them with a different mechanism, such as a different iq, or some atomic query-and-enable-carbons iq or whatever. Such schemes might much more formally define precisely which messages are carbonised (e.g. ‘every message that goes into the MAM archive that you have not otherwise received, including reflection of your own messages, which is what I’m dubbing mamsub’). Lance then checked existing server implementations, and it seems that most aren’t compliant anyway, ignoring that carbons should only be for chats, and doing it for normal. Which leads me to think that any existing client implementations must cope with this, and we can avoid a namespace bump for the above change. Unless anyone objects, I’ll submit a PR updating the XEP along these lines. On the basis that implementations won’t need to change as they’re closer to the new text than complying with the old text, I think we would be able to move to Draft in Not Very Long after the new version is published. /K
[Standards] Fwd: [Council] Minutes 2015-08-12
FYI Begin forwarded message: From: Kevin Smith Subject: [Council] Minutes 2015-08-12 Date: 13 August 2015 13:43:21 BST To: XMPP Council Logs: http://logs.xmpp.org/council/2015-08-12/ 1) Roll call Kev, Lance, Fippo present. Dave later. Matt absent. 2) XEP-0280 (Carbons) Issue Last Call All in favour (including Dave later), although Kev notes that he thinks more work is needed before Draft. 3) http://xmpp.org/extensions/inbox/otr-info.html Accept as Experimental? Lance +1. Dave +1 later in meeting. Kev, Fippo, Matt to vote onlist. 4) https://github.com/xsf/xeps/pull/41 Some confusion about Council needing to approve commits to Draft changes (they don’t - they only need to approve a new version being published, editors/authors can continue as normal). Agreement there’s no Council action here. Dave enters here. 5) XEP Authors unresponsive to updates from non-authors Discussion of a pending community submission for MAM changes that hasn’t been merged. Kev to look at the change. 6) Date of next meeting. 2015-08-19 15:00Z 7) Any other business Matt Miller (Editor) reminds people about the HTTP-Upload protoXEP, which has a week left on its vote. Dave mentioned that we were going to discuss his Myths draft, but that had been overtaken by events (the draft was widely shared before review). Fini
Re: [Standards] XEP-0313 MAM implementation for MUC
On 31 Jul 2015, at 16:49, Mickaël Rémond mrem...@process-one.net wrote: Hello, Hi Mickaël, While iterating on our MAM for MUC server-side implementation, we reached an issue on the following part of the XEP. • from in MUC archive: When sending out the archives to a requesting client, the 'to' of the forwarded stanza MUST be empty, and the 'from' MUST be the occupant JID of the sender of the archived message. The original issue is that you cannot display the remote history as you would do with local history because: - On local history, you will have nickname, we are missing it here. I commented on the PR you sent to GitHub here - I’m afraid you might have misread ‘occupant JID’ in XEP-0045. It’s the full JID including the nickname - so when retrieving data from a MUC MAM archive you do have the nickname as part of the occupant JID, and you also have the real JID (if you should be able to see it). /K
Re: [Standards] [Council] Minutes 2015-08-05
On Aug 13, 2015, at 7:11 AM, Kevin Smith kevin.sm...@isode.com wrote: 2) Accept as experimental? http://xmpp.org/extensions/inbox/http-upload.html All to vote on list I’m ever so marginally +1 on this. I am very uncomfortable with introducing another file transfer negotiation mechanism, and I believe this should be done with Jingle (for the negotiation), which has many advantages (the server could offer HTTP upload as well as other mechanisms, etc.), so this does meet one of my criteria for blocking a protoXEP. So, based on discussion in the other thread about the HTTP Upload proposal, I wrote up what a Jingle transport based on HTTP transfers could look like: http://legastero.github.io/customxeps/extensions/http-transport.html There were a few things I learned in the process: 1. While it would be possible to use this to negotiate uploading a file to a server, there is not yet any Jingle mechanism telling the server that it should in turn expose the shared content with others (COLIBRI kinda does this, but that's just for RTP streams and is still outside of the Jingle negotiation process). We would need to do something like expand JinglePub (XEP-0358) so that including a jinglepub / element in the session-initiate signals that we want the session content to be available for others to request. While I think this is desirable as a long term and more general solution, it gets further from the simplicity of the original proposal here. 2. The HTTP upload proposal is more accurately discussed in term of storage space and URI provisioning, not file transfer directly. For example, using the Jingle HTTP transport above, I could request a storage slot and signal the details of that slot to another client, requesting that other client to upload a particular file to my file server. That is powerful, and it requires a URI provisioning process outside of Jingle. We've had a similar situation for Jingle RTP with COLIBRI (XEP-0340). Any client-client transfer situation will end up with one of the clients needing to ask *something* to provision URIs. (puts on council voting hat) All of that said, I am +1 on a modified form of HTTP-Upload (Sam and Mickaël had some good improvements that should be reviewed and incorporated). - Lance smime.p7s Description: S/MIME cryptographic signature
[Standards] DRAFT: XEP-0294 (Jingle RTP Header Extensions Negotiation)
Version 1.0 of XEP-0294 (Jingle RTP Header Extensions Negotiation) has been released. Abstract: This specification defines an XMPP extension to negotiate the use of the use of RTP Header Extension as defined by RFC 5285 with Jingle RTP sessions Changelog: Advanced to Draft per a vote of the XMPP Council. (XEP Editor (mam)) Diff: http://xmpp.org/extensions/diff/api/xep/0294/diff/0.2/vs/1.0 URL: http://xmpp.org/extensions/xep-0294.html
[Standards] LAST CALL: XEP-0280 (Message Carbons)
This message constitutes notice of a Last Call for comments on XEP-0280 (Message Carbons). Abstract: In order to keep all IM clients for a user engaged in a conversation, outbound messages are carbon-copied to all interested resources. URL: http://xmpp.org/extensions/xep-0280.html This Last Call begins today and shall end at the close of business on 2015-08-28. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
[Standards] DRAFT: XEP-0293 (Jingle RTP Feedback Negotiation)
Version 1.0 of XEP-0293 (Jingle RTP Feedback Negotiation) has been released. Abstract: This specification defines an XMPP extension to negotiate the use of the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) with Jingle RTP sessions Changelog: Advanced to Draft per a vote of the XMPP Council. (XEP Editor (mam)) Diff: http://xmpp.org/extensions/diff/api/xep/0293/diff/0.3/vs/1.0 URL: http://xmpp.org/extensions/xep-0293.html
