Re: [Standards] Council Minutes 2020-02-26

On 4 Mar 2020, at 15:00, Dave Cridland wrote: > > > > On Wed, 4 Mar 2020 at 10:23, Daniel Gultsch > wrote: > Am So., 1. März 2020 um 01:14 Uhr schrieb Tedd Sterr >: > > 4b) Advance XEP-0198 (Stream Management) - > >

Re: [Standards] LAST CALL: XEP-0398 (User Avatar to vCard-Based Avatars Conversion)

On 4 Mar 2020, at 10:00, Daniel Gultsch wrote: > > I’d like to get some more feedback (from more than 2 people) before I > rewrite vast parts of the XEP. > The XEP talks a lot about copy pasting one avatar to the other instead > of feeding them both from the same data storage. > To the user both

Re: [Standards] Council Minutes 2020-02-26

On 4 Mar 2020, at 10:22, Daniel Gultsch wrote: > > Am So., 1. März 2020 um 01:14 Uhr schrieb Tedd Sterr : >> 4b) Advance XEP-0198 (Stream Management) - >> https://xmpp.org/extensions/xep-0198.html >> Georg is unsure, but it's doing its job, expect for the unclear resume host >> connection

Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts

On 3 Mar 2020, at 17:45, Jonas Schäfer (XSF Editor) wrote: > > The XEP Editor would like to Call for Experience with XEP-0184 before > presenting it to the Council for advancing it to Final status. > > > During the Call for Experience, please answer the following questions: > > 1. What

Re: [Standards] XEP-0184: Message Delivery Receipts and XEP-0333: Chat Markers

At the risk of AOLing, I think I agree with pretty much everything Marvin says here. /K > On 4 Mar 2020, at 11:45, Marvin W wrote: > > XEP-0184 is doing one job, that is to notify the sender when a message > was delivered to the recipient's client. That's literally what the title > is. While

Re: [Standards] Council Minutes 2020-02-05

On 11 Feb 2020, at 09:17, Kevin Smith wrote: > > On 10 Feb 2020, at 10:09, Dave Cridland <mailto:d...@cridland.net>> wrote: >> >> PEDANTRY WARNING! >> ... > >> 3a) Call for Experience: XEP-0198 (Stream Management) - >> https://xmpp.or

Re: [Standards] Council Minutes 2020-02-05

On 10 Feb 2020, at 10:09, Dave Cridland wrote: > > PEDANTRY WARNING! > ... > 3a) Call for Experience: XEP-0198 (Stream Management) - > https://xmpp.org/extensions/xep-0198.html > > > > I do not need to vote on this, because the Council doesn't

Re: [Standards] Council Minutes 2020-01-22

On 29 Jan 2020, at 08:27, Georg Lukas wrote: > > * Tedd Sterr [2020-01-28 19:04]: >> 3a) Proposed XMPP Extension: Full Text Search in MAM - >> https://xmpp.org/extensions/inbox/fulltext.html > > +1 this is a good first step, and I'm sure we can figure out the > remaining parts (like an

Re: [Standards] A Meta-Discussion about the Standards Process

On 17 Jan 2020, at 09:54, Marvin W wrote: > > On 1/17/20 10:29 AM, Kevin Smith wrote: >>> I need a feature X *now* and all I see is >>> an experimental XEP I have two choices; Implement that Experimental >>> XEP or create something myself. >> I

Re: [Standards] A Meta-Discussion about the Standards Process

(Snipping bits that hopefully don’t cause a misrepresentation of Daniel’s views) On 17 Jan 2020, at 09:18, Daniel Gultsch wrote: > It *almost* feels like we shifted our stages to the left were Draft is > the new Final and experimental is the new Draft. The latter is > currently less true than

Re: [Standards] A Meta-Discussion about the Standards Process

> On 16 Jan 2020, at 22:15, Kevin Smith wrote: > > On 16 Jan 2020, at 21:50, Daniel Gultsch <mailto:dan...@gultsch.de>> wrote: >> >> Am Do., 16. Jan. 2020 um 21:32 Uhr schrieb Dave Cridland > <mailto:d...@cridland.net>>: >>> >>

Re: [Standards] A Meta-Discussion about the Standards Process

On 16 Jan 2020, at 21:50, Daniel Gultsch wrote: > > Am Do., 16. Jan. 2020 um 21:32 Uhr schrieb Dave Cridland >: >> >> >> >> On Thu, 16 Jan 2020 at 20:55, Daniel Gultsch wrote: >>> >>> Am Do., 12. Dez. 2019 um 09:24 Uhr schrieb Dave Cridland >>> : >>> 2) The

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

