Re: [Standards] XMPP Council Minutes 2019-01-09
Hello, Le lundi 14 janvier 2019, 02:41:57 CET Tedd Sterr a écrit : > 3) Proposed XMPP Extension: Order-By - > https://xmpp.org/extensions/inbox/order-by.html > > Georg thinks it's a very specific use case, and defines two hard-coded > properties (creation and modification timestamp) for ordering on, whereas it > would be cleaner to allow ordering by any field. Jonas and Dave point out > that the properties are external to the items themselves. > Jonas wants to discuss further with the author about points already raised. > Georg wonders why the properties couldn't be embedded in the items - Jonas > say servers must not modify items; Georg suggests the client could add the > timestamps itself, but Jonas says the author dislikes this as it would allow > them to be spoofed. > Georg thinks it needs to be renamed to "PubSub MAM Retrieval Ordered by > Creation or Modification." > Dave noticed that it apples to MAM but doesn't really discuss it, and > presumably also has an impact on RSM. Jonas says it doesn't impact RSM, but > the server might have to use different identifiers in RSM to work correctly; > Dave thinks that's worth thinking about and mentioning. Kev says it does > interact with RSM, but 'impact' is a matter of interpretation. > Kev would like to see this have a little more work before being published, > but couldn't find a reason to veto. > > Jonas: [on-list] > Georg: [on-list] (with fallback to -1: very specific use case; requires > [implementation] changes to other XEPs) > Kev: +1 (not keen on it, but it clears the bar-of-incompetence for > Experimental) > Link: [on-list] (still catching up on everything) > Dave: +0 (reserve the right to change that while others are still on-list) For the record, I've answered to the concerns raised by the council at https://mail.jabber.org/pipermail/standards/2019-January/035646.html . I hope this helps. Thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Voting Summary 2019-01-13
2018-12-19 (expired 2019-01-02) PASSED (-0:1:+4) Last Call: XEP-0410 (MUC Self-Ping (Schrödinger's Chat)) - https://xmpp.org/extensions/xep-0410.html 2019-01-09 (expiring 2019-01-23) Proposed XMPP Extension: Order-By - https://xmpp.org/extensions/inbox/order-by.html Dave: +0 (reserve the right to change that while others are still on-list) Georg: [on-list] (with fallback to -1: very specific use case; requires [implementation] changes to other XEPs) Jonas: +1 (useful as-is; could imagine generalising to all types of result sets, e.g. disco#items on MUC) Kev: +1 (not keen on it, but it clears the bar-of-incompetence for Experimental) Link: [on-list] (still catching up on everything) PR #715 - XEP-0045: Add missing disco#info feature to example 4, 9, 78 and 218 - https://github.com/xsf/xeps/pull/715 Dave: -0 Georg: -0 (I like my examples short and focused) Jonas: -0 Kev: -0 (Don't care) Link: +1 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Minutes 2019-01-09
http://logs.xmpp.org/council/2019-01-09/#16:00:55 Dave got around to writing an agenda, though it seems to have been missed by many as it was not sent to 'standards', but only to the 'council' mailing list (to which Jonas is, curiously, not subscribed - Kev offers to do the magic.) 1) Roll Call Present: Kev, Jonas, Link, Georg, Dave Dave and Jonas apologise for their absence last week. 2) Agenda Bashing Did Dave forget anything? Jonas wouldn't know as he hasn't seen the agenda. Georg suggests splitting PR #727 (item 6a) into individual LCs for process' sake. 3) Proposed XMPP Extension: Order-By - https://xmpp.org/extensions/inbox/order-by.html Georg thinks it's a very specific use case, and defines two hard-coded properties (creation and modification timestamp) for ordering on, whereas it would be cleaner to allow ordering by any field. Jonas and Dave point out that the properties are external to the items themselves. Jonas wants to discuss further with the author about points already raised. Georg wonders why the properties couldn't be embedded in the items - Jonas say servers must not modify items; Georg suggests the client could add the timestamps itself, but Jonas says the author dislikes this as it would allow them to be spoofed. Georg thinks it needs to be renamed to "PubSub MAM Retrieval Ordered by Creation or Modification." Dave noticed that it apples to MAM but doesn't really discuss it, and presumably also has an impact on RSM. Jonas says it doesn't impact RSM, but the server might have to use different identifiers in RSM to work correctly; Dave thinks that's worth thinking about and mentioning. Kev says it does interact with RSM, but 'impact' is a matter of interpretation. Kev would like to see this have a little more work before being published, but couldn't find a reason to veto. Jonas: [on-list] Georg: [on-list] (with fallback to -1: very specific use case; requires [implementation] changes to other XEPs) Kev: +1 (not keen on it, but it clears the bar-of-incompetence for Experimental) Link: [on-list] (still catching up on everything) Dave: +0 (reserve the right to change that while others are still on-list) 4) Outstanding Votes Dave doesn't imagine there are any. Georg mutters something about spreadsheets and doom. 5) Next Meeting 2019-01-16 1600 UTC Georg will be in a present-absent quantum superposition for the next few months, but hopes reality will collapse into one possibility in time for next week. 6) AOB 6a) Cleaning up Deferred items (wrt PR #727 - https://github.com/xsf/xeps/pull/727) Jonas says the PR can't be applied as-is, and proposes that Editor just closes it; if such process is desired, a modification to XEP-0001 is needed. Dave asks whether someone wants to take on changing the process, or does nobody care about clearing out old Deferred XEPs. Link believes Obsolete is the correct status for those three XEPs (and more, but let's start small.) Jonas says they would have to be Draft to allow for obsoletion; Dave notes Proposed->Rejected exists; Jonas agrees rejecting would also be an option. Dave would happily allow Deferred->Rejected, as it feels more accurate. Dave puts forward two questions: What do we want the process to be? and Who wants to draft the PR to XEP-0001? Jonas can do the PR to XEP-0001. Kev adds a third question: Is there a problem with Deferred XEPs staying Deferred? Jonas (as Editor) has no problem with this. Georg suggests adding Proposed->Deprecated. Dave notes that Deferred is much the same as expired Internet Drafts in the IETF, which are sometimes 'un-expired' years later. Kev doesn't see a particular problem with something being Deferred for eternity, reflecting the actual state of "abandoned before advancement." Link would mainly like to solve the problem of people being expected to read Deferred XEPs (replete with a big red warning) because process is too slow. Georg, agreeing with Link, thinks 'Deprecated' is a stronger signal not to implement than 'Deferred.' Jonas says it's more worthwhile to tackle the XEPs that are worthy of advancement than those which are dead anyway. Kev asks if the problem is really one of rescuing XEPs from Deferred that shouldn't have been deferred, rather than moving them when they are abandoned - Link would like to do both in the end. Dave says moving an XEP from Deferred is easy, and isn't sure how to make that any faster. Jonas says the actually-abandoned XEPs aren't the actual issue. Link notes that fixing a typos in Deferred XEPs has moved them back to Experimental, and would like to avoid that; Jonas agrees. Georg says editorial changes shouldn't count; Jonas says it needs fixing, but is a separate issue - there are varying opinions (any change means someone cares enough, versus only non-editorial changes should un-defer) and maybe Board should clarify. Dave tries to move things along and requests that if someone cares they should take this to the standards
Re: [Standards] LAST CALL: XEP-0345 (Form of Membership Applications)
On 2019/01/12, Jonas Schäfer wrote: > This message constitutes notice of a Last Call for comments on > XEP-0345. > > Note: Since this is a Procedural XEP under control of Board, the Last Call > mail goes to both standards@ and members@ (only for XSF members) mailing > lists. This may lead to fragmentation of feedback. The archives of the lists > are at [1] and [2] respectively. > > Title: Form of Membership Applications > Abstract: > This specification outlines the form and mandatory content of > membership applications. > > URL: https://xmpp.org/extensions/xep-0345.html > > This Last Call begins today and shall end at the close of business on > 2018-01-27. > > Please consider the following questions during Last Call and send your > feedback to either or both of the members or the standards discussion list. > > 1. Is this document needed to fill gaps in the XMPP Standards Foundation's > policies and procedures, or to clarify an existing XSF policy or procedure? Yes. I just reread the bylaws, and there does not seem to be any indication of what information is required to apply for membership. > 2. Does the document address the problem stated in the introduction and > requirements? Yes. > 3. Should the XSF adopt this document as part of its policies and procedures? Unsure. See concerns / questions below. > 4. Do you have any concerns about the effects of this policy? §2 of the XEP -- "Who May Apply" -- specifies that it is not normative, but it states: > only "natural persons" The bylaws directly conflict with this in §2.1 "Admission of Members": > [..] to be eligible for membership, a person, corporation, organization, > or other entity [..] This is confusing to say the least. Another concern that has surfaced not so long ago, and which is the reason of this LC, is about requiring a Legal Name, §6 "Mandatory Information". Would it be possible to know if there is actually any legal requirement for this? Board members are not actually required to be members to apply. As for council, do they have any legal authority? It was also mentioned on xsf@ that using a pseudonym might be used to apply for membership multiple times, and thus influence votes. When in reality, I could just as well use a Real-looking name, since I don't think there is any verification in place. If legal name becomes a requirement, will we have to do verifications? I am personally not for enforcing the legal name if there is no legal requirement. > 5. Is the document accurate and clearly written? Not entirely sure what "accurate" is supposed to mean, but the document is clearly written. Cheers, -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2019
On Sonntag, 13. Januar 2019 17:33:38 CET Ненахов Андрей wrote: > There is, however, a really big problem that no one seems to be > talking about - it's not the protocol, but accompanying behaviour. > Simple example: subscription request. It looks like very simple, but > it's not. It is more or less straightforward only if user has just one > device. But if it has more devices? > - Romeo has XMPP clients on phone and tablet > - Romeo has received subscription request from Juliet > - Romeo opened dialog on tablet, but switched to phone > - Romeo opened same dialog on phone and accepted subscription > - What should happen on tablet? Should it close this dialog? What > should tablet open after closing dialog? main screen, or user details? Those are indeed important considerations, but not relevant to the current form of Compliance Suites. Note that the XSF is primarily a *XMPP Standards* Organisation, and as such focuses on the protocol. Still. The issues you raise are important. There are several people interested in doing similar things, and I suggest that you hang out in the xmpp:x...@muc.xmpp.org?join or xmpp:x...@chat.yax.im?join MUCs and/or contribute to the wiki (there are pages such as [1], [2], [3] which could use some contributions, with cases like the one you described). [1]: https://wiki.xmpp.org/web/XMPP_IM_Client_Design_Guidelines [2]: all in https://wiki.xmpp.org/web/Category:Easy_XMPP [3]: https://wiki.xmpp.org/web/Usability/Glossary signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2019
I have an issue with these compliance suites. I think for the most part it's a pointless bureaucracy. Just listing XEPs makes it an artificial metric that can be gamed easily. Typically if XMPP client supports just one tiny part of a XEP, app developer immediately claims this XEP support. We did it too, of course. This is kinda natural, because many XEPs are often more complex that developer needs, and it makes little sense to implement them fully just for compliance sake. Classic example is private messages in XEP-0045, and all these crazy roles/affilation models in it. So, just listing XEPs saves little purpose other than a faint guideline for an app developer if he's missing something. Also, I don't think that listing them as XEPs is a good idea. There is, however, a really big problem that no one seems to be talking about - it's not the protocol, but accompanying behaviour. Simple example: subscription request. It looks like very simple, but it's not. It is more or less straightforward only if user has just one device. But if it has more devices? - Romeo has XMPP clients on phone and tablet - Romeo has received subscription request from Juliet - Romeo opened dialog on tablet, but switched to phone - Romeo opened same dialog on phone and accepted subscription - What should happen on tablet? Should it close this dialog? What should tablet open after closing dialog? main screen, or user details? Current XMPP clients manage to do these very basic things in dramatically different ways, worsening interoperability and user experience. If compliance suites are aimed at harmonising a rather chaotic XMPP environment, it'd better think not of underlying protocols, but about user experience and why these protocols are needed in first place. I imagine that a proper compliance suite would be not a list of XEPs, but rather a list of test cases that describe behaviour in commonly occurring scenarios. It is more difficult and way more work, but would be of much more help to anyone who wants to implement some functionality in his client/server of choice. Also, this could be a basis for objective testing if some client is compliant or not to such suite. -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04 http://www.redsolution.ru ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Cryptographic Hash Function Recommendations for XMPP
On Sonntag, 13. Januar 2019 16:50:24 CET Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Cryptographic Hash Function Recommendations for XMPP > Abstract: > This document provides recommendations for the use of cryptographic > hash functions in XMPP protocol extensions. > > URL: https://xmpp.org/extensions/inbox/hash-recommendations.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. In this context, please see https://mail.jabber.org/pipermail/standards/2018-December/035562.html As it stands, the ProtoXEP duplicates a lot of XEP-0300. Once accepted, we can rectify that. See the proposal of this ProtoXEP as concrete proposal on where and how to split XEP-0300. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0412 (XMPP Compliance Suites 2019)
On Sonntag, 13. Januar 2019 17:02:21 CET Ненахов Андрей wrote: > > Changelog: > > * Remove XEP-0184 from server support (doesn't make sense) > > Actually, it does. Currently, when you start up a client (after some > time offline or just a first start of an app) you don't have any > information if message was delivered to or read by you chat partner. > This is massive problem for iOS when you have to resume chat state > after every push notification. So it would be nice if we could have a > standard way to fetch this metadata from server somehow. This is not in XEP-0184 as-is, so it doesn’t make sense to require server support for XEP-0184 at this time. I see that was a bit misleading, but I tried to keep the changelog concise. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0412 (XMPP Compliance Suites 2019)
> Changelog: > * Remove XEP-0184 from server support (doesn't make sense) Actually, it does. Currently, when you start up a client (after some time offline or just a first start of an app) you don't have any information if message was delivered to or read by you chat partner. This is massive problem for iOS when you have to resume chat state after every push notification. So it would be nice if we could have a standard way to fetch this metadata from server somehow. Some app developers use an ad-hoc approach to spam server archive with empty messages, using them as a quasi-permanent read markers, but we don't think it's a good method. We have a pretty clear idea of a XEP that we internally call 'conversations metadata' but it's not implemented yet. Most likely, it'll appear in a few months. -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04 http://www.redsolution.ru ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Proposed XMPP Extension: Cryptographic Hash Function Recommendations for XMPP
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Cryptographic Hash Function Recommendations for XMPP Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. URL: https://xmpp.org/extensions/inbox/hash-recommendations.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0412 (XMPP Compliance Suites 2019)
Version 0.4.0 of XEP-0412 (XMPP Compliance Suites 2019) has been released. Abstract: This document defines XMPP protocol compliance levels. Changelog: * Fix mess-up with TLS: TLS itself is of course required, it is just Direct TLS which is supposed to be advanced. * Add XEP-0308 (Last Message Correction) for Advanced Client * Minor typographical fixes (jsc) URL: https://xmpp.org/extensions/xep-0412.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2019
On Sonntag, 13. Januar 2019 16:12:04 CET Sam Whited wrote: > On Sun, Jan 13, 2019, at 11:26, Jonas Schäfer wrote: > > On Mittwoch, 12. Dezember 2018 18:05:26 CET Georg Lukas wrote: > > > * Jonas Schäfer [2018-12-08 20:06]: > > > > Title: XMPP Compliance Suites 2019 > > > > > > thanks for taking up the work! > > > Some remarks: > > > > > > IMO XEP-0184 is sufficiently important to become IM-Core, not just > > > IM-Advanced. > > > > I don’t think so. But same as for XEP-0333, if there are more voices in > > favour, I’m happy to change that. > > To both of these feedbacks I'd say the same thing: when we have old > compliance suites we look incompetent. This isn't a delay that we can put > down to not having enough volunteers. Yes, we can put this down to not having enough volunteers. You stepped down from doing the CS, which I can understand. There weren’t many volunteers to pick them up, at all (more below). Note that the suites will go through LC anyways, so I’m doing my best to avoid a second LC iteration by pushing updates and asking for feedback ahead of time. > Just get it out by the date on the > title, if something isn't quite right we'll have another shot at revising > them next year. That’s what’s happening right now, because see at the bottom of the mail. > It's several weeks into 2019, and we just look silly having > the 2018 compliance suites be official. There are other things which make the community look much sillier. Including having important extensions in Deferred or Experimental state. I prefer it if people sink their energy into that. > If there really wasn't enough time > to address feedback, then we should have gotten it to the council earlier. I agree. I messed up by underestimating my workload around the time I should’ve started the work on them. Nobody took up the work (or asked me whether they should), so, I’m rather confident that we don’t have any more volunteers to work on them. I also think that the process how we work on the CS isn’t quite right, and I have a modification in mind for next year’s, but that’s for then. I see your point, and you raised it last year, too. Re-iterating it in a 48 hour interval on the list will do nothing except draining more precious time from me and others by having to read and possibly reply to the email. If you want to help with the process, please skim the list archives and point me to feedback which I haven’t addressed with an update or a direct reply yet, so that I can incorporate it in an update before the next council meeting. Thanks. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2019
On Sun, Jan 13, 2019, at 11:26, Jonas Schäfer wrote: > On Mittwoch, 12. Dezember 2018 18:05:26 CET Georg Lukas wrote: > > * Jonas Schäfer [2018-12-08 20:06]: > > > Title: XMPP Compliance Suites 2019 > > > > thanks for taking up the work! > > Some remarks: > > > > IMO XEP-0184 is sufficiently important to become IM-Core, not just > > IM-Advanced. > > I don’t think so. But same as for XEP-0333, if there are more voices in > favour, I’m happy to change that. To both of these feedbacks I'd say the same thing: when we have old compliance suites we look incompetent. This isn't a delay that we can put down to not having enough volunteers. Just get it out by the date on the title, if something isn't quite right we'll have another shot at revising them next year. It's several weeks into 2019, and we just look silly having the 2018 compliance suites be official. If there really wasn't enough time to address feedback, then we should have gotten it to the council earlier. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Le dimanche 13 janvier 2019, 12:53:51 CET Evgeny a écrit : > On Sun, Jan 13, 2019 at 2:40 PM, Goffi wrote: > > Future XEPs may extend this, but in case where it's too complicated, > > implementation has always the choice to not implement it, or to have > > different features with different backends. > > I really don't see how this will work in practice. > 1) a client issues a request with "direction"/whatever attribute > 2) a server responds with "not-implemented" or some such > 3) a client gets stuck? or should it re-send a modified request? Well clients already have to manage different feature set. It's more: 1) client discover features of pubsub service 2) a) if server do ordering, fine, we do optimal workflow b) if server doesn't support ordering, we can either show items in the not optimal order (bad UX but it works), or show a warning of whatever. This is a client decision and probably depends of the context. It's already the case for nearly every XMPP feature. For instance most pubsub services don't currently support MAM filtering. If it's available, nice you can click on categories to see filtered items, else you can't do that. In the same spirit, if other client doesn't support video, or e2ee, or whatever, you have to adapt. > Second problem is that competition in servers is quite high > and if customers/users want the feature then I have to implement it > somehow. > That has happened in the past already. If there is a high demand for a feature, there is probably a real need. I don't find this is a good reason to not implement something, quite the opposite actually. > Third problem is assuming SQL-only backend to support the > feature is the wrong approach, in my opinion. This is not assuming SQL only backend at all. You can even implement quite easily this XEP with flat files backend, you just have to keep a list of items ids ordered by creation date, which is trivial to do. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
On Sun, Jan 13, 2019 at 2:40 PM, Goffi wrote: Future XEPs may extend this, but in case where it's too complicated, implementation has always the choice to not implement it, or to have different features with different backends. I really don't see how this will work in practice. 1) a client issues a request with "direction"/whatever attribute 2) a server responds with "not-implemented" or some such 3) a client gets stuck? or should it re-send a modified request? Second problem is that competition in servers is quite high and if customers/users want the feature then I have to implement it somehow. That has happened in the past already. Third problem is assuming SQL-only backend to support the feature is the wrong approach, in my opinion. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Le dimanche 13 janvier 2019, 12:28:09 CET Evgeny a écrit : > On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote: > > For Pubsub services based on SQL or NoSQL databases, it should not be > > too hard to implement as ordering is most of time a part of API. > > Note however, that some NoSQL databases only support a single index > in the query, DynamoDB is such an example. You can apply post-filtering > of course (kinda map-reduce, where filtering is "reduce"), but it may > become inefficient depending on the query subset. > > That's just a thing to consider if you want to go too broad in > your specification. > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > Thanks for the pointer. I'm not planning to complicate more the XEP than it is now, so it should not go broader. Future XEPs may extend this, but in case where it's too complicated, implementation has always the choice to not implement it, or to have different features with different backends. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0412 (XMPP Compliance Suites 2019)
Version 0.2.0 of XEP-0412 (XMPP Compliance Suites 2019) has been released. Abstract: This document defines XMPP protocol compliance levels. Changelog: * Remove XEP-0184 from server support (doesn't make sense) * Do not require Avatars for Core clients * Add a note for RFC 7622 and do not require it * Do not require XEP-0368 in core servers (jsc) URL: https://xmpp.org/extensions/xep-0412.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0367 (Message Attaching)
Version 0.3 of XEP-0367 (Message Attaching) has been released. Abstract: This specification defines a method for indicating that a message contains content which describes an earlier message in the conversation and should be grouped with the earlier message. Changelog: Update to use unique stanza ids. (mw) URL: https://xmpp.org/extensions/xep-0367.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0394 (Message Markup)
Version 0.2.1 of XEP-0394 (Message Markup) has been released. Abstract: This specification provides an alternative to XHTML-IM with rigid separation of content and markup information, improving the resilience against spoofing and injection attacks. Changelog: Adopt deferred XEP. (kks) URL: https://xmpp.org/extensions/xep-0394.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Le dimanche 13 janvier 2019, 12:24:45 CET Evgeny a écrit : > On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote: > > a XEP for XPATH like syntax > > And the server will process this XPATH query? > Not sure if you're serious... This is a future plan, not concerning the current proposal, and will be discussed at the time. I'm not thinking about a full XPath engine of course, that would be overkill, just an ultra-simplied syntax to link a specific element or attribute in a stanza or payload. But it's definitely too early to discuss that. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2018-12-19
On Dienstag, 25. Dezember 2018 17:43:28 CET Kevin Smith wrote: > > On 20 Dec 2018, at 20:27, Tedd Sterr wrote: > > Dave noticed that Jonas pushed through XEP-0412 (XMPP Compliance Suites > > 2019) before all votes have been made, and has literally no idea what do > > to about it as there is no process to handle a process violation. Jonas > > suggests reverting the changes in Git; Georg suggests pretending it never > > happened unless the final vote contradicts, and revert if so. Dave thinks > > reverting would be a bad idea as it could lead to 0412 referring to a > > different XEP. > I don’t really want to be the blocker of progress, but there are various > things in here that I’m not convinced by. Sorry for putting the pressure on you by delaying the suites for such long time, even though I did not intend to do so. > Some of them (368) were existing > things that I don’t feel are really essential in a core client/server Noted and fixed. > , or > are inconsistent (84 but not 163 in a server), Noted and fixed. > others are new (what does it > mean for 184 to be supported by a server? That was simply a typo, thanks for pointing it out. > 398 is neat, but does it deserve > to be in a compliance suite already?). Yes, I think so. It provides valuable support in moving the ecosystem forward. > I’m also not sure that 7622 is > actually practically required for interop, as opposed to 6122, and a note > to that effect would be sane. Changed. (The actual change isn’t published yet, but it only hinges on the docker build.) kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote: For Pubsub services based on SQL or NoSQL databases, it should not be too hard to implement as ordering is most of time a part of API. Note however, that some NoSQL databases only support a single index in the query, DynamoDB is such an example. You can apply post-filtering of course (kinda map-reduce, where filtering is "reduce"), but it may become inefficient depending on the query subset. That's just a thing to consider if you want to go too broad in your specification. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2019
On Mittwoch, 12. Dezember 2018 18:05:26 CET Georg Lukas wrote: > * Jonas Schäfer [2018-12-08 20:06]: > > Title: XMPP Compliance Suites 2019 > > thanks for taking up the work! > Some remarks: > > IMO XEP-0184 is sufficiently important to become IM-Core, not just > IM-Advanced. I don’t think so. But same as for XEP-0333, if there are more voices in favour, I’m happy to change that. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2019
On Montag, 24. Dezember 2018 13:30:04 CET Georg Lukas wrote: > * Georg Lukas [2018-12-12 18:07]: > > There are some pet XEPs I have that I'd like to integrate: > And another one: > > Advanced IM Client: XEP-0333: Chat Markers > (should also be used/usable for inter-client read-state sync) I don’t think that this spec is in a place where it should be in any compliance suite. I’m not strongly opposed to including it, but I’d like to hear more voices in favour than just one. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote: a XEP for XPATH like syntax And the server will process this XPATH query? Not sure if you're serious... ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Hello, I've read the council logs, I'll try to defend the protoXEP here (in addition to what has already been said in this thread). > it's a very specific use case, and it defines two hard-coded properties to > order by. A clean approach would allow ordering by any field of the items, > using some XSLT magic or something. ([16:04:52] ) It's not a niche case at all, it's a major feature for blogging, and many other experimental features I'm working on and hope to standartize in the not too distant future (like tickets handler, forums or events). It seems that at least Movim would be interested too (cf. message from edhelas at https://mail.jabber.org/pipermail/standards/2018-August/035316.html). In my opinion, it is an important missing feature at the moment. About the ordering on arbitrary field, this has been debated with Jonas already (cf. https://mail.jabber.org/pipermail/standards/2019-January/035642.html): it is a future plan but will complicate a lot (a XEP for XPATH like syntax, the issue with data type, and the fields which can be missing in items, to quote the most important issues). > this needs to be renamed "PubSub MAM retrieval ordered by creation or > modification" ([16:07:42] ) I'll make an update to restrict to Pubsub, this doesn't have really much use/sense for MAM with instant messaging. Beside that, the XEP already states that it is extensible, it's not a pubsub only thing. I think for instance that it would be really useful to get list of MUC rooms ordered by number of participants, or order of creation. > I did notice this applies to MAM, too, but doesn't disucss it, and presumably > has quite an impact on RSM, but doesn't mention that. ([16:07:49] ) As said above, I'll restrict MAM to pubsub only. RSM is not impacted (there is the ID which could be something else than item_id, as noticed by Jonas, but this is already a RSM thing, nothing new). I'll mention the RSM after/before ID thing in next update. > I wouldn't be unhappy to see this have more work on it before it's published > ([16:09:06] ) Sure this was a first draft, I'll try to find time to update it today or tomorrow. > my rationale is that it's only adressing a very specific use case, and > requires changes to multiple other XEPs, like PubSub (for storing metadata) > […] it implies changes to their implementation. ([16:09:46] and [16:10:36] > ) No other XEP is modified. About implementation changes, well most of XEPs imply implementation changes. For Pubsub services based on SQL or NoSQL databases, it should not be too hard to implement as ordering is most of time a part of API. For Pubsub services based on flat files (I think it's the case for Prosody), well the feature is not mandatory, and the doc can say that this feature needs an other backend. For the metadata, there is not much to do: - ordering by modification time as defined in the XEP is actually the current default ordering of Pubsub, so there is nothing to do - ordering by creation date needs to keep the date of first item with a specific ID. In practice, you can do that by copying the date (or uid or whatever you're using) on the new item when you have an ID conflict, before destroying the old item, nothing fancy. That's it, I hope I have convinced you. Anyway this is experimental, time will show where it goes. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CORS for XEP-0156: Discovering Alternative XMPP Connection Methods
Hi Wiktor, On Freitag, 4. Januar 2019 11:48:23 CET Wiktor Kwapisiewicz wrote: > Hello, > > I have noticed that XEP-0363: HTTP File Upload was recently updated with > recommendations that make it possible to use from a web client, notably CORS > headers. [0] > > [0]: https://xmpp.org/extensions/xep-0363.html#impl > > I think the similar thing could be added to XEP-0156: Discovering > Alternative XMPP Connection Methods [1]. In this case (because it's only > GET) adding a single "Access-Control-Allow-Origin: *" header would allow > web clients to discover BOSH/WebSocket endpoints. > > [1]: https://xmpp.org/extensions/xep-0156.html#http > > The short summary of what would be changed is: > - recommending "Access-Control-Allow-Origin: *" for /.well-known/host-meta > and /.well-known/host-meta.json > > I don't know if that's the correct place, but depending on the connection > method the endpoints pointed to by host-meta would also need further > headers, e.g. "Access-Control-Allow-Origin: *" for WebSockets and > additionally > Access-Control-Allow-Methods: OPTIONS, HEAD, GET, PUT" for BOSH. I think that is a sensible thing to mention in the Implementation Notes. Would it be possible that you draft a patch and make a PR on GitHub [1] or send it via email here or to edi...@xmpp.org (make sure to mention the XEP-0156 in the subject)? Discussing a concrete patch is often easier :-). kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Please consider advancing Compliance Suites 2019
On Freitag, 11. Januar 2019 23:09:05 CET Sam Whited wrote: > Hi, > > It's 2019 now, and we're back in the situation of having two compliance > suites published, where the one that appears to be recommended doesn't seem > to be current. This is a very confusing situation. > > Please consider advancing the 2019 suites. I just now prepared an update which addresses the (some of the) concerns voiced by Georg and Kev. I’d also like to hereby add the LC for XEP-0412 to the Council agenda. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
On Sonntag, 13. Januar 2019 11:41:01 CET Goffi wrote: > Le samedi 12 janvier 2019, 20:50:25 CET Jonas Schäfer a écrit : > > […] > > The lack of clock synchronisation is a problem in any case, even when the > > timestamps are generated on the server side, since XMPP is federated. I’d > > even argue that it is *worse* when the server is solely responsible, > > because there is no way for a client to fix it. > > One node is on one server, so you have only one authority per node, the > order will be consistent within that node (you can't achieve that by > relying on X clients publishing X items). What I want to avoid, is what we > have with email, where spammer put dates in future to be always on top. > Note that this only influence the order, in XEP-0277 the creation and > update dates (what appears to end-user) are set by the client. Thanks, I wasn’t seeing that spoofing a date could be abused this way, and that the displayed date is still under control of the publishing client. That’s fine by me, then. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Le samedi 12 janvier 2019, 20:50:25 CET Jonas Schäfer a écrit : > They do, here’s how: You have two metadata fields, let’s call them Time and > Author. You have the following data: > > Time Author Item ID > 10:00 Alice1 > 11:00 Alice2 > 12:00 Bob 3 > 13:00 Bob 4 > 14:00 Bob 5 > 14:00 Carol6 > 15:00 Carol7 > > Suppose I want the posts ordered Ascendingly by Author, and use the time as > tiebreaker, descendingly. The resulting set would be: > > 2 1 5 4 3 7 6 Oh you're absolutely right, with multi-levels we could change ordering (ASC then DESC like here) while I was supposing it's always DESC, my bad. I'll add a "direction" argument defaulting to DESC, thanks for the explanation. > […] > I don’t think that relates to what I was trying to say. RSM relies strongly > on > having a unique, immutable identifier for items (which is used in > and ). On the *implementation* side (mind, I’m asking specifically > for > implementation guidance), I am not clear on what would be used here. Sure, > you > can use the Item ID, but there’s the problem that you cannot map that to an > SQL query with ORDER BY. You can use the classic "nth item in result set", > but > that loses the completeness and dub-free guarantees. OK I see. I have an implementation with SQL, and I'm doing an other SELECT with the item_id, I then get either the creation or modification date, and put it in a WHERE clause. But so far I was using one level of ordering, in case of multi-levels this is more complicated, I'll think about it, thanks for the pointer. > […] > The lack of clock synchronisation is a problem in any case, even when the > timestamps are generated on the server side, since XMPP is federated. I’d > even > argue that it is *worse* when the server is solely responsible, because there > is no way for a client to fix it. One node is on one server, so you have only one authority per node, the order will be consistent within that node (you can't achieve that by relying on X clients publishing X items). What I want to avoid, is what we have with email, where spammer put dates in future to be always on top. Note that this only influence the order, in XEP-0277 the creation and update dates (what appears to end-user) are set by the client. > I don’t see the faking of dates as an issue. At least for the blogging case. > Quite the contrary, I think it’s a good thing to have the flexibility (and in > a federated network, an adversary who wins by faking the dates can always > create their own server and spoof the dates there; so there’s no way for > clients to rely on those dates anyways). When you create a blog post, you usually also create the comments node on your own server, so you have control on both. When you visit a third party server, everything can be faked of course (including publisher jid and payload), but I suspect that the case when you want to visit a whole node maintained by a spammer is rare. So in nearly every common case, you can rely on the pubsub service dates for ordering. > On the other hand, I think that *not* letting the server do the date thing > and > instead selecting on the data already present in, for example, Atom, gives us > the advantage of being able to map existing Atom data into XMPP without loss > of usability and generality. I have plans for a future XEP allowing to order on arbitrary field, so client, knowing the context, could choose which method suits the best, but still I think it's important to be able to do it using pubsub service data. What to do if one or two items in a node are not following the right schema? Or if you use a XEP which doesn't set creation date? With pubsub service you are sure that the data is there and reliable (as long as you trust the node as said above). Note that ordering on arbitrary field is not that trivial, because Pubsub service doesn't know which fields are int, or dates, or something else. Also we would need a simplied XPATH like syntax, so a other XEP for that. If I can find some time today (I'm overwhelmed, so it's not sure at all), I'll try to update the protoXEP with all the insightful feebacks I've had sor far. Thank you all for those comments :) ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
