Re: [Standards] NEW: XEP-0359 (Unique and Stable Stanza IDs)
> I have some questions regarding the business rules: > > - Why enforce a single id at a time ? I think it can be useful to have > multiple ids in a message: > > >[...] > > > > This is allowed. The restriction here is that you can only have one with a given JID in the 'by' attribute. So the above is ok, but this is NOT ok: [...] > - Why put the client-id in the stanza-id ? It has been suggested (but not yet incorporated into 359) that client-id be replaced by the simple lack of a 'by' attribute. (If no 'by' is present, the entity that stamped the ID is the stanza sender, pending the support checks that should be added in the security considerations that I mentioned on list earlier.) - Lance smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] NEW: XEP-0359 (Unique and Stable Stanza IDs)
Excerpts from Lance Stout's message of 2015-07-14 10:33:23 -0700: > > > Version 0.1 of XEP-0359 (Unique and Stable Stanza IDs) has been released. > > > \o/ > > > Some feedback on this new version: > > > 1. Disco feature is needed to discover that an entity generates ids, and that > it therefore is able to assure that ids attributed to it are valid by > stripping & overwriting ids that it routes. > > 2. Security considerations needs to include that a given id should only be > accepted for use if the by attribute is for the JID that is expected and that > the JID is able to assert the id. (Don't trust ids from room messages unless > the by attribute is the room JID AND the room lists the stanza-id feature in > its disco features) > > > > - Lance Hey everyone, I have some questions regarding the business rules: - Why enforce a single id at a time ? I think it can be useful to have multiple ids in a message: [...] Here the id given by the room is not the same as the one used to store it in my server's archive: I will more probably query my archive with the archive-provided id, but when I'm going directly to the room I will want to use the room-provided id - Why put the client-id in the stanza-id ? Intuitively I would have put it directly at the top-level: Hello there! # No more client-id here This makes it clearer that the message, as generated by me, has this id, and all the others are added along the road. (Note: this seems to "conflict" with XEP-0184 at least, however I think the features actually overlap more than they conflict) - Purely semantic: "client-id" implies it was generated by a client, but there are cases where it's not: for instance pubsub notifications are sent by the servers (although there already are item-level ids in this case), bots can technically be clients but they can also be server, ... The name should indicate that it is the id generated by the initiator. Maybe something like "sender-id" signature.asc Description: PGP signature
Re: [Standards] XEP-0234 Jingle File Transfer 0.16
The reasoning behind creating a FT:4 was to leverage the core semantics of Jingle versus continuing to reinvent them inside of FT to solve some of the remaining open items in the FT:3 spec. (The idea here being that a general Jingle session management implementation should have a well lit path for how to use its existing session management tools & data to support file transfer.) Thus, instead of a bundle of files inside a single Jingle Content, there is a separate Content per file. That solves the unresolved issues in FT:3 about how to add (and remove!) additional files to the transfer session while it is in progress. In FT:4, we use the standard Jingle content-* actions. A nice side effect is that it means that the files do not need to wait for each other to download over a single connection, the data can be sent in parallel via multiple connections. However, in the process of editing and creating FT:4, the and wrappers were removed, which appears to have removed the ability to request a file, but that case is still doable with FT:4. It now requires using core Jingle semantics instead of something inside FT itself. Namely, Jingle Contents may specify which side of the session is supposed to send data. This is an example of requesting files using FT:4 65ea0164c91de2197956ed143099b90ff37d699e test.txt da39a3ee5e6b4b0d3255bfef95601890afd80709 for-good-measure.txt (Likewise for transfer offers, the Content should include `senders="initiator"` to indicate as such.) I'm currently writing up patches to submit as a PR to add a section covering requesting files and the use of the content senders attribute, along with some additional examples and editorial fixes. - Lance smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] NEW: XEP-0359 (Unique and Stable Stanza IDs)
> Version 0.1 of XEP-0359 (Unique and Stable Stanza IDs) has been released. \o/ Some feedback on this new version: 1. Disco feature is needed to discover that an entity generates ids, and that it therefore is able to assure that ids attributed to it are valid by stripping & overwriting ids that it routes. 2. Security considerations needs to include that a given id should only be accepted for use if the by attribute is for the JID that is expected and that the JID is able to assert the id. (Don't trust ids from room messages unless the by attribute is the room JID AND the room lists the stanza-id feature in its disco features) - Lance smime.p7s Description: S/MIME cryptographic signature
[Standards] NEW: XEP-0360 (Nonzas (are not Stanzas))
Version 0.1 of XEP-0360 (Nonzas (are not Stanzas)) has been released. Abstract: This specification defines the term "Nonza", describing every top level stream element that is not a Stanza. Changelog: Initial published version approved by the XMPP Council. (XEP Editor (mam)) Diff: http://xmpp.org/extensions/diff/api/xep/0360/diff/0.1/vs/0.1 URL: http://xmpp.org/extensions/xep-0360.html
[Standards] NEW: XEP-0359 (Unique and Stable Stanza IDs)
Version 0.1 of XEP-0359 (Unique and Stable Stanza IDs) has been released. Abstract: This specification describes unique and stable IDs for stanzas. Changelog: Initial published version approved by the XMPP Council. (XEP Editor (mam)) Diff: http://xmpp.org/extensions/diff/api/xep/0359/diff/0.1/vs/0.1 URL: http://xmpp.org/extensions/xep-0359.html
Re: [Standards] Proposed XMPP Extension: Zero Handshake Server to Server Protocol
I think it's worth noting that low-bandwidth support is a key differentiator for Isode's implementation, and so it's especially pleasing to see this low-bandwidth binding of XML Streams be submitted for standardization in this way. While I appreciate it's relatively niche, I think it will benefit the community, and exemplifies the nature of the community's relationship with industry, and our common desire for open standards. Non-blocking comments follow: With this specification as written, what happens is, roughly, that a TCP session is opened and then XML fragments sent "as if" a stream open had been sent, something like: Hi! ... Two questions: 1) What defines what the default namespace is? (I think it's mandatorily defined as 'jabber:server') 2) When a stream is closed, should a close tag be exchanged? (I suspect yes, for all the reasons given in XEP-0190) 3) What defines what the stream prefix means? (I think it's fixed as ' http://etherx.jabber.org/stream') (1) and (3) can be specified as being due to an unsent tag, or by configuration. I'd prefer to fix the prefixes used, and minimize their use (ie, maybe require that stream errors should be explicitly namespaced). It's tempting, as a result, to define more, such as XEP-0198's namespace for use with and elements, but this is rapidly increasing the complexity of the approach. An alternate design (changing the wire protocol) would be to send, pipelined, the stream-open, which XML namespaces properly defined. I think this is the most flexible approach, but I appreciate that accurately defining what has been implemented is the right first step. Bandwidth constraints for the deployment of this protocol suggest we want to avoid explicitly namespacing elements if we can avoid it, so the approach used in the WebSocket binding, for example, is likely inappropriate. On 14 July 2015 at 15:35, Steve Kille wrote: > Let me give a bit more background on this proto-XEP. > > We (Isode) have been involved with a number of systems operating over very > high latency (several second) slow and flakey links. > Using standard XMPP over these links is barely useable - many minutes to > establish communications. > > The approach here of eliminating server to server handshakes has been > implemented and tested in a number of UK and NATO trials. > > It seems desirable to make this useful approach available as a XEP. NATO > are keen to see this happen, and I prefer to avoid > proprietary approaches. > > This proto-XEP writes up what we implemented. I'd welcome any input on > this. > > Regards > > > Steve > > > > -Original Message- > > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of XMPP > Extensions Editor > > Sent: 14 July 2015 14:31 > > To: standards@xmpp.org > > Subject: [Standards] Proposed XMPP Extension: Zero Handshake Server to > Server Protocol > > > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Zero Handshake Server to Server Protocol > > > > Abstract: > > This specification defines an approach for a pair of servers to > eliminate initial handshakes and associated > > data transfer when using the XMPP S2S Protocol. This approach may > only be used with a priori agreement and configuration > > of the two servers involved. This is of significant benefit in high > latency environments. > > > > > > URL: http://xmpp.org/extensions/inbox/optimized-s2s.html > > > > The XMPP Council will decide in the next two weeks whether to accept > this proposal as an official XEP. > > >
Re: [Standards] Proposed XMPP Extension: Zero Handshake Server to Server Protocol
Let me give a bit more background on this proto-XEP. We (Isode) have been involved with a number of systems operating over very high latency (several second) slow and flakey links. Using standard XMPP over these links is barely useable - many minutes to establish communications. The approach here of eliminating server to server handshakes has been implemented and tested in a number of UK and NATO trials. It seems desirable to make this useful approach available as a XEP. NATO are keen to see this happen, and I prefer to avoid proprietary approaches. This proto-XEP writes up what we implemented. I'd welcome any input on this. Regards Steve > -Original Message- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of XMPP > Extensions Editor > Sent: 14 July 2015 14:31 > To: standards@xmpp.org > Subject: [Standards] Proposed XMPP Extension: Zero Handshake Server to Server > Protocol > > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Zero Handshake Server to Server Protocol > > Abstract: > This specification defines an approach for a pair of servers to eliminate > initial handshakes and associated > data transfer when using the XMPP S2S Protocol. This approach may only be > used with a priori agreement and configuration > of the two servers involved. This is of significant benefit in high > latency environments. > > > URL: http://xmpp.org/extensions/inbox/optimized-s2s.html > > The XMPP Council will decide in the next two weeks whether to accept this > proposal as an official XEP.
[Standards] NEW: XEP-0358 (Publishing Available Jingle Sessions)
Version 0.1 of XEP-0358 (Publishing Available Jingle Sessions) has been released. Abstract: This specification defines an XMPP protocol extension that enables an XMPP entity to advertise the fact that it is willing accept a particular Jingle session request. The protocol is used mainly to inform other entities that a particular file is available for transfer via the Jingle File Transfer protocol defined in XEP-0234. Changelog: Initial published version approved by the XMPP Council. (XEP Editor (psa)) Diff: http://xmpp.org/extensions/diff/api/xep/0358/diff/0.1/vs/0.1 URL: http://xmpp.org/extensions/xep-0358.html
[Standards] Proposed XMPP Extension: Zero Handshake Server to Server Protocol
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Zero Handshake Server to Server Protocol Abstract: This specification defines an approach for a pair of servers to eliminate initial handshakes and associated data transfer when using the XMPP S2S Protocol. This approach may only be used with a priori agreement and configuration of the two servers involved. This is of significant benefit in high latency environments. URL: http://xmpp.org/extensions/inbox/optimized-s2s.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Re: [Standards] XEP-0234 Jingle File Transfer 0.16
While we're on the subject, is there any benefit to having a reestablish mechanism in a more general sense? I'm thinking about the number of times I tell colleagues that I'll call them right back - would we save much effort in negotiation if we chose to repeat a previous session rather than create a new one? In this specific case, I don't see that jingle pub provides the same semantic, without considerable effort and fiddling. On 20 Jun 2015 13:09, "Yann Leboulanger" wrote: > Hi all, > > I just read the version 0.16 of Jingle File Transfer XEP, and saw that > you removed the flow. > Just to mention that it is used in Gajim to re-request the file at the > end of a tranfer when hash was wrong. > I don't think it's a good thing to removed a feature without a > replacement, that's not very nice for clients to remove a feature they > implemented. > Please note also that this thing was used by XEP-0329 that is > now no more implementable! > > Is there a way to have it back in the XEP or have a replacement XEP for > that feature? > > -- > Yann > >