I don’t have feedback to give at the moment, but this is a thing we’ve needed for a long time, so a big thank you to Marvin for getting something submitted. /K > On 17 Dec 2019, at 11:18, p...@bouah.net wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title:

Re: [Standards] Proposed XMPP Extension: Message Fastening

Thanks for the feedback. I don’t want to ignore this, but was trying to digest bits. > On 12 Dec 2019, at 12:10, Marvin W wrote: > > On 12/11/19 6:50 PM, Kevin Smith wrote: >>> The business rules in §4 say that a Fastening can not have a Fastening >>> themselves

Re: [Standards] Proposed XMPP Extension: Message Fastening

On 12 Dec 2019, at 15:08, Dave Cridland wrote: > > On Thu, 12 Dec 2019 at 12:11, Marvin W mailto:x...@larma.de>> > wrote: > I think the question this comes down to is, what we want to build using > fastenings. I don't want reactions to reactions, but if we allow some > sort of "comment" as a

Re: [Standards] Proposed XMPP Extension: Message Fastening

Thanks Philipp. On 12 Dec 2019, at 13:53, Philipp Hörist wrote: > The solution for me is to separate metadata and content > > lets do something like > > to="chatroom@chatservice.example"> > > > Very much > > This seems like a good compromise, I’ll incorporate similar, thanks. (I

Re: [Standards] A Meta-Discussion about the Standards Process

On 12 Dec 2019, at 09:22, Dave Cridland wrote: > > Many moons past, we had a clever idea. > > What we thought was that we should change the XML namespace system we used - > previously, XEPs had been allocated a namespace when adopted, and they stuck > with this namespace throughout. Sometimes

Re: [Standards] Proposed XMPP Extension: Message Fastening

Thanks Marvin. I really am sorry for the delay in the reply. On 6 Sep 2019, at 23:11, Marvin W wrote: > > Just a few things I noticed while reading this proto xep: > > In the introduction it describes "a server adding information on a link > previously posted to a chat room" as a use case of

Re: [Standards] Proposed XMPP Extension: Message Fastening

> On 9 Sep 2019, at 20:37, Florian Schmaus wrote: > > On 9/5/19 7:52 PM, Jonas Schäfer (XSF Editor) wrote: >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Message Fastening >> Abstract: >> This specification defines a way for payloads on a message to be >>

Re: [Standards] Proposed XMPP Extension: Message Fastening

On 10 Sep 2019, at 08:20, JC Brand wrote: > > > > Am 7. September 2019 15:03:49 MESZ schrieb Andrew Nenakhov > mailto:andrew.nenak...@redsolution.com>>: >> Seems like a copy of XEP-0367 Message Attaching. It also shares the >> same >> problem: no explanation whatsoever on how to fetch these

Re: [Standards] Proposed XMPP Extension: Message Fastening

On 7 Sep 2019, at 14:17, Daniel Gultsch wrote: > > Am Sa., 7. Sept. 2019 um 13:05 Uhr schrieb Andrew Nenakhov > : >> >> Seems like a copy of XEP-0367 Message Attaching. It also shares the same >> problem: no explanation whatsoever on how to fetch these attachments from a >> Message Archive in

Re: [Standards] Proposed XMPP Extension: Message Fastening

On 7 Sep 2019, at 14:03, Andrew Nenakhov wrote: > Seems like a copy of XEP-0367 Message Attaching. It also shares the same > problem: no explanation whatsoever on how to fetch these attachments from a > Message Archive in any efficient way. Ideally, we should retrieve a message > from an

Re: [Standards] Resurrecting Reactions

On 10 Dec 2019, at 18:46, Andrew Nenakhov wrote: > > Our stance on reactions, in a collection of theses: > - the most practical way to address reactions is something we refer to as > 'fastening'. > - fastening also looks like the best way to attach error messages to stanzas > - fastening

Re: [Standards] Resurrecting Reactions

(Various bits snipped) On 10 Dec 2019, at 18:12, Jonas Schäfer wrote: > So... Uh. My problem with this situation is, that we’re in an awful > stalemate. > We have the suggestion by Kev on how to do the message fastening stuff, we > have the Attaching XEP (which Sam says could also be used for

Re: [Standards] Resurrecting Reactions

On 10 Dec 2019, at 18:12, Jonas Schäfer wrote: > I think > Kevin and the Reactions authors should have a direct discussion about > Fastening to move forward. It is my intention to find the Fastening feedback I missed and reply to the various threads over the next couple of days (including

Re: [Standards] Council Voting Summary 2019-10-22

On 30 Oct 2019, at 23:26, Kim Alvefur wrote: > > On Wed, Oct 30, 2019 at 10:52:35PM +, Kevin Smith wrote: >> On 23 Oct 2019, at 15:25, Tedd Sterr wrote: >>> Advance to Draft: XEP-0292 (vCard4 Over XMPP) - >>> https://xmpp.org/extensions/xep-0292.html >>&

Re: [Standards] Bookmarks 2 extensibility

On 25 Nov 2019, at 14:25, Dave Cridland wrote: > > On Mon, 25 Nov 2019 at 14:19, Evgeny > wrote: > On Mon, Nov 25, 2019 at 5:17 PM, Dave Cridland > > wrote: > > If you're saying we shouldn't have arbitrary namespaced data in such > >

Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)

(And this time I’ll remember to thank Georg for taking this on. Thanks Georg) > On 6 Nov 2019, at 13:43, Georg Lukas wrote: > > * Kevin Smith [2019-11-06 12:24]: >> I think the addition of ’66 is well-intentioned, but jabber:x:oob >> is underspecified (it defines a

Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)

On 6 Nov 2019, at 13:57, Daniel Gultsch wrote: > > Am Mi., 6. Nov. 2019 um 13:45 Uhr schrieb Georg Lukas : >> >> * Kevin Smith [2019-11-06 12:24]: >>> I think the addition of ’66 is well-intentioned, but jabber:x:oob >>> is underspecified (it defines a sy

Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)

> On 23 Oct 2019, at 16:07, Jonas Schäfer (XSF Editor) > wrote: > > This message constitutes notice of a Last Call for comments on > XEP-0423. > > Title: XMPP Compliance Suites 2020 > Abstract: > This document defines XMPP application categories for different use > cases (Core, Web, IM, and

Re: [Standards] Council Voting Summary 2019-10-22

On 23 Oct 2019, at 15:25, Tedd Sterr wrote: > Advance to Draft: XEP-0292 (vCard4 Over XMPP) - > https://xmpp.org/extensions/xep-0292.html > Dave: [pending] > Georg: [on-list] > Jonas: [on-list] > Kev: [on-list] (feels like we've done this already) > Link: [on-list] (will have to gather data

Re: [Standards] Council Voting Summary 2019-10-15

On 16 Oct 2019, at 15:32, Tedd Sterr wrote: > > > 2019-10-09 (expiring 2019-10-23) > > Proposed XMPP Extension: Message Retraction - > https://xmpp.org/extensions/inbox/message-retraction.html > > Dave: +1 (willing to be told I'm

Re: [Standards] Council Voting Summary 2019-10-08

On 8 Oct 2019, at 15:09, Tedd Sterr wrote: > 2019-09-25 (expiring 2019-10-09) > > PR #824 - XEP-0060: Add pubsub#public in Publish-Subscribe features - > https://github.com/xsf/xeps/pull/824 > Dave: [on-list] > Georg: [on-list] > Jonas: [on-list] > Kev:

Re: [Standards] Council Minutes 2019-09-18

On 20 Sep 2019, at 20:53, Tedd Sterr wrote: > 3) PR #828 - XEP-0045: add muc#roominfo_webchat_url form field as used in the > wild -https://github.com/xsf/xeps/pull/828 > Jonas: +1 (author's privilege) > Link: +1 > Georg: +1 > Dave: [pending] > Kev: [pending] -0 (I nearly -1d it, but decided if

Re: [Standards] Council Voting Summary 2019-08-06

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. /K > > Dave. > > On Thu, 29 Aug 2019 at 09:22, Kevin Sm

Re: [Standards] Council Minutes 2019-08-28

On 2 Sep 2019, at 20:57, Tedd Sterr wrote: > > 4a) Advance to Draft: XEP-0300 (Use of Cryptographic Hash Functions in XMPP) > - https://xmpp.org/extensions/xep-0300.html > > Georg: [on-list] > Jonas: +1 (I think) > Dave: +1 (I think) > Link:

Re: [Standards] Council Voting Summary 2019-08-06

> On 29 Aug 2019, at 09:19, Daniel Gultsch wrote: > > Hi, > > Am Mi., 7. Aug. 2019 um 16:18 Uhr schrieb Tedd Sterr : > >> VETOED (-1:0:+4) >> Proposed XMPP Extension: Message Reactions - >> https://xmpp.org/extensions/inbox/reactions.html >> Dave: +1 (enthusiastic about the problem space,

Re: [Standards] Persisting Message Errors (XEP-0280, XEP-0313, XEP-0160)

> On 1 Aug 2019, at 19:42, Ненахов Андрей > wrote: > > I imagine that a proper solution to this problem might be something > like... reactions? If we do reactions with some kind of attached > message, errors might be a special kind of attachments. Thinking > further, I like it even more:

Re: [Standards] Proposed XMPP Extension: Message Reactions

Blah, I flipped 367 and 372 a couple of times here. I’m fine with using Attaching for this and not References - apply that rule whenever I screwed up the numbers. /K > On 31 Jul 2019, at 16:58, Kevin Smith wrote: > > On 24 Jul 2019, at 21:00, Marvin W wrote: >> >>

Re: [Standards] Proposed XMPP Extension: Message Reactions

On 24 Jul 2019, at 21:00, Marvin W wrote: > > Hi, > >> * Jonas Schäfer [2019-07-15 17:59]: >> Title: Message Reactions >> This specification defines a way for adding reactions to a message. > > Given the feedback this proposed XEP received, I'd like to drop a few > more comments on the issues

Re: [Standards] Proposed XMPP Extension: Message Reactions

On 31 Jul 2019, at 16:40, Jonas Schäfer wrote: > > On Mittwoch, 24. Juli 2019 22:00:30 CEST Marvin W wrote: >>> Backward compatibility >> >> There clearly have been opposing opinions on that matter. I believe they >> are partly driven by different understanding on how Reactions might be >> used

Re: [Standards] Council Voting Summary 2019-07-28

> On 29 Jul 2019, at 02:15, Tedd Sterr wrote: > > > 2019-07-17 (expiring 2019-07-31) > > Proposed XMPP Extension: Anonymous unique occupant identifiers for MUCs > -https://xmpp.org/extensions/inbox/occupant-id.html > Dave: [pending] > Georg: +1 (would rather see occupant IDs in the form of

Re: [Standards] Inbox and Other Stories

There’s another aspect of unread/inbox that is worth thinking about while we’re trying to solve this, I think, which is that many modern systems have two levels of unread - unread message, and unread message that triggers a notification (e.g. @Kev @everyone), and we probably want to know that.

Re: [Standards] Council Voting Summary 2019-04-23

On 24 Apr 2019, at 01:57, Tedd Sterr wrote: > PR #778 - XEP-0280: Rewrite of the 'Messages Eligible for Carbons Delivery' > section -https://github.com/xsf/xeps/pull/778 > Kev: [on-list] (need to think about this at length) This one we agreed a way forwards (so technically -1 on the PR as-was,

Re: [Standards] Council Voting Summary 2019-04-23

On 24 Apr 2019, at 01:57, Tedd Sterr wrote: > PR #779 - XEP-0184: add a box about types and JIDs - > https://github.com/xsf/xeps/pull/779 > Kev: [on-list] I did try to start a discussion about this on-list, but got no replies. I wasn’t anticipating -1ing it, but I guess I should until that

Re: [Standards] Council Voting Summary 2019-04-14

On 14 Apr 2019, at 19:44, Tedd Sterr wrote: > PR #779 - XEP-0184: add a box about types and JIDs - > https://github.com/xsf/xeps/pull/779 > Dave: [pending] > Georg: +1 > Jonas: +1 > Kev: [on-list] > Link: +1 This seems a little backwards to me - it’s only saying the completely non-normative

Re: [Standards] XEP-0308: LMC of a previous correction

g a chain of messages), only replacing the payloads, etc. - my PR clarified this, although I don’t pretend that my PR is perfect, or removes all other opportunities for clarity in 308. > * Kevin Smith [2019-04-02 10:52]: >> It’s the original message @id - if you follow th

