Re: [Standards] XEP-0313: Treatment of type=groupchat in user archive with or without hint

> On 23 Nov 2017, at 22:18, Matthew Wild <mwi...@gmail.com> wrote: > > On 23 November 2017 at 18:33, Daniel Gultsch <dan...@gultsch.de> wrote: >> 2017-11-23 18:33 GMT+01:00 Kevin Smith <kevin.sm...@isode.com>: >>> The main use case for having gc message

Re: [Standards] XEP-0313: Treatment of type=groupchat in user archive with or without hint

On 23 Nov 2017, at 17:11, Daniel Gultsch wrote: > > Hi, > > today I stumbled over an interesting behaviour of ejabberd MAM implementation. > While ejabberd usually does not store messages of type groupchat into > the users archive (ignoring the »A server SHOULD also include

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

> On 14 Nov 2017, at 21:37, Sam Whited wrote: > >> On Tue, Nov 14, 2017, at 12:06, Dave Cridland wrote: >> So arguing over whether it's a Core, Advanced, or neither feature >> seems a bit pointless - except that it means XEP-0387 may reflect >> neither the current reality

Re: [Standards] Problems with IM Message Routing: Message Types

On 11 Nov 2017, at 11:04, Georg Lukas wrote: > > * Florian Schmaus [2017-11-10 21:54]: >>> - bare-JID = all-clients + archive >>> - full-JID = single client, no carbons, no archive, no redirection >> >> Which rules of RFC 6121 do you exactly need/want to bend

Re: [Standards] Problems with IM Message Routing: Message Types

On 11 Nov 2017, at 11:01, Georg Lukas <ge...@op-co.de> wrote: > > * Kevin Smith <kevin.sm...@isode.com> [2017-11-10 21:31]: >> I don’t think this needs a new session type. It would be sufficient to >> enable these rules when clients enable ‘mamsub’ (for want

Re: [Standards] Problems with IM Message Routing: Message Types

On 10 Nov 2017, at 19:57, Georg Lukas wrote: > > Hi, > > Hello, this is part 3 of the thread about how broken XMPP is > , > today we are going to cover Message Types. > > There are five different well-defined

Re: [Standards] Renaming XEP status 'Draft' to 'Stable'

On 1 Nov 2017, at 14:30, Peter Saint-Andre wrote: > As to the second point, it would be good to define more objective > criteria for advancement (e.g., no significant changes in 12 months, > widespread implementation and deployment, no known security issues). I’m not sure

Re: [Standards] Renaming XEP status 'Draft' to 'Stable'

On 1 Nov 2017, at 12:40, Matthew Wild wrote: > > On 1 November 2017 at 12:35, Matthew Wild wrote: >> As such, I've prepared a change of XEP-0001 here: >> https://github.com/mwild1/xeps/commit/9cebf36e11d5918352b49c1a3e27fec2f17d8005 > > Without my Board hat

Re: [Standards] Renaming XEP status 'Draft' to 'Stable'

On 1 Nov 2017, at 12:35, Matthew Wild wrote: > > Guus der Kinderen recently sparked a discussion about revising our XEP > statuses for better clarity about their intention (thread at > https://mail.jabber.org/pipermail/standards/2017-September/033441.html > ). > > Although the

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

> On 27 Oct 2017, at 12:19, Florian Schmaus wrote: > > On 16.10.2017 20:38, Jonas Wielicki (XSF Editor) wrote: >> This message constitutes notice of a Last Call for comments on >> XEP-0313. >> >> Abstract: >> This document defines a protocol to query and control an archive

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

On 26 Oct 2017, at 09:58, Jonas Wielicki wrote: > > On Montag, 16. Oktober 2017 18:38:45 CEST Jonas Wielicki wrote: >> This message constitutes notice of a Last Call for comments on >> XEP-0313. >> >> Abstract: >> This document defines a protocol to query and control an

Re: [Standards] 2017-10-25 XSF Council Minutes

Thanks for the minutes, sorry to quibble. > On 25 Oct 2017, at 16:57, JC Brand wrote: > With 3 (+1) votes and 2 (-1) votes the council has decided to change the state > of XEP-0071: XHTML-IM to Deprecated This isn’t quite right. The requirement is a majority of Council being

Re: [Standards] IM Message Routing 2: Device Identity

On 24 Oct 2017, at 08:01, Evgeny Khramtsov <xramt...@gmail.com> wrote: > > Mon, 23 Oct 2017 10:11:54 +0100 > Kevin Smith <kevin.sm...@isode.com> wrote: > >> bin it and trust the new value > > No. Let's imagine a situation: a cluster with 2 nodes, there is

Re: [Standards] IM Message Routing 2: Device Identity

On 18 Oct 2017, at 19:46, Evgeny Khramtsov <xramt...@gmail.com> wrote: > > Wed, 18 Oct 2017 16:43:54 +0100 > Kevin Smith <kevin.sm...@isode.com> wrote: > >> It’s much easier to keep a global lookup table if you don’t have to >> deal with conflicts becau

Re: [Standards] Time-bound unsubscription from presence info of particular users

On 20 Oct 2017, at 14:47, vaibhav singh wrote: > > > > On Fri, Oct 20, 2017 at 5:23 PM, Kim Alvefur > wrote: > Hi! > > (shortened) > > On Fri, Oct 20, 2017 at 04:01:31PM +0530, vaibhav singh wrote: > > a person who was

Re: [Standards] IM Message Routing 2: Device Identity

Thanks again. On 11 Oct 2017, at 18:14, Georg Lukas wrote: > 1. Resource identifiers in the JID > > Those are unique, so a server must either kill the old session or refuse > the new session on conflict. IMO clients that create a randomized > resource string on account setup, or

Re: [Standards] A Quick and Dirty design for "Snippets"

On 16 Oct 2017, at 10:09, Dave Cridland <d...@cridland.net> wrote: > > On 16 October 2017 at 10:03, Kevin Smith <kevin.sm...@isode.com> wrote: >> It’s certainly the path of least resistance for web clients. I’m somewhat >> concerned that >> a) “anything

Re: [Standards] A Quick and Dirty design for "Snippets"

On 16 Oct 2017, at 09:58, Dave Cridland <d...@cridland.net> wrote: > On 15 October 2017 at 11:22, Kevin Smith <kevin.sm...@isode.com> wrote: >> On 15 Oct 2017, at 10:03, Dave Cridland <d...@cridland.net> wrote: >>> I'm just polling for interest; I said I'd

Re: [Standards] A Quick and Dirty design for "Snippets"

On 15 Oct 2017, at 10:03, Dave Cridland wrote: > I'm just polling for interest; I said I'd write this up properly > elsewhere, but is there interest in the following: Yes > A Snippet is a small item of content. It is normally referenced within > a chatroom or 1:1 chat. I'm

Re: [Standards] Security issues with XHTML-IM (again)

> On 13 Oct 2017, at 09:42, Dave Cridland <d...@cridland.net> wrote: > > On 13 October 2017 at 09:20, Kevin Smith <kevin.sm...@isode.com> wrote: >> On 12 Oct 2017, at 21:22, Dave Cridland <d...@cridland.net> wrote: >>> I hereby promise a concrete propos

Re: [Standards] Security issues with XHTML-IM (again)

On 12 Oct 2017, at 21:22, Dave Cridland wrote: > I hereby promise a concrete proposal on > these - it ought to handle a few other cases too. Ta, I think that’s needed for the discussion. One issue here is that I think Sam’s argument is that it’s 1) too tempting, for

Re: [Standards] XEP-0045 MUC: am I still there?

On 5 Oct 2017, at 12:51, Kim Alvefur <z...@zash.se> wrote: > > On Thu, Oct 05, 2017 at 12:20:12PM +0100, Kevin Smith wrote: >> >>> On 5 Oct 2017, at 11:39, Jonas Wielicki <jo...@wielicki.name> wrote: >>> >>> On Mittwoch, 4. Oktober 2

Re: [Standards] XEP-0199: XMPP Ping - question on ping timeout

On 5 Oct 2017, at 10:54, Florian Schmaus <f...@geekplace.eu> wrote: > > On 05.10.2017 11:20, Kevin Smith wrote: >> I’m not sure that the sides need to agree on timeouts. As long as each side >> does sensible pinging (only when the stream is silent) and not blindly every

Re: [Standards] XEP-0045 MUC: am I still there?

> On 5 Oct 2017, at 11:39, Jonas Wielicki <jo...@wielicki.name> wrote: > > On Mittwoch, 4. Oktober 2017 21:19:33 CEST Kevin Smith wrote: >>>> I think >>>> that “presence things with magic side effects” is one of the problems we >>>> have with MU

Re: [Standards] XEP-0199: XMPP Ping - question on ping timeout

On 5 Oct 2017, at 07:26, vaibhav singh wrote: > >> >> >> On Wed, Oct 4, 2017 at 4:38 PM, Florian Schmaus wrote: >> On 04.10.2017 07:34, Georg Lukas wrote: >> > * vaibhav singh [2017-10-03 15:45]: >> >> After Service

Re: [Standards] XEP-0045 MUC: am I still there?

> On 4 Oct 2017, at 16:41, Jonas Wielicki <jo...@wielicki.name> wrote: > > On Mittwoch, 4. Oktober 2017 16:08:43 CEST Kevin Smith wrote: >>> On 4 Oct 2017, at 14:07, Georg Lukas <ge...@op-co.de> wrote: >>> >>> Hi Kev, >>> &g

Re: [Standards] XEP-0045 MUC: am I still there?

> On 4 Oct 2017, at 14:07, Georg Lukas <ge...@op-co.de> wrote: > > Hi Kev, > > * Kevin Smith <kevin.sm...@isode.com> [2017-10-04 11:43]: >> Thanks for the write-up. I agree this is a problem worth solving. > > Thanks for the feedback! > >&g

Re: [Standards] Problems with IM Message Routing

On 4 Oct 2017, at 07:01, Georg Lukas wrote: > there is a number of open issues with how message routing currently > works for the IM use case, and where it doesn't work consistently > because of different patches (Carbons, MAM) that we have applied over > time to modernize it. >

Re: [Standards] XEP-0045 MUC: am I still there?

On 4 Oct 2017, at 09:19, Georg Lukas wrote: > > Hi, > > TL;DR: checking if you are still in a MUC is broken and needs to be > fixed, either with new IQs or with a new rejoin-if-needed presence. > > > MUC presence tends to break > === > > Most of us

Re: [Standards] XEP-0163: depend on persistent-items, node-config and publish-options

On 29 Aug 2017, at 13:27, Kim Alvefur wrote: > > On Mon, Aug 28, 2017 at 12:03:37PM +0200, Daniel Gultsch wrote: >> Now that the PR regarding publish-options has been merged into >> XEP-0060 I want to bump this thread and ask if anyone objects to that >> proposal (making

Re: [Standards] Rename XEP status identifiers

On 27 Sep 2017, at 15:08, Sam Whited <s...@samwhited.com> wrote: > > On Wed, Sep 27, 2017, at 02:08, Kevin Smith wrote: >> Are they not then going to be upset if there are backwards-incompatible >> changes in a new namespace? We try not to do that in Draft XEPs, but >

Re: [Standards] Rename XEP status identifiers

On 26 Sep 2017, at 20:35, Sam Whited wrote: > > On Tue, Sep 26, 2017, at 14:19, Ivan Vučica wrote: >> And now, to bikeshed a bit on the proposed naming: To a casual reader, >> stable has similar implications as final. Especially if said reader is >> used to Debian's use of

Re: [Standards] Reputation system for XMPP

On 5 Sep 2017, at 02:46, Peter Saint-Andre wrote: > > On 9/3/17 11:53 PM, Evgeny Khramtsov wrote: >> Sun, 3 Sep 2017 17:07:32 -0600 >> Peter Saint-Andre wrote: >> >>> Before we spend energy on building a reputation system, it would be >>> good to

Re: [Standards] TOTP and enforced password changes in SASL2

On 24 Aug 2017, at 16:56, Dave Cridland wrote: > Moreover, SASL2 is designed to handle a lot more than just TOTP etc - > we can merge in resource binding without any additional round-trips, > for example, if I can ever persuade Kev to see things my way. So it's > more

Re: [Standards] XEP-0234: Denote used hash function in session-initiate

On 17 Aug 2017, at 21:23, Paul Schaub wrote: > > Hi! > > I stumbled across another inconvenience in the Jingle File Transfer XEP: > > The session-initiate MIGHT contain a hash-element which contains the > checksum of the file. Alternatively the hash-element can also be

Re: [Standards] XEP-0357: Adding last-message-priority

Just a holding message that I’ve seen this thread is in my inbox and I need to read/reply - I’ve just not got down to it yet. /K > On 28 Jul 2017, at 02:23, Chris Ballinger wrote: > > This adds an optional "high" and "low" priority value, where "high" depends > on

Re: [Standards] length of time in ProtoXEP state

On 22 Jun 2017, at 22:23, Dave Cridland wrote: > > On 22 June 2017 at 21:49, Sam Whited wrote: >> On Thu, Jun 22, 2017 at 3:30 AM, Dave Cridland wrote: >>> If it really is the name, then let's call it "Stable". >> >> I actually do

Re: [Standards] OMEMO Discussion Summary 2017

On 21 Jun 2017, at 18:03, Daniel Gultsch wrote: > > 2017-06-21 18:58 GMT+02:00 Daniel Gultsch : >> I think the meaning of that compromise is overstated. >> The main reason for doing this is that we have a stable version which >> can be addressed and linked

Re: [Standards] length of time in ProtoXEP state

On 21 Jun 2017, at 16:47, Daniel Gultsch wrote: > > The problem here is that XEPs usually don't move up the ranks as it is > intended by XEP-0001. We have countless - very essential - stuck in > very low ranks like experimental and draft. This leads to developers >

Re: [Standards] OMEMO Discussion Summary 2017

On 21 Jun 2017, at 15:47, Peter Saint-Andre wrote: > > Thanks for the summary, Tobias! > > On 6/21/17 8:35 AM, Tobias Markmann wrote: > > >> With that, the media and client developers can point to the version of >> XEP-0384 that is currently widely implemented and the XSF

Re: [Standards] Dealing with the choice to have a different MIX roster format

On 15 Jun 2017, at 15:30, Steve Kille wrote: > > > >>> >>> >> id='bv1bs71f' >>> type='get'> >>> >>> >>> >>> >> >> I'd also s/mix-info-request/mix/. >> > [Steve Kille] > > is already used to encode MIX extension to a

Re: [Standards] (MIX) - When to increment Namespace

On 14 Jun 2017, at 12:30, Dave Cridland wrote: > A sticking point I have, however, is that the specification should > update as needed to match our current consensus - holding back changes > outside of the XSF is problematic, and while one might argue that > "everyone knows"

Re: [Standards] XEP-0369 (MIX): When to deliver messages to a client

On 14 Jun 2017, at 09:02, Kevin Smith <kevin.sm...@isode.com> wrote: > > On 14 Jun 2017, at 08:53, Kevin Smith <kevin.sm...@isode.com> wrote: >> >> On 14 Jun 2017, at 08:23, Steve Kille <steve.ki...@isode.com> wrote: >>> >>> Jonas, >

Re: [Standards] XEP-0369 (MIX): When to deliver messages to a client

On 14 Jun 2017, at 08:53, Kevin Smith <kevin.sm...@isode.com> wrote: > > On 14 Jun 2017, at 08:23, Steve Kille <steve.ki...@isode.com> wrote: >> >> Jonas, >> >>> >>> From <https://github.com/xsf/xeps/compare/ >>>

Re: [Standards] XEP-0369 (MIX): When to deliver messages to a client

On 14 Jun 2017, at 08:23, Steve Kille wrote: > > Jonas, > >> >> From > master...stevekille:MIX#diff-46551996fe454185b68cb3f084c2e18fR2426>: >> >>> The server receiving the message will then deliver the messages to all >>> online

Re: [Standards] XEP-0369 (MIX): Early stages of a clients connection

On 14 Jun 2017, at 08:36, Steve Kille wrote: >> One thing I could imagine is for the server to include that information in >> the >> roster version. E.g. if it usually versions the roster with incrementing >> numbers, it could add "+mix" to the stringified number if MIX

Re: [Standards] (MIX) - When to increment Namespace

On 14 Jun 2017, at 08:31, Jonas Wielicki wrote: > > On Mittwoch, 14. Juni 2017 08:12:06 CEST Steve Kille wrote: >> Jonas, >> I have not pushed as a PR because of namespace numbering. It seems likely that if a change is pushed every time we make a protocol

Re: [Standards] Dealing with the choice to have a different MIX roster format

On 14 Jun 2017, at 08:24, Jonas Wielicki <jo...@wielicki.name> wrote: > > Replies to both Kevin and Steve inline. > > On Mittwoch, 14. Juni 2017 08:11:08 CEST Kevin Smith wrote: >> On 14 Jun 2017, at 08:04, Steve Kille <steve.ki...@isode.com> wrote: > [snip] &g

Re: [Standards] (MIX) - When to increment Namespace

On 14 Jun 2017, at 08:12, Steve Kille wrote: > > Jonas, > >> >>> I have not pushed as a PR because of namespace numbering. It seems >>> likely that if a change is pushed every time we make a protocol tweak, >>> there is going to be a serious problem of namespace

Re: [Standards] Dealing with the choice to have a different MIX roster format

On 14 Jun 2017, at 08:04, Steve Kille wrote: > > Jonas, > > Thanks for the clarification here. > >> -Original Message- >> From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Jonas >> Wielicki >> Sent: 14 June 2017 07:23 >> To: XMPP Standards >>

Re: [Standards] XEP Authors

On 9 Jun 2017, at 14:08, Peter Saint-Andre wrote: > > On 6/9/17 5:37 AM, Philipp Hancke wrote: >>> However, I don't think this is particularly contentious. We have lots >>> of documents for which one of the "Authors" hasn't made any input for >>> several revisions. >> >>

Re: [Standards] XEP Authors

On 9 Jun 2017, at 11:41, Dave Cridland wrote: > However, I don't think this is particularly contentious. > I see, on the other hand, no advantage to *not* having a Previous > Authors section This seems like a sensible change to me, whether driven by Dave’s non-lawyerness or

Re: [Standards] XEP-0280 (Carbons) proposals

On 2 Jun 2017, at 08:59, Dave Cridland wrote: > > On 1 June 2017 at 12:51, Georg Lukas wrote: >>> Requiring servers to implement particular delivery rules: >>> https://github.com/xsf/xeps/commit/9c388a51c61541507c599832038b6562f3d01841 >>> >>> I don’t think

Re: [Standards] Don't let today be the day we bury OMEMO

> On 7 Jun 2017, at 22:15, Ignat Gavrilov wrote: > > Before anyone (including me) gets outrageous here, I wonder what this > compromise is exactly: > > a) The OMEMO-siacs is put into the/a XEP and all future standardizing work is > put into OMEMO-NEXT (not

Re: [Standards] Don't let today be the day we bury OMEMO

On 7 Jun 2017, at 21:49, Vanitas Vitae wrote: > I agree. Its not exactly nice to deny the existing implementations the > name OMEMO, since those implementations are what gave OMEMO its > reputation, so could we please agree on the fact, that existing > implementations are

Re: [Standards] Don't let today be the day we bury OMEMO

On 7 Jun 2017, at 21:46, Ignat Gavrilov <ignat.gavri...@mailfence.com> wrote: >> From: Kevin Smith <kevin.sm...@isode.com> >> I can understand that argument, but I think a lot of people want to have the >> currently deployed thing-that-isn’t-OMEMO (OMEMO-siac

Re: [Standards] Don't let today be the day we bury OMEMO

On 7 Jun 2017, at 21:00, Ignat Gavrilov wrote: > IMHO a new encryption scheme change should be a new XEP or this will confuse > users even more I can understand that argument, but I think a lot of people want to have the currently deployed thing-that-isn’t-OMEMO

Re: [Standards] Don't let today be the day we bury OMEMO

Hi Ignat, > On 7 Jun 2017, at 19:22, Ignat Gavrilov wrote: > Just that I understand this topic correctly: > The intention is to put the currently implemented OMEMO (a.k.a. siacs OMEMO) > into the XEP and then no longer update that XEP and put all effort into >

Re: [Standards] Don't let today be the day we bury OMEMO

Hi Flo, This feels somewhat like trying to torpedo the current compromise that’s on the table, so I’d like to make some comments. On 7 Jun 2017, at 14:48, Florian Schmaus wrote: > The council will likely soon [1] decide if the currently used OMEMO > protocol will be

Re: [Standards] OMEMO Key Agreement

> On 2 Jun 2017, at 11:57, Daniel Gultsch <dan...@gultsch.de> wrote: > > 2017-06-01 13:12 GMT+02:00 Kevin Smith <kevin.sm...@isode.com>: >> On 1 Jun 2017, at 11:22, Daniel Gultsch <dan...@gultsch.de> wrote: >>> I went ahead an created a PR for XEP-0384

Re: [Standards] OMEMO Key Agreement

Hi Daniel, On 1 Jun 2017, at 11:22, Daniel Gultsch wrote: > I went ahead an created a PR for XEP-0384 to match what is actually > implemented in the wild. > ... > I changed the track from Standards to Historical. > I checked: Track changes have happened before and are

[Standards] XEP-0280 (Carbons) proposals

Hi all, I promised to review and start a thread on the pending PR for Carbons updates ( https://github.com/xsf/xeps/pull/434 ), so here we are. Removing no-copy: https://github.com/xsf/xeps/commit/aac8f94b0df64b250f7d5320d9f2e5e76b38d2ff I think this goes beyond just removing no-copy, and makes

Re: [Standards] OMEMO Key Agreement

On 1 Jun 2017, at 06:03, Daniel Gultsch wrote: > > Hi, > > a lot of what Dave said about future proofing spoke to me and I'm > starting to think he (and the others) are right. > > It makes me wonder if we should work towards making OMEMO a good > standard for a more distant

Re: [Standards] [Council] Council Minutes 20150531

On 31 May 2017, at 17:21, Dave Cridland wrote: > 3) ODR / OMEMO https://trello.com/c/pxYjqmnR/182-odr-omemo > > Tobias asked whether the Council should accept ODR, or wait for the > OMEMO discussion to come to some conclusion, based on an agenda item > by Sam. Daniel said the

Re: [Standards] Delayed Delivery for CSI and possibly SM

On 30 May 2017, at 15:37, Daniel Gultsch <dan...@gultsch.de> wrote: > > 2017-05-30 16:28 GMT+02:00 Kevin Smith <kevin.sm...@isode.com>: >> On 30 May 2017, at 15:18, Daniel Gultsch <dan...@gultsch.de> wrote: >>> >>> 2017-05-30 16:02 GMT+02:00 Dave C

Re: [Standards] Delayed Delivery for CSI and possibly SM

On 30 May 2017, at 15:18, Daniel Gultsch wrote: > > 2017-05-30 16:02 GMT+02:00 Dave Cridland : >> Presence, mind, I'm not so sold on - I think it's significantly less >> important, since presence is stateful rather than an event. But I'm >> not averse to it

Re: [Standards] Delayed Delivery for CSI and possibly SM

On 30 May 2017, at 15:02, Dave Cridland <d...@cridland.net> wrote: > > On 30 May 2017 at 14:48, Kevin Smith <kevin.sm...@isode.com> wrote: >> On 30 May 2017, at 14:00, Daniel Gultsch <dan...@gultsch.de> wrote: >>> I noticed that some CSI implementations

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

On 26 May 2017, at 15:33, Kevin Smith <kevin.sm...@isode.com> wrote: > > On 26 May 2017, at 15:22, Sam Whited <s...@samwhited.com> wrote: >>> email is an issue of Editor tooling, rather than iteam, and we can resolve >>> that there. >> >> Is it

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

> On 26 May 2017, at 14:56, Kevin Smith <kevin.sm...@isode.com> wrote: > > On 26 May 2017, at 14:41, Sam Whited <s...@samwhited.com> wrote: >> >>>> Sam and Dave think it still involves manual steps. >>> >>> It does, as it has always

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

On 26 May 2017, at 14:41, Sam Whited wrote: > >>> Sam and Dave think it still involves manual steps. >> >> It does, as it has always done. > > Those manual steps have never involved being dependent on another team > though, which is the actual problem. Well, the good news

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

On 24 May 2017, at 14:48, Tobias Markmann wrote: > ## XSF Editor infrastructure state > > Tobias asks Sam (with his editor hat on) about the current state of XSF > Editor infrastructure and their ability to publish and otherwise process XEP > changes. Without this

Re: [Standards] Council Minutes 2017-05-24

On 24 May 2017, at 21:03, Dave Cridland wrote: > > On 24 May 2017 at 20:30, Evgeny Khramtsov wrote: >> Wed, 24 May 2017 21:24:40 +0200 >> Daniel Gultsch wrote: >> >>> The author is unresponsive and has been ignoring my feedback for

Re: [Standards] Push. Was Re: Council Minutes 2017-05-24

On 24 May 2017, at 20:34, Daniel Gultsch wrote: > > https://mail.jabber.org/pipermail/standards/2016-February/030925.html > > The follow up message from Holger (Timeout only starts after first > push-worthy stanza) is also important. > > We also came to the conclusion that

Re: [Standards] OMEMO and Olm

On 25 May 2017, at 10:01, Florian Schmaus wrote: > > On 25.05.2017 10:56, Dave Cridland wrote: >> On 25 May 2017 at 08:26, Florian Schmaus wrote: >>> On 25.05.2017 08:04, Remko Tronçon wrote: On 24 May 2017 at 22:55, Andreas Straub

[Standards] Push. Was Re: Council Minutes 2017-05-24

> On 24 May 2017, at 20:24, Daniel Gultsch wrote: > > 2017-05-24 21:16 GMT+02:00 Evgeny Khramtsov : >> Since we're discussing this: what about XEP-0357 (Push Notifications)? >> Is it gonna be deferred? What's its state? > > The author is unresponsive and

Re: [Standards] Proto-XEP: Pre-Authenticated Roster Subscription

On 10 May 2017, at 21:08, Sam Whited wrote: > > On Wed, May 10, 2017 at 2:29 PM, Daniel Gultsch wrote: >> IMHO the hypothetical service operators who maintain their own service which >> are self-branded are very welcome to step forward now and try to get

Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA

> On 30 Mar 2017, at 17:30, Florian Schmaus <f...@geekplace.eu> wrote: > > On 30.03.2017 18:24, Kevin Smith wrote: >> OMEMO’s initial publication was delayed for some time, in large part because >> of the need to move away from a situation where it can only be

Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA

On 30 Mar 2017, at 17:13, Florian Schmaus wrote: > > On 30.03.2017 18:02, Dave Cridland wrote: >> On 30 March 2017 at 16:00, Florian Schmaus wrote: >>> On 30.03.2017 15:54, Remko Tronçon wrote: On 30 March 2017 at 15:10, Andreas Straub

Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA

On 30 Mar 2017, at 14:10, Andreas Straub wrote: >> So, I'm wondering whether it wouldn't make more sense to not carry the >> Signal legacy around in OMEMO, use Ed25519 keys as identity keys, and >> adapt X3DH to use these for creating an initial shared secret (with the >> same

Re: [Standards] [Members] Server loss

On 29 Mar 2017, at 12:07, Daniel Pocock <dan...@pocock.pro> wrote: > > > > On 29/03/17 12:49, Kevin Smith wrote: >> Hi folks, >> >> As many of you will have noticed, we had a ‘minor issue’ with the server at >> the weekend. To cut a modera

[Standards] Server loss

Hi folks, As many of you will have noticed, we had a ‘minor issue’ with the server at the weekend. To cut a moderately long story short, there was a failure at the hosting provider, destroying the server that hosts the xmpp.org XMPP service, website, wiki, xmpp.net service, etc. etc. Because

Re: [Standards] MIX, MAM, jidmap, and Jid-Hidden

I’ve not done the research I should have before responding to this, so apologies if what I say is patently stupid. > On 15 Mar 2017, at 14:36, Dave Cridland wrote: >> On 15 March 2017 at 14:02, Steve Kille wrote: >> What you are suggesting here is that

Re: [Standards] XEP-0313: Storage Rules for Archives

On 30 Jan 2017, at 22:52, Tobias Kräntzer wrote: > > Hi, > > I searched the archive to see, if this has already been discussed recently, > but didn’t finde anything. Please bear with me, if this has been already > discussed too much. > > I’m recently implemented

Re: [Standards] XEP-0369: xmlns in disco#info feature elements

On 2 Mar 2017, at 21:02, Jonas Wielicki wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Donnerstag, 23. Februar 2017 08:05:23 CET XMPP Extensions Editor wrote: >> Version 0.8.1 of XEP-0369 (Mediated Information eXchange (MIX)) has been >> released. >>

Re: [Standards] Bind 2.0 and Best Practices for Handling Offline Messages interoperability

Hi Michal, On 24 Feb 2017, at 08:31, Michal Piotrowski wrote: > XEP-0386: Bind 2.0 spec says: > > > Clear the offline messages for this user, if any, without sending them (as > > they will be provided by MAM). > > XEP-0160: Best Practices for Handling

Re: [Standards] Resourceparts with Bind2

On 20 Feb 2017, at 16:12, Steve Kille wrote: >> Clients are going to need to use a consistent approach to globally unique >> naming. If they’re not unique then you’ll get collisions and all the >> benefits are >> lost. (And if they’re not consistent then they’ll be

Re: [Standards] Resourceparts with Bind2

> On 20 Feb 2017, at 12:42, Florian Schmaus <f...@geekplace.eu> wrote: > > On 20.02.2017 12:54, Kevin Smith wrote: >> Hi Flow, >> >> On 20 Feb 2017, at 11:28, Florian Schmaus <f...@geekplace.eu> wrote: >>> >>> On 20.02.2017 10:36, Geor

Re: [Standards] Example Resources in XEPs (XEP-0369)

Hi Flow, On 20 Feb 2017, at 11:28, Florian Schmaus wrote: > > On 20.02.2017 10:36, Georg Lukas wrote: >> * Jonas Wielicki [2017-02-20 10:20]: >>> I feel that using BIND2 resources---albeit this is likely to become the new >>> standard---harms

Re: [Standards] Improving Usability of XMPP Clients from the Bottom - Usability Considerations

On 8 Feb 2017, at 22:11, Tobias M wrote: > To improve the overall usability of XMPP software, I want authors to consider > how the protocols they design might be implemented, and how their protocol > influences the usability. Some examples for this are: > > *

Re: [Standards] Summit MIX Decsions

On 8 Feb 2017, at 15:16, Sam Whited wrote: > > On Wed, Feb 8, 2017 at 3:32 AM, Steve Kille wrote: >> 9. It is agreed that MIX Channels will be represented in the roster. >> >> >> 10. It is intended to mark MIX clients in the roster with a server

Re: [Standards] RFC 6120 vs. Bind2 XEP (was: CSI and Carbons state after SM resumption)

> On 6 Feb 2017, at 14:53, Marvin Gülker wrote: > Someone creating a new XMPP client naturally starts by > implementing RFC 6120, only to discover that it is obsoleted by > practice. But they would still interoperate, because 6120 is the baseline. Bind2 is not the

Re: [Standards] CSI and Carbons state after SM resumption

On 6 Feb 2017, at 12:25, Evgeny Khramtsov <xramt...@gmail.com> wrote: > > Mon, 6 Feb 2017 12:03:15 +0000 > Kevin Smith <kevin.sm...@isode.com> wrote: > >> Nothing stops further specs from changing the core rules by >> negotiation. This is not a viol

Re: [Standards] CSI and Carbons state after SM resumption

On 6 Feb 2017, at 12:01, Evgeny Khramtsov wrote: > > Mon, 6 Feb 2017 12:44:49 +0100 > Florian Schmaus wrote: > >> Maybe I don't understand the question, but Bind2 still does resource >> binding. > > Yes, but in a different way. While RFC6120 tells how to

Re: [Standards] LAST CALL: XEP-0333 (Chat Markers)

> On 28 Jan 2017, at 17:25, XMPP Extensions Editor wrote: > > This message constitutes notice of a Last Call for comments on XEP-0333 (Chat > Markers). > > Abstract: This specification describes a solution of marking the last > received, displayed and acknowledged message in

Re: [Standards] Proposed XMPP Extension: Bind 2.0

On 25 Jan 2017, at 10:52, Kim Alvefur <z...@zash.se> wrote: > > On Wed, Jan 25, 2017 at 10:32:41AM +, Kevin Smith wrote: >> On 23 Jan 2017, at 15:38, Georg Lukas <ge...@op-co.de> wrote: >>> 3. Server performs magic: >>> >>> - if the

Re: [Standards] Proposed XMPP Extension: Bind 2.0

On 23 Jan 2017, at 15:38, Georg Lukas wrote: > > * XMPP Extensions Editor [2017-01-17 16:24]: >> Abstract: This specification provides a single-request replacement for >> several activities an XMPP client needs to do at startup. > > I know this is a bold

Re: [Standards] Proposed XMPP Extension: Bind 2.0

estions, please share. /K > > > Best regards > Michal Piotrowski > michal.piotrow...@erlang-solutions.com > > On 19 January 2017 at 12:05, Michal Piotrowski > <michal.piotrow...@erlang-solutions.com> wrote: > > On 19 January 2017 at 11:58, Kevin Smith <ke

Re: [Standards] Proposed XMPP Extension: Bind 2.0

> On 18 Jan 2017, at 14:36, Michal Piotrowski > wrote: > > I have another question regarding pipelining. From what I understand the very > first connection to the server should be "normal" like - client sends packet, > waits for the response(s) and

Re: [Standards] Proposed XMPP Extension: Bind 2.0

On 19 Jan 2017, at 10:37, Michal Piotrowski wrote: > Few more question, just to be on the same page: Yes, thanks for spending the time thinking about it! > >Work out which contacts have unread messages in the user's MAM archive, how > >many, and what

Re: [Standards] Proposed XMPP Extension: Bind 2.0

On 18 Jan 2017, at 13:25, Michal Piotrowski <michal.piotrow...@erlang-solutions.com> wrote: > On 18 January 2017 at 14:08, Kevin Smith <kevin.sm...@isode.com> wrote: > How many is many? I don’t see a problem with this scaling to any human IM > cases that I can think of.

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