Re: [Standards] Proposed XMPP Extension: Chat Markers
Should I migrate the Chat Marker XEP to a Message based solution and assume the issues regarding the storage of the messages with no body will be resolved in some way? Regards Spencer On Fri, May 31, 2013 at 4:05 PM, David Laban alsu...@gmail.com wrote: On Thu, 2013-05-30 at 18:16 +0100, Matthew Wild wrote: A more general issue is whether this XEP (or rather the specific protocol it defines) s necessary at all. I'm not saying it definitely isn't, but need a little more persuasion. For example it seems that the primary issue it is working around is that XEP-0136 and XEP-0313 might not save messages with no body. Might it not be easier to solve this problem instead? Sorry I'm late to the party. I have actually been discussing this with Spencer in the office over the last couple of weeks, so maybe I can give some more motivation for why we feel that an XEP is required. I'm not too attached There are actually a bunch of things that Chat Markers is trying to solve: 1) Atomic Read Receipt messages (Or Seen Receipts or whatever[1]). 1.1.1) Currently, our pre-alpha implementation of Seen by $user markers requires each client to keep track of the state machine (xep-0085) for *each* remote resource. Any incoming active/ notification, or any incoming received notification from a resource that is in the 'active' state currently updates the Seen by $user marker. 1.2.1) xep-0022 basically solves this problem, but it is marked as obsolete. I didn't feel like digging it out of the grave, but maybe we should re-consider it? 1.3.1) I suggested that we could simply include our state (if active) as a sister element to received/, but Spencer pointed out that xep-0184 section 7 states: When the recipient sends an ack message, it SHOULD ensure that the message stanza contains only one child element. What would break if we did this? 2) State recovery for disconnected clients that come online. 2.1.1) Currently, this is impossible, so our Seen by $user marker stays where it is, and messages appear as Not delivered when they are retrieved from MAM until a reply is received from the remote party (at which point, we assume that their client has done state recovery from MAM, and mark all messages as received. 2.1.2) xep-0184 section 5.5 Archived Messages states An entity MUST NOT send an ack message when a user views messages that have been archived or stored on the client or the server (e.g., via Message Archiving [8]), only when first receiving the message. This is annoying, but quite understandable (e.g. what should a client do if it gets received id=1234/ when it doesn't have any knowledge of message id=1234/ or when it might have been sent?) 2.3.1) We could allow MAM to store *all messages*, but then then a query for how many unread messages to I have since $time returns a hugely inflated answer. The only way to get an accurate count would then be to retrieve *all messages* and classify them. 2.3.2) We could create a clone of the MAM XEP (let's call it Message State Recovery: MSR) that stores everything without a body, and let the clients query that in order to do state recovery. A little benchmarking of our client's message/ datastore and a simple thought experiment suggests that this will be many times as large as the MAM database in a naive implementation (when Kate sends a message to Pete, her client will send active/; composing/; (paused/; composing/)* body/... and each of Pete's clients will send received/ and 0 or more will send active/. Note that we would need to bend the rules for xep-0184 (see 2.1.2) for this to be useful. Specifically (after retrieving all messages from MSR and MAM) for each incoming message in MAM that doesn't have a corresponding outgoing entry in MSR, send a receipt anyway. 2.3.3) We could get the server to store markers for delivered and seen etc. This is what Chat States attempts to do. 3) Efficiency 3.1.1) 2.3.2 and 1.1.1 cover a couple of the obvious problems with what we have now. 3.3.1) If we create a MSR XEP, what is the minimum amount of information that we can store? If we have solved problem 1) then we can make a lot of optimizations. For example, if we used my 1.3.1 proposal, then could simply store the last message of each type? Concretely, could we have a database with the following uniqueness constraint: (sender_barejid, receiver_barejid, sibling_ns, sibling_name) where sibling_ns is the namespace of the element after received/ in the message/ stanza, and sibling_name is its name (e.g. 'active' or NULL)? And in reply to Matthew Wild's specific comments: For XEP-0136, it appears to be configurable already in the archiving preferences (surprise surprise!). For XEP-0313, I'm open to discussion about what it recommends. We have gone for a Message Archive Management + Message Carbons approach so far, which means that clients only need to know how to unpack forwarded/. I
Re: [Standards] LAST CALL: XEP-0297 (Stanza Forwarding)
On 23 August 2012 00:04, XMPP Extensions Editor edi...@xmpp.org wrote: This message constitutes notice of a Last Call for comments on XEP-0297 (Stanza Forwarding). I have incorporated the feedback received so far, and a revised version can be found here: http://matthewwild.co.uk/uploads/xep-0297.html http://matthewwild.co.uk/uploads/xep-0297.xml http://matthewwild.co.uk/uploads/xep-0297.diff.html http://matthewwild.co.uk/uploads/xep-0297.wdiff.html Regards, Matthew
Re: [Standards] LAST CALL: XEP-0288 (Bidirectional Server-to-Server Connections)
Thanks for the feedback. On Tue, Jun 4, 2013 at 10:41 PM, Peter Saint-Andre stpe...@stpeter.imwrote: On 2/20/13 5:43 PM, XMPP Extensions Editor wrote: 5. Is the specification accurate and clearly written? I have several questions: Section 2.1: If a server supports bidirectional server-to-server streams, it should inform the connecting entity when returning stream features during the stream negotiation process (both before and after TLS negotiation). Is there any reason why the should is not a MUST? It's a should not a SHOULD, too. While I don't think it'd be useful, I don't think it raises an interoperability concern. For instance, a server could suggest bidi after some traffic has flowed, and if the peer starts sending traffic back, great - if not, nothing's lost. As such, RFC 2119 language would seem inappropriate. Section 2.2: This isn't really negotiation, is it? More like simply enabling the feature (no parameters negotiated etc.). If I'm to be pedantic, I might suggest this is really a feature offer, and neither enabling nor negotiating. Happy to pick a term and stick to it throughout, but I'd note this is splitting hairs. Section 2.2: To enable bidirectional communication, the connecting server sends a bidi/ element qualified by the 'urn:xmpp:bidi' namespace. This SHOULD be done before either SASL negotiation or Server Dialback. Why is this not a MUST? I don't see what good it would do to negotiate / enable bidi after SASL negotiation or server dialback. As above - this shouldn't be SHOULD, but is typically or some such. Section 2.2: Also note that the receiving server MUST only send stanzas for which it has been authenticated - in the case of TLS/SASL based authentication, this is the value of the stream's 'to' attribute, whereas in the case of Server Dialback this is the inverse of any domain pair that has been used in a dialback request. This is already covered by RFC 6120 and XEP-0220. Does it need to be reiterated here? Yes, I thought so at the time. The distinction between what RFC 6120 and XEP-0220 says is in the direction. Section 3 has C: and S: but these are both servers. It might help to change them to S1 and S2 or I and R. Yes, R and I seem sensible. Add the TLS negotiation after proceed/ for Example 3 and Example 4? OK I think Example 5 is OK but I think it's mislabled (it's really about piggybacking / multiplexing, not stream setup before TLS as far as I can see). I'll take a look.
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
On 16 April 2013 21:16, XMPP Extensions Editor edi...@xmpp.org wrote: This message constitutes notice of a Last Call for comments on XEP-0220 (Server Dialback). Abstract: This specification defines the Server Dialback protocol, which is used between XMPP servers to provide identity verification. Server Dialback uses the Domain Name System (DNS) as the basis for verifying identity; the basic approach is that when a receiving server accepts a server-to-server connection from an initiating server, it does not process traffic over the connection until it has verified the initiating server's key with an authoritative server for the domain asserted by the initiating server. Additionally, the protocol is used to negotitate whether the receiving server is accepting stanzas for the target domain. Although Server Dialback does not provide strong authentication and it is subject to DNS poisoning attacks, it has effectively prevented address spoofing on the XMPP network since its development in the year 2000. URL: http://xmpp.org/extensions/xep-0220.html This Last Call begins today and shall end at the close of business on 2013-05-10. 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? Definitely needed. 2. Does the specification solve the problem stated in the introduction and requirements? Yes, it does. 3. Do you plan to implement this specification in your code? If not, why not? We have, except for the newer errors portion of the protocol and multiplexing sender domains. Support for errors is planned. 4. Do you have any security concerns related to this specification? Nothing not already documented. 5. Is the specification accurate and clearly written? The nature of the protocol is confusing, and it isn't helped by carrying legacy baggage and not fitting very nicely into the rest of XMPP. Nevertheless, I think the specification does a decent job at trying to present everything logically, and I didn't have that much trouble implementing it. Editorially there seem to be some issues with internal references. For example links and text about section 2.4, which is about advertising support and not errors in particular. Overall I think this is a good useful document of a protocol that isn't going away any time soon. Someone asked only yesterday if Prosody could be configured to do TLS authentication *and* dialback (i.e. requiring both to pass). Regards, Matthew
Re: [Standards] LAST CALL: XEP-0301 (In-Band Real Time Text)
Peter, On 2013-06-05 04:34, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/28/13 2:30 PM, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0301 (In-Band Real Time Text). Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Real-time text is text transmitted instantly while it is being typed or created. URL: http://xmpp.org/extensions/xep-0301.html This Last Call begins today and shall end at the close of business on 2013-06-28. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: I have one additional question: do both of the authors (re-)affirm that they are contributing this specification in conformance with the XSF's IPR Policy? http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/ Yes, confirmed. In addition, are the authors personally aware of any patents over their contribution, whether those patents might be held or applied for by the authors or any other persons or organizations they know of? No. Regards Gunnar Gunnar Hellström Omnitor gunnar.hellst...@omnitor.se
Re: [Standards] LAST CALL: XEP-0297 (Stanza Forwarding)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/5/13 4:00 AM, Matthew Wild wrote: On 23 August 2012 00:04, XMPP Extensions Editor edi...@xmpp.org wrote: This message constitutes notice of a Last Call for comments on XEP-0297 (Stanza Forwarding). I have incorporated the feedback received so far, and a revised version can be found here: http://matthewwild.co.uk/uploads/xep-0297.html http://matthewwild.co.uk/uploads/xep-0297.xml http://matthewwild.co.uk/uploads/xep-0297.diff.html http://matthewwild.co.uk/uploads/xep-0297.wdiff.html Would you like that version published as 0.5? Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRr1g6AAoJEOoGpJErxa2pmQIP/2IDNVsbgOC/QuYPKOepYGyM PsTozi+vWeklnLj0xyYv2ucuXUlRmdVDFROTRp0K+VIdepKU3Mw1hKSPgXAhwRrd 1zB29/hzf8f7cqWCUCDSk1zKklOnaeSVTCmhOJMdrtTLNf7T4SycfKQWjUVwePWj ln15JdPmT2wi5yPBSuJsOFT7JwUsBVDtJPAPTRbOxOXD0gUv1lBiGJVtDk96kJdY Q839HwEWupp5Qw47/2JPoCUbvcOTw6YzgHWW1K9OHb44fOFcO4Wucy7dZtb+mPSG zoNInBxkWxFv4l0jqZWA0j/4/XRWHvecZ1BhIcYNAFJE0BYS4QbVD6c72UeyVBh7 Y1o/nUV3jwk+W3dLFvjmT6OwcAqgzhxbdjS+qTQWSLLuYG1OjF/RCc/19X+77nXh IR2lU0ZQH1zqad+ciZfOxjkEtAxw7wQbVUz42WnouER9mYzrXPA6U1meh+slVr6k mWdxJWiLYc0wtvqMySFQpzpLb3NFekdFFY02Wq0CHYNqIXnZ7avsMVaBwvnoi+bc JNSOFsxkhIIle2yBGNNklpBDc9UnGwD8T6oq+EPmIQDvDYxMW5ifiEMW3WhTzHtq On8Svf45jt8dLfzbYO700Vt+rDqVeCb4NTkYoO17PYP4x4ZIvHQstubEWlxdnXyt zNeuahSgH7vutCD5xtW2 =BUki -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0297 (Stanza Forwarding)
On 5 June 2013 16:24, Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/5/13 4:00 AM, Matthew Wild wrote: On 23 August 2012 00:04, XMPP Extensions Editor edi...@xmpp.org wrote: This message constitutes notice of a Last Call for comments on XEP-0297 (Stanza Forwarding). I have incorporated the feedback received so far, and a revised version can be found here: http://matthewwild.co.uk/uploads/xep-0297.html http://matthewwild.co.uk/uploads/xep-0297.xml http://matthewwild.co.uk/uploads/xep-0297.diff.html http://matthewwild.co.uk/uploads/xep-0297.wdiff.html Would you like that version published as 0.5? Yes please, it seems sane to me. Regards, Matthew
Re: [Standards] LAST CALL: XEP-0301 (In-Band Real Time Text)
On 2013-05-28 22:30, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0301 (In-Band Real Time Text). Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Real-time text is text transmitted instantly while it is being typed or created. URL: http://xmpp.org/extensions/xep-0301.html This Last Call begins today and shall end at the close of business on 2013-06-28. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: Being a co-author, I feel that I should anyway express my view of this specification. 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes, it fills a gap. 2. Does the specification solve the problem stated in the introduction and requirements? Yes. 3. Do you plan to implement this specification in your code? If not, why not? Yes. 4. Do you have any security concerns related to this specification? No. We are just asked to explain better a security related question on transmission timing attacks, placed by Peter Saint-Andre. It has a positive answer. 5. Is the specification accurate and clearly written? Yes. Your feedback is appreciated! I am glad to be part of this work initiated by Mark Rejhon. I think it contributes in a good way to usability enhancement of XMPP. Regards Gunnar Hellström Omnitor
Re: [Standards] LAST CALL: XEP-0301 (In-Band Real Time Text)
XMPP Extensions Editor schreef op 28/05/2013 22:30: This message constitutes notice of a Last Call for comments on XEP-0301 (In-Band Real Time Text). Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Real-time text is text transmitted instantly while it is being typed or created. URL: http://xmpp.org/extensions/xep-0301.html This Last Call begins today and shall end at the close of business on 2013-06-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? yes 2. Does the specification solve the problem stated in the introduction and requirements? yes 3. Do you plan to implement this specification in your code? If not, why not? yes 4. Do you have any security concerns related to this specification? No. 5. Is the specification accurate and clearly written? yes It's ready for production and many deaf poeple will be very happy. It will improved for all people that will using rtt on xmpp (for example whatsapp and facebook chat)
Re: [Standards] LAST CALL: XEP-0297 (Stanza Forwarding)
On Wed, Jun 5, 2013 at 4:52 PM, Matthew Wild mwi...@gmail.com wrote: On 5 June 2013 16:24, Peter Saint-Andre stpe...@stpeter.im wrote: On 6/5/13 4:00 AM, Matthew Wild wrote: http://matthewwild.co.uk/uploads/xep-0297.html I reviewed this version. Overall I think this is good to go, but I'm concerned that it has lots of SHOULD that seems like it ought to be MUST, and I'm not clear this has received any discussion: §3.2 (1) discusses incomplete forwarding, particularly removal of chatstates, etc. I would suggest that different use-cases for forwarding affect this, and would appreciate a note suggesting that other extensions (and I'm waggling eyebrows suggestively toward XEP-0280 here). §3.2 (3) has some odd wording about xml namespaces - clearly if the forwarding element itself is prefixed, the second sentence will not occur. This second sentence feels like an implementation note to me, and needs to be worded along the lines of: Implementation Note: Particular care should be taken if the forwarded/ element is used unprefixed, and thus declares the default namespace to be urn:xmpp:forward:0, as this would cause the default namespace of the stanza to be incorrect unless redeclared, as per XML namespace processing rules. §3.2 (4) describes a strong recommendation, but does not discuss when this might be broken or why. Certainly the latter phrase and a receiving client should seems orthogonal, and seems like a security consideration rather than a business rule. (In fact, it's already present as such, in §5.1) In contrast, I wonder if §3.2 (3)'s absolute requirement to leave a jabber:server and jabber:client unchanged is required to be so strong (and, moreover, whether this is even a good idea). I'd be inclined to argue that a stanza SHOULD always have from and to completed (the exceptional case being in a reporting protocol where the absence of an addressing attribute might be significant) and the namespace SHOULD be the application namespace of the stream (ie, always jabber:client for clients). Otherwise there's some odd handling if you have inbound stanzas from servers (or worse, components) being forwarded. As an aside, the current schema prevents stanzas from being forwarded from XEP-0114 components. As usual, I'll be happy to be told that all my points have been discussed to death already. Dave.
Re: [Standards] LAST CALL: XEP-0288 (Bidirectional Server-to-Server Connections)
On 6/4/13 11:51 PM, Michal 'vorner' Vaner wrote: Good morning I did not write the XEP, not really read it whole, but from common sense: On Tue, Jun 04, 2013 at 03:41:34PM -0600, Peter Saint-Andre wrote: Section 2.1: If a server supports bidirectional server-to-server streams, it should inform the connecting entity when returning stream features during the stream negotiation process (both before and after TLS negotiation). Is there any reason why the should is not a MUST? I can imagine a server not wanting to enable it for some domains and enable it for others. In such case, it would send the feature to those it wants it enabled for. Sure, that makes some sense. Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] resurrecting Hop Check (XEP-0219)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been thinking I'd like to resurrect the Hop Check proposal (because after further reflection I think it would be useful, even if not perfect): http://xmpp.org/extensions/xep-0219.html Before I post an updated version, does anyone have requests for data they'd like to see included in the data format? Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRr/BwAAoJEOoGpJErxa2pHR0P/0jTB9b8UTCUJOnmRfPyACF9 7FI++aJ7a1woKFMnH5Tt0JnZ28SzFed3o9XkusUoC5PFbUiTSNcCRTHvCFeiGozE vLY3yXwQuZiUc0fEuwWRrhfgodkSyRrP9vtSax56BWbHMFvrslcbDBPPkQazW79A fZq9b1bF3df4aPX8L2RGNPTpeb/wCqjacznNEfQ093ZsBrVvZ3xTwxJQKLMdOG9s ElckIiTKqdSvepHzq9f0wmngsPEbkxALM6m/WvDFZeLhm+UCkwvvPLv5EngCLIj1 K9SAfpbgHirO007s5iyPgwJiAqcZecJ8alC8u435h3wc85Zs4S0Z9ZYBLus+jrnr RKeSSDSYXLcz+jomk13BIw77a+izFysj9kPljPEgEBH8lqzflGrFKl/r6/kbtnVn P9MeaOspoXLgz+NHXw0qhvjjtvpN+T8x1pJdyL9dTsrPmMDjaBfQVX784R9PcY6r 980BGm6nRf89raPHLzKaj4/uGyMOub0wyFGW2sQHdBHpr4ln4MQGyiv+qNa0w1Aq pUB610h41uf/3M7ifXlxv1HhNZxf2+Gj3n3E/RnP+4toK1h4PPWNJvpBuI3f7UBa nEETd19/UBxlNVA7WelNzaWVA/K6WoQDiiH1hfZmKALfQu+yystGaM0gY8Ulw3dt C/igyQGvxz28GvQxUb3y =wbXd -END PGP SIGNATURE-
Re: [Standards] resurrecting Hop Check (XEP-0219)
I've been thinking I'd like to resurrect the Hop Check proposal (because after further reflection I think it would be useful, even if not perfect): for debugging/support? +1 [...] Before I post an updated version, does anyone have requests for data they'd like to see included in the data format? A bidi flag (for s2s) and the raw certificate data for both dialback and external auth. Probably also whether an SRV record was resolved or the A fallback is used. And keep in mind that most s2s connections still aren't bidi, see the list archives from 2007 for some discussion ;-)