Re: [Standards] XEP-0308: LMC of a previous correction

Sorry that this got buried in my mailbox and I didn’t notice it. On 17 Nov 2018, at 16:32, Georg Lukas wrote: > when correcting a previously corrected message, do you reference the > original message @id or the message @id of the last correction to that > message? It’s the original message @id

Re: [Standards] Council Minutes 2019-03-20

On 21 Mar 2019, at 17:22, Tedd Sterr wrote: > 3b) Last Call: XEP-0353 (Jingle Message Initiation) - > https://xmpp.org/extensions/xep-0353.html > Link notes that there were comments on this from RalphM's previous team, and > Андрей's team too; Dave additionally notes Fippo's contacts. > Dave is

Re: [Standards] Council Minutes 2019-03-27

On 31 Mar 2019, at 00:19, Tedd Sterr wrote: > > http://logs.xmpp.org/council/2019-03-27?p=h#2019-03-27-237ca0091c8adb57 > > Dave is having a catastrophic day, so would be grateful for skipping the > meeting this week. > Jonas and Georg would like to at least get the vote started on the

Re: [Standards] XEP-0313 / XEP-0359 interaction

On 25 Mar 2019, at 11:48, Guus der Kinderen wrote: > > XEP-0313 "Message Archive Management" (v0.6.3) relies on XEP-0359 "Unique and > Stable Stanza IDs" to identify content in the archive. > > MAM provides an archive on the server, which can be efficiently synchronized > with a client-sided

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

