[Standards] UPDATED: XEP-0280 (Message Carbons)
Version 0.13.1 of XEP-0280 (Message Carbons) has been released. Abstract: In order to keep all IM clients for a user engaged in a conversation, outbound messages are carbon-copied to all interested resources. Changelog: Add clear example on problematic (spoofed) carbon messages and that they need to be handled. (gl) URL: https://xmpp.org/extensions/xep-0280.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] NEW: XEP-0423 (XMPP Compliance Suites 2020)
Version 0.1.0 of XEP-0423 (XMPP Compliance Suites 2020) has been released. Abstract: This document defines XMPP protocol compliance levels. Changelog: Accepted by vote of Council on 2019-09-11. (XEP Editor (jsc)) URL: https://xmpp.org/extensions/xep-0423.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] NEW: XEP-0422 (Message Fastening)
Version 0.1.1 of XEP-0422 (Message Fastening) has been released. Abstract: This specification defines a way for payloads on a message to be marked as being logically fastened to a previous message. Changelog: Typographical fixes (lnj) URL: https://xmpp.org/extensions/xep-0422.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-0060 (Publish-Subscribe)
Version 1.16.0 of XEP-0060 (Publish-Subscribe) has been released. Abstract: This specification defines an XMPP protocol extension for generic publish-subscribe functionality. The protocol enables XMPP entities to create nodes (topics) at a pubsub service and publish information at those nodes; an event notification (with or without payload) is then broadcasted to all entities that have subscribed to the node. Pubsub therefore adheres to the classic Observer design pattern and can serve as the foundation for a wide variety of applications, including news feeds, content syndication, rich presence, geolocation, workflow systems, network management systems, and any other application that requires event notifications. Changelog: Add a pubsub#rsm disco#info feature to clear confusion (edhelas) URL: https://xmpp.org/extensions/xep-0060.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] Council Voting Summary 2019-08-06
On Wed, 11 Sep 2019 at 16:35, Marvin W wrote: > By specifically > disallowing referencing of messages that reference other messages it > obviously is not a general referencing. I actually quite like this restriction - it means I can split IM traffic into "Messages" and "Attachments". It also means it's unsuited to, say, Slack-style threading (but then we have if people actually want to go that route). But a smaller, more contained data model means that, in turn, I have the ability to have an archive of messages, and for each message have the reactions and other ancillary data that's needed. That said, I'm not entirely convinced that message receipts, edits (and retractions) need to either not apply to, or should be, fastenings, so perhaps that simplifies the problem space sufficiently. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Voting Summary 2019-08-06
On 11.09.19 17:22, Jonas Schäfer wrote: > I recall you stating in the past that Message Attaching would not be fit to > general referencing use-cases (such as Emoji Reactions), which is what > Fastening aims at. I don't read Fastening at aiming a general references use-case, but more a specific subset of it (small information/markup that is attached to a single message but doesn't make sense on its own). By specifically disallowing referencing of messages that reference other messages it obviously is not a general referencing. It does fit to some degree for the use cases of Reactions, Delivery Receipts and maybe message edits (although this is debatable given it apparently needs the special meaning of removing some unrelated previous Fastenings then). As I understand Message Attaching, it creates a full-featured message (that still can receive Delivery Receipts, Reactions or edits) that is just visually attached to another one. Marvin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Proposed XMPP Extension: Authorization Tokens
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Authorization Tokens Abstract: This document defines an XMPP protocol extension for issuing authentication tokens to client applications and provides methods for managing сlient connections. URL: https://xmpp.org/extensions/inbox/auth-tokens.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 ___
Re: [Standards] Council Voting Summary 2019-08-06
On Freitag, 6. September 2019 16:47:23 CEST Sam Whited wrote: > On Fri, Sep 6, 2019, at 10:08, Kevin Smith wrote: > > I’ve instead submitted a fastening protoXEP that Reactions can use to > > allay my concerns. If that is published, I’m amenable to accepting > > reactions as-is and immediately updating it to use fastening > > (providing we agreed that me doing so was appropriate), or for the > > authors to update pre-publish. > > At a quick glance this seems broadly similar to XEP-0367: Message > Attaching, would it be better to just add you as an author and you can > add external payloads to that instead of having yet another XEP that > does the same thing and muddies the waters when people are trying to > figure out what they should use to actually implement a feature? I recall you stating in the past that Message Attaching would not be fit to general referencing use-cases (such as Emoji Reactions), which is what Fastening aims at. 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 ___
[Standards] Council Voting Summary 2019-09-10
2019-08-07 (expired 2019-08-21)
FAILED (-0:4:+1) PR #806 - XEP-0060: Add pubsub#public in Publish-Subscribe
features - https://github.com/xsf/xeps/pull/806
VETOED (-1:3:+1) PR #808 - XEP-0045: Add Tags configuration and metadata -
https://github.com/xsf/xeps/pull/808
PASSED (-0:1:+4) PR #805 - XEP-0060: Add a pubsub#rsm disco#info feature to
clear confusion - https://github.com/xsf/xeps/pull/805
2019-08-28 (expiring 2019-09-11)
Advance to Draft: XEP-0300 (Use of Cryptographic Hash Functions in XMPP) -
https://xmpp.org/extensions/xep-0300.html
Dave: +1 (agree with Kev)
Georg: +1
Jonas: +1 (I think)
Kev: +1 (agree Table 1 is problematic; there to supplement IANA Registry - it
may change over time, but so will the registry)
Link: [on-list]
Advance to Draft: XEP-0353 (Jingle Message Initiation) -
https://xmpp.org/extensions/xep-0353.html
Dave: -1 (agree with Kev)
Georg: -1 (sure some of {0280, 0313, 0353, 0357} will need to be changed to
make this sound)
Jonas: -1 (the LC provided valuable feedback to be considered before Draft)
Kev: -1 (until there is a clearer picture - LC feedback suggests outstanding
questions)
Link: [on-list] (default to +1)
2019-09-04 (expiring 2019-09-18)
Proposed XMPP Extension: XMPP Compliance Suites 2020 -
https://xmpp.org/extensions/inbox/cs-2020.html
Dave: [on-list] (need time to look at this)
Georg: +1 (obviously)
Jonas: +1 (we can discuss details in Experimental)
Kev: [on-list]
Link: [pending]
PR #812 - XEP-0084: Bump bytes datatype from unsignedShort to unsignedInteger -
https://github.com/xsf/xeps/pull/812
Dave: +1 (just rectifies an error in the XML schema)
Georg: [on-list]
Jonas: +1
Kev: [on-list] (default to +1, unless I think of a reason later)
Link: [pending]
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
[Standards] Council Minutes 2019-09-04
http://logs.xmpp.org/council/2019-09-04?p=h#2019-09-04-16a6af505da630a8 1) Roll Call Present: Kev, Dave, Georg, Jonas Touring Europe: Link 2) Agenda Bashing Dave notes the CS-2020 proto-XEP; Jonas adds PR #812. 3a) Proposed XMPP Extension: XMPP Compliance Suites 2020 - https://xmpp.org/extensions/inbox/cs-2020.html Georg: +1 (obviously) Kev: [on-list] Jonas: +1 (we can discuss details in Experimental) Dave: [on-list] (need time to look at this) Link: [pending] 3b) PR #812 - XEP-0084: Bump bytes datatype from unsignedShort to unsignedInteger - https://github.com/xsf/xeps/pull/812 Georg: [on-list] Dave: +1 (just rectifies an error in the XML schema) Kev: [on-list] (default to +1, unless I think of a reason later) Jonas: +1 Link: [pending] 4) Outstanding Votes Dave thinks Georg and Link have some votes outstanding; Georg mailed votes last night. Jonas changes his vote on XEP-0353 to -1 (the LC provided valuable feedback to be considered before Draft.) 5) Next Meeting 2019-09-11 1500 UTC 6a) AOB i Georg thinks the Introduction in XEP-0412 (XMPP Compliance Suites 2019) is awful for informing developers that this is the XEP for guidance on what to implement first - would like to change this text to make compliance a secondary concern. Jonas and Dave are supportive. 6b) AOB ii Georg has added a "Future Development" section [1] because something like that is needed, but the content is very rough - requests suggestions for XEPs to be included. Jonas delves into the future and suggests XEP-0500 (title to be announced). Dave says the text should have broad community agreement; Kev says in an Ideal World the community would agree with Council - Council has purview over, and should agree to a statement of, technical direction. Dave suspects this will cause a lot of discussion, but potentially few conclusions; Jonas thinks a Wiki page would be more appropriate - Georg accepts that is possible, but can always axe the section if there are issues. Kev thinks it would be fine with a little tweaking; if it simply says "These are the areas which Council believe …", then it's non-contentious as long as Council agree among themselves; or if it suggests these are areas under development, rather than forecasting the future. Kev very very very very very very very much thinks we should have that section, if only to stop the Compliance Suites from being used as a form of wishful thinking. Jonas agrees with the sentiment, but doesn't think the Compliance Suites are the right place for that, though it would make their purpose immediately clear (by having a dedicated Future section.) Georg thinks there is value in having a section containing XEPs that implementers should watch closely, and possibly implement (on the understanding they will likely change). Dave says there is both aspirational and development stuff that could be there - Georg thinks it need subsections; Kev suggests adding a summary of why it's there. 6c) AOB iii Georg doesn't expect the remaining items to fit into the remaining three minutes - they each deserve a Council Meeting of their own. Georg requests comments on-list in reply to "Persisting Message Errors (XEP-0280, XEP-0313, XEP-0160)" [2]. 6d) AOB iv Kev thinks archives need to be drastically rethought - Georg suggests rethinking message delivery, and then fixing archives on the way (not that this wasn't supposedly started two years ago.) Dave is a little concerned that there is a risk for every XEP in this space to be rejected unless someone comes up with a proposal - Ralph and Kev have been working on something they hope will lead to a proposal; Georg mentions that there was a very productive discussion a few days ago [3], which he tried to summarise [4]. Kev says Ralph is writing a blog post [5] about it. Jonas tried to contact the authors of Reactions (concerning follow-up), but didn't get a reply - Dave notes that Marvin did join the XSF, which is positive. Kev is ahead of his schedule and might be able to write something tomorrow - asks whether he should update XEP-0367 (Message Attaching), or write a new, if mostly duplicate, one for attaching, or roll it into XEP-0372 (References) - Jonas thinks a breaking change will be needed in any case, so go with a separate document for now. Kev would like guidance from Council, to avoid a fight about having done the wrong thing. Kev assumes there is no desire to have all of this described in a single document - Georg agrees; Jonas says References needs fixing first; Dave honestly doesn't care. Georg says three use cases were identified in the discussion, and each should have its own document; Kev says there are three halves: references, attaching, and threads (but that can be left for now.) Dave notes the meeting is now 10 minutes over, and would like to call it a day. Kev would like a concrete agreement on the approach - updating References for one half, and a new proto-XEP for the other (possibly later