> On 13 Mar 2019, at 17:37, Peter Saint-Andre wrote: > > I can help, but I would not object to adding a more active co-author > (preferably an implementor of the spec). Do you want to request a last call? Under the new rules Council aren’t allowed to trigger an LC any more unless either the

Re: [Standards] Council Minutes 2019-02-27

On 2 Mar 2019, at 18:56, Tedd Sterr wrote: > 3a) PR #758 - XEP-0060: Expose pubsub#access_model and pubsub#publish_model - > https://github.com/xsf/xeps/pull/758 > Jonas assumes this is still optional, so that existing services aren't > suddenly

Re: [Standards] Extending XEP-0085 Chat State Notifications, again

On 1 Mar 2019, at 09:18, Dave Cridland wrote: > > > > On Fri, 1 Mar 2019 at 08:35, Ненахов Андрей > wrote: > This was discussed in July 2018 and, I guess, moved nowhere, but I'll raise > the issue once again. Any decent messenger bar XMPP based ones

Re: [Standards] Third month with no updated compliance suites

On 4 Mar 2019, at 10:22, Guus der Kinderen wrote: > I do not dislike publishing the Compliance Suite content as part of the > website. It will make things more clear. I do not believe, however, that the > process of choosing what goes on that page is going to be faster, as compared > to doing

Re: [Standards] Carbons with Bind 2.0 and Routing 2.0

On 31 Jan 2019, at 18:20, Mathieu Pasquet wrote: > > Hi List, > > Looking at XEP-0409 and XEP-386, it appears that 0409 says: > >> A client activating IM-NG MUST NOT also activate Carbons. > > while 0386 says that after binding, the server MUST: > >> Silently enable carbons for this session

Re: [Standards] XMPP Council Minutes 2018-12-19

On 13 Jan 2019, at 11:29, Jonas Schäfer wrote: > > 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

Re: [Standards] Should we split XEP-0300 (Use of Cryptographic Hash Functions in XMPP) up?

On 16 Dec 2018, at 09:37, Jonas Schäfer wrote: > > This may sound ridiculous at first, given that the text easily fits on less > than 10 pages in font size, but bear with me. > > I was proposing an LC for it to Kevin, because the protocol IMO is rather > mature, but then I realized that we

Re: [Standards] XMPP Council Minutes 2018-12-19

> On 20 Dec 2018, at 20:27, Tedd Sterr wrote: > > http://logs.xmpp.org/council/2018-12-19/#16:00:41 > > > 1) Who's Here? > Present: Jonas, Georg, Dave, Link > Fashionably late: Kev (I did send tentative apologies in case I didn’t make it).

Re: [Standards] Server status pages

On 3 Dec 2018, at 10:02, Matthew Wild wrote: > > Hi all, > > I'd like to allow servers to advertise status pages to their users. > See for example https://statut.jabberfr.org/ > > This information could be cached by clients, and linked to in case of > problems connecting, for example. > > The

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

On 30 Nov 2018, at 07:54, Daniel Gultsch wrote: > > Am Fr., 30. Nov. 2018 um 08:29 Uhr schrieb Kevin Smith <mailto:kevin.sm...@isode.com>>: >> >> On 29 Nov 2018, at 20:41, Daniel Gultsch wrote: >>> >>> Hi Steve, >>> >

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

On 29 Nov 2018, at 20:41, Daniel Gultsch wrote: > > Hi Steve, > > Am Do., 29. Nov. 2018 um 20:22 Uhr schrieb Steve Kille > : >> First, the Avatar for a MIX channel is an associated with the channel, not >> with individual participants. So an XSF MIX channel might have an XMPP logo >> as the

Re: [Standards] LAST CALL: XEP-0359 (Unique and Stable Stanza IDs)

On 20 Oct 2018, at 12:51, Jonas Schäfer (XSF Editor) wrote: > > This message constitutes notice of a Last Call for comments on > XEP-0359. > > Title: Unique and Stable Stanza IDs > Abstract: > This specification describes unique and stable IDs for messages. > > URL:

Re: [Standards] LAST CALL: XEP-0357 (Push Notifications)

On 20 Oct 2018, at 12:51, Jonas Schäfer (XSF Editor) wrote: > This message constitutes notice of a Last Call for comments on > XEP-0357. > > Title: Push Notifications > Abstract: > This specification defines a way for an XMPP servers to deliver > information for use in push notifications to

Re: [Standards] XMPP Council Minutes 2018-08-01

On 6 Aug 2018, at 16:25, Tedd Sterr wrote: > > http://logs.xmpp.org/council/2018-08-01/#14:59:59 > > 1) Roll Call > Present: Sam, Dave, Kev, Georg > Pursuing business interests in the Middle Kingdom: Daniel > > 2) Agenda Bashing > No agenda changes; Georg liked it, but didn't put a ring on it.

Re: [Standards] Exact hint for Result Set Management

On 12 Jul 2018, at 11:23, Matthew Wild wrote: > > On 11 July 2018 at 18:25, Florian Schmaus wrote: >> On 11.07.2018 18:01, Matthew Wild wrote: >>> On 11 July 2018 at 16:33, Florian Schmaus wrote: I recently submitted PR #672 to the xeps repo https://github.com/xsf/xeps/pull/672

Re: [Standards] XEP-0045: How to signal tombstones for destroyed rooms?

On 11 Jul 2018, at 03:02, Kim Alvefur wrote: > > Hello list, > > I have implemented tombstones for destroyed MUC rooms. My reading of the > sacred texts did not give me enlightenment as how to inform someone > who's attempting to enter the remains of such a place. I've so far opted > to return

Re: [Standards] the meaning of "MUST be empty"

ld be appreciated, thank you. I think your suggested text encapsulates what the original text was trying to say. /K > > BG > > On 19/06/2018 14:26, Kevin Smith wrote: >> On 19 Jun 2018, at 13:13, Guus der Kinderen >> mailto:guus.der.kinde...@gmail.com>> wrote:

Re: [Standards] the meaning of "MUST be empty"

On 19 Jun 2018, at 12:09, Bartłomiej Górny wrote: > > Hi > > If a XEP states that an attribute "MUST be empty", does it mean that it: > a) must be present and have a value "" > b) must not be there > c) can be either of the two > > The question arose because of XEP-0313, which in point 5.1.2

Re: [Standards] Business rules of Last Message Correction

On 11 Jun 2018, at 15:20, Sam Whited wrote: > > On Mon, Jun 11, 2018, at 09:15, Kevin Smith wrote: >> I’m not sure that’s necessary, given that the current protocol was >> designed to allow exactly this. > > Was it? I was reading this whole conversation in the c

Re: [Standards] Business rules of Last Message Correction

On 11 Jun 2018, at 15:11, Sam Whited wrote: > > On Mon, Jun 11, 2018, at 09:02, Tedd Sterr wrote: >> As long as it doesn't confuse existing implementations, hopefully >> nothing; but I suppose that's what the namespace bump is for. > > It sounded to me like this would be a new distinct

Re: [Standards] Business rules of Last Message Correction

On 11 Jun 2018, at 13:52, Tedd Sterr wrote: > and add deletion too (functionally, replacing the message with "This message > was deleted.", but semantically different from literally replacing the > message with that text.) Is that essentially

Re: [Standards] Business rules of Last Message Correction

On 11 Jun 2018, at 13:52, Tedd Sterr wrote: > > I have considered this issue previously and concluded that, while there > appears to be no technical reason to disallow correcting older messages, > (some) current implementations only support correction of the last message > (in line with this

Re: [Standards] XMPP Council Agenda 2018-06-06

On 6 Jun 2018, at 01:35, Tedd Sterr wrote: > > 2) Isn't it nice that Tedd Sterr does the minutes? > > Come on, you need a new joke now - this one started wearing thin weeks ago  How well do you know Dave? :) /K ___ Standards mailing list Info:

Re: [Standards] Should we move Nicks out of MIX-CORE?

On 4 Jun 2018, at 20:18, Steve Kille wrote: > From: Standards On Behalf Of Dave Cridland >> Sent: 04 June 2018 20:06 >> To: XMPP Standards >> Subject: Re: [Standards] Should we move Nicks out of MIX-CORE? >> >> Nicknames are what users use to refer to each other. If, in a channel, I >> say,

Re: [Standards] Addressing for IQs in MIX-CORE

On 4 Jun 2018, at 16:28, Florian Schmaus wrote: > > On 04.06.2018 16:43, Jonas Wielicki wrote: >> A random side note: I found another argument against the variant where the >> client resource is encoded together with the participant id in the resource: >> The client resource is -- in contrast

Re: [Standards] Addressing for IQs in MIX-CORE

On 4 Jun 2018, at 16:03, Dave Cridland wrote: > On 4 June 2018 at 14:37, Kevin Smith wrote: >> On 4 Jun 2018, at 12:15, Dave Cridland wrote: >> >> >> >> >> >> >> >> On 4 June 2018 at 11:37, Steve Kille wrote: >> >&g

Re: [Standards] Addressing for IQs in MIX-CORE

On 4 Jun 2018, at 12:15, Dave Cridland wrote: >> >> >> >> On 4 June 2018 at 11:37, Steve Kille wrote: >> >> To support IQs in MIX-CORE, there needs to be an addressing and routing >> scheme. >> >> I am proposing that this uses a different scheme to messages from the >> channel (this is

Re: [Standards] Requirements for "Jid Hidden" Channels

On 2 Jun 2018, at 17:36, Steve Kille wrote: > It is clear that much of the complexity around JID encoding that is being > postulated as necessary, ties back to requirements to support participant > communication through JID Hidden channels. > > This note is to step back from the JID discussion,

Re: [Standards] Per Channel Nicks vs Global Nicks

On 3 Jun 2018, at 17:13, Steve Kille wrote: > > Daniel, > >> -Original Message- >> From: Standards On Behalf Of Daniel Gultsch >> Sent: 03 June 2018 08:29 >> To: XMPP Standards >> Subject: Re: [Standards] Another proposal - Handling JIDs for MIX-CORE, MIX- >> PRESENCE and MIX-PAM >>

Re: [Standards] Another proposal - Handling JIDs for MIX-CORE, MIX-PRESENCE and MIX-PAM

On 3 Jun 2018, at 00:33, Steve Kille wrote: > Sam's message made me realize that none of the variant 1/2/3/4 stuff is > needed for MIX-CORE. I’m not at all convinced that this is true. Anything that relies directly on real-JID routing is breaking PMs, and I don’t think disallowing PMs in

Re: [Standards] Using route-able JIDs in MIX-CORE

> On 3 Jun 2018, at 17:32, Steve Kille wrote: > > > >> -Original Message- >> From: Standards On Behalf Of Florian >> Schmaus >> Sent: 03 June 2018 17:27 >> To: XMPP Standards >> Subject: Re: [Standards] Using route-able JIDs in MIX-CORE >> >> On 03.06.2018 18:01, Steve Kille

Re: [Standards] Using route-able JIDs in MIX-CORE

On 3 Jun 2018, at 17:27, Florian Schmaus wrote: > 3.) IQ requests usually send to / received from > channel@mix.service/stable-participant-id/client-id > > To allow us to address a particular client for IQ exchange. (We could > add IQ semantics for channel@mix.service/stable-participant-id later

Re: [Standards] Using route-able JIDs in MIX-CORE

On 3 Jun 2018, at 17:01, Steve Kille wrote: > > Flo, > >>> That very much looks like that I would currently favour, besides that >>> I don't see a reason why we shouldn't also use the stable participant >>> identifier as the resourcepart of the originating address. >> >> Uh, and I slightly

Re: [Standards] Should we move Nicks out of MIX-CORE?

On 3 Jun 2018, at 17:22, Steve Kille wrote: >> As far as I understood nicknames are already optional in current MIX. If >> that's >> the case, then it should be moved out of MIX-CORE. > [Steve Kille] > > We do not fundamentally need Nicks to be in MIX-CORE. We do not *fundamentally* need

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

On 2 Jun 2018, at 13:01, Florian Schmaus wrote: > > On 02.06.2018 13:46, Kevin Smith wrote: >>> On 2 Jun 2018, at 11:44, Florian Schmaus wrote: >>> I think I'm currently in the >>> - messages from channel@service/nick >>> - IQs to/from and presence from

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

On 2 Jun 2018, at 09:25, Steve Kille wrote: > > We've been talking about a number of variants to deal with the problem of > encoding four pieces of information in a JID structure that only allows > encoding of three. > > Here is an approach to avoid the problem. > > These JIDs are mostly

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

> On 2 Jun 2018, at 11:44, Florian Schmaus wrote: > > On 02.06.2018 10:25, Steve Kille wrote: >> We've been talking about a number of variants to deal with the problem of >> encoding four pieces of information in a JID structure that only allows >> encoding of three. >> >> Here is an approach

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

On 2 Jun 2018, at 10:22, Steve Kille wrote: > >>> The only problem to address is when in a JID Hidden channel, the recipient >>> wants to address a specific client (PM or vCard lookup). A solution here is >>> to is to use the channel@domain/stable-participant-id addressing to the >>> channel,

Re: [Standards] MIX - an approach to JIDs that avoids the four into three problem

On 2 Jun 2018, at 09:25, Steve Kille wrote: > > We've been talking about a number of variants to deal with the problem of > encoding four pieces of information in a JID structure that only allows > encoding of three. > > Here is an approach to avoid the problem. > > These JIDs are mostly

Re: [Standards] MIX Addressing

On 1 Jun 2018, at 17:19, Florian Schmaus wrote: > > On 01.06.2018 17:57, Kevin Smith wrote: >> On 1 Jun 2018, at 16:47, Florian Schmaus wrote: >>> >>> On 31.05.2018 13:45, Kevin Smith wrote: >>>> We’ve had some discussions recently about whether pre

Re: [Standards] MIX Addressing

On 1 Jun 2018, at 16:47, Florian Schmaus wrote: > > On 31.05.2018 13:45, Kevin Smith wrote: >> We’ve had some discussions recently about whether presence should come from >> the channel’s JID, the user’s proxy JID, or be encoded in pubsub. Similarly >> whether messag

Re: [Standards] MIX Addressing

On 1 Jun 2018, at 11:37, Steve Kille wrote: > 1. Use variant 2 for messages.Messages will come from bare JID of > channel, with resource being stable ID indicating the sender. Sender JID > and Nick in the message.This works right for MAM, and I think it is > reasonably natural for

Re: [Standards] MIX Addressing

> On 1 Jun 2018, at 09:36, Jonas Wielicki wrote: > > On Freitag, 1. Juni 2018 09:21:45 CEST Kevin Smith wrote: >> On 31 May 2018, at 20:12, Jonas Wielicki wrote: >>> On Donnerstag, 31. Mai 2018 13:45:06 CEST Kevin Smith wrote: >>>> We’ve had some discuss

Re: [Standards] MIX Addressing

On 1 Jun 2018, at 09:20, Jonas Wielicki wrote: > > On Freitag, 1. Juni 2018 09:29:15 CEST Kevin Smith wrote: >>> So here’s a straw-man proposal, Variant 3 (because, creating many variants >>> is what we’re good at!): >>> >>> An occupant is identified b

Re: [Standards] MIX Addressing

> On 31 May 2018, at 21:43, Jonas Wielicki wrote: > > On Donnerstag, 31. Mai 2018 13:45:06 CEST Kevin Smith wrote: >> 1) Stick with proxy JIDs and user%channel@domain[/resource] (or similar), >> with the resource missed off for bare-JID traffic, where >> ‘user%chann

Re: [Standards] MIX Addressing

On 31 May 2018, at 20:12, Jonas Wielicki wrote: > > On Donnerstag, 31. Mai 2018 13:45:06 CEST Kevin Smith wrote: >> We’ve had some discussions recently about whether presence should come from >> the channel’s JID, the user’s proxy JID, or be encoded in pubsub. Similarly &

[Standards] MIX Addressing

We’ve had some discussions recently about whether presence should come from the channel’s JID, the user’s proxy JID, or be encoded in pubsub. Similarly whether messages should be coming from the channel’s JID or the user’s proxy JID. I think the argument that things should come from the user’s

Re: [Standards] [Council] XMPP Council Agenda 2018-05-30

Sure. Thanks for the agendumas. /K > On 30 May 2018, at 14:53, Dave Cridland wrote: > > I'm unfortunately unable to attend this week; could someone else chair the > meeting? > > On 30 May 2018 at 14:51, Dave Cridland wrote: > Folks, > > The XMPP Council will be holding it's regular meeting

Re: [Standards] Proposed XMPP Extension: Best practices for GDPR compliant deployment of XMPP

On 25 May 2018, at 22:07, Dave Cridland wrote: > Since we're sitting on this for a bit, I'm curious as to what the concerns > with the XSF offering anything that might be considered "legal advice" > actually are. > > I'm aware there's always been a lot of "IANAL" around on mailing lists, but

<    1   2   3   4   5   6   7   8   9   10   >