Re: [Standards] Proposed XMPP Extension: Bind 2.0

Thanks. > On 17 Jan 2017, at 20:30, Michal Piotrowski > wrote: > > Hi, > > Thanks for the protoXEP, this is step in a good direction! The part which I > find the most important is the information about unread messages. Here are my > questions

Re: [Standards] Proposed XMPP Extension: Bind 2.0

> On 17 Jan 2017, at 22:09, Florian Schmaus wrote: > > On 17.01.2017 16:23, XMPP Extensions Editor wrote: >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Bind 2.0 >> >> Abstract: This specification provides a single-request replacement for

Re: [Standards] [xsf/xeps] Defers many old XEPs (#372)

Hi Peter, > On 18 Jan 2017, at 10:43, Peter Waher wrote: > > Is it possible for me to mail updates to these XEPs to the editor e-mail, as > was possible before? Sending patches by email remains an option, yes. You could probably even get away with sending the entire

Re: [Standards] bind2

ng-solutions.com > > On 13 January 2017 at 12:24, Florian Schmaus <f...@geekplace.eu> wrote: > On 13.01.2017 10:27, Kevin Smith wrote: > > On 11 Jan 2017, at 20:09, Evgeny Khramtsov <xramt...@gmail.com> wrote: > >> > >> Wed, 11 Jan 2017 19:56:43 +

Re: [Standards] XEP-0300 and a future without reading tea leaves

> On 17 Jan 2017, at 15:33, Goffi <go...@goffi.org> wrote: > > Le mardi 17 janvier 2017, 14:08:54 CET Tobias Markmann a écrit : >> On Fri, Jan 13, 2017 at 11:59 AM, Kevin Smith <kevin.sm...@isode.com> wrote: >>> It sounds like a sensible enough a

Re: [Standards] XEP-0300 and a future without reading tea leaves

On 17 Jan 2017, at 13:08, Tobias Markmann <tmarkm...@googlemail.com> wrote: > > > On Fri, Jan 13, 2017 at 11:59 AM, Kevin Smith <kevin.sm...@isode.com> wrote: > It sounds like a sensible enough approach to me, unless we think Gajim is the > only deployment us

Re: [Standards] Easy XMPP

On 7 Jun 2016, at 16:04, Georg Lukas wrote: > I think we can improve significantly for the XMPP IM use case (I have > not much expertise in other use cases), if we simplify the things that > can be simplified, make them consistent between clients, and give the > whole thing a

Re: [Standards] Easy XMPP

Thread necromancy. > On 8 Jun 2016, at 18:59, A. Bikadorov wrote: > you may wanna have a look at the Kontalk project which already has a client > implementing > some simplifications you are proposing: > - server list + automatic server selection (and option to override) > -

Re: [Standards] XEP-0300 and a future without reading tea leaves

On 12 Jan 2017, at 09:48, Tobias Markmann wrote: > This can be seen as a continuation of my classic thread on this very channel > from 2014 titled "File Hashes in XEP-0234". It was so popular, that even I > did lost interest in it. :D > > Back to the future, today.

Re: [Standards] Obsoleting vCard-Based Avatars

On 11 Jan 2017, at 20:09, Evgeny Khramtsov <xramt...@gmail.com> wrote: > > Wed, 11 Jan 2017 19:56:43 +0000 > Kevin Smith <kevin.sm...@isode.com> wrote: > >> I’m obviously just about the last person to say we shouldn’t be >> trying to modernise XMPP, g

Re: [Standards] Expected behavior when blocking all unknown JIDs

On 11 Jan 2017, at 21:13, Daniel Gultsch wrote: > And yes there are a few users out there for which blocking strangers is an > effective way of fighting spam. However so is blocking messages with Cyrillic > letters in them. This doesn't mean we should make a standard for

Re: [Standards] Obsoleting vCard-Based Avatars

> On 11 Jan 2017, at 16:44, Sam Whited <s...@samwhited.com> wrote: > > On Tue, Jan 10, 2017 at 11:04 AM, Kevin Smith <kevin.sm...@isode.com> wrote: >> FWIW, give the remaining widespread deployment of vcard avatars compared to >> pubsub-based, and of re

Re: [Standards] Obsoleting vCard-Based Avatars

On 08/01/2017 14:59, Sam Whited wrote: Hi all, XEP-0053: vCard-Based Avatars [1] is a historical specification that has been superseded by XEP-0084: User Avatars [2] for quite some time. However, since it's historical it still shows up in the list on xmpp.org and this seems like a possible

Re: [Standards] XEP-0369 Proxy JIDs and MIX

On 10/01/2017 15:23, Sam Whited wrote: 2. While burner JIDs may be helpful to provide a user with complete anonymity in a channel, I think that channel administration needs access to the real JIDs. It would not be acceptable to manage a public MUC and just have a stack of anonymous

Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]

On 10/01/2017 15:16, Sam Whited wrote: On Tue, Jan 10, 2017 at 9:01 AM, Kevin Smith <kevin.sm...@isode.com> wrote: I think you'd need to build so much extra stuff on top of burner JIDs … that you end up with vastly more complexity than proxy JIDs give you. I'm not so sure; you get a

Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]

On 06/01/2017 16:15, Sam Whited wrote: On Fri, Jan 6, 2017 at 10:10 AM, Steve Kille wrote: I don't object to this, but I can't see how it makes much difference to MIX. What impact is there besides following the rules for generating random JIDs? Using this removes the

Re: [Standards] XEP-0369 (MIX) and sorting out co-existence of MUC and MIX on a single domain

On 10/01/2017 14:27, Dave Cridland wrote: On 10 January 2017 at 13:30, Kevin Smith <kevin.sm...@isode.com> wrote: On 10/01/2017 12:05, Steve Kille wrote: I have just issued a PR for MIX version 0.6.4. There is clear desire to have the option for MUC and MIX to use the same

Re: [Standards] XEP-0369 (MIX) and sorting out co-existence of MUC and MIX on a single domain

On 10/01/2017 12:05, Steve Kille wrote: I have just issued a PR for MIX version 0.6.4. There is clear desire to have the option for MUC and MIX to use the same domain.The difficulty in achieving this was incompatible disco results. This version has made a change to add node='mix' to

Re: [Standards] A possible MIX approach: hiding multiple clients

On 6 Jan 2017, at 10:01, Kevin Smith <kevin.sm...@isode.com> wrote: > >> >> On 6 Jan 2017, at 07:50, Steve Kille <steve.ki...@isode.com> wrote: >> >> >> The recent discussion on the difficulty of proxy JIDs has triggered me to >> writ

Re: [Standards] A possible MIX approach: hiding multiple clients

> On 6 Jan 2017, at 07:50, Steve Kille wrote: > > > The recent discussion on the difficulty of proxy JIDs has triggered me to > write up a more radical idea I have had floating around. > > For the most part, a MIX channel deals with users (not clients). Messages > are

Re: [Standards] Unread syncing

On 14 Dec 2016, at 11:46, Michal Piotrowski wrote: > > > On 2 December 2016 at 18:18, forenjunkie > wrote: > Ah now im understanding, basically the server should give you a list of > contacts to

[Standards] Thanks for the meetup

Not really sure whether here or members@ is the better place, but I wanted to drop a quick note saying thanks! to Dave, Laura and Paul (and anyone else involved) for setting up the XMPP Meetup in London last night, and the (other) speakers. Was a good night (good pizza :)). /K

Re: [Standards] References and XHTML-IM interoperability

> On 2 Dec 2016, at 22:50, Tobias Markmann <tmarkm...@googlemail.com> wrote: > > >> On Fri, Dec 2, 2016 at 9:51 PM, Kevin Smith <kevin.sm...@isode.com> wrote: >> We are, but that shouldn't stop me confusing things! >> >> Tobi mentioned that we sh

Re: [Standards] References and XHTML-IM interoperability

> On 2 Dec 2016, at 18:38, Peter Saint-Andre <stpe...@stpeter.im> wrote: > >> On 12/2/16 11:32 AM, Kevin Smith wrote: >> >> >>>> On 2 Dec 2016, at 18:22, Peter Saint-Andre <stpe...@stpeter.im> wrote: >>>> >>>> On 12

Re: [Standards] Unread syncing

never did write a implementation of MAM myself, but if im reading the XEP, > you can filter with various attributes, you dont have to step through EVERY > message. > >> Am 02.12.2016 um 16:57 schrieb Kevin Smith: >>> On 2 Dec 2016, at 15:49, forenjunkie <forenjun...

Re: [Standards] Unread syncing

dreds or thousands of messages older than my messages from contact B, all of which are read. If I merely read the archive backwards until I found a read marker, I wouldn’t find the unread messages for contact A. /K > > > Am 02.12.2016 um 16:34 schrieb Kevin Smith: >> On 2 D

Re: [Standards] References and XHTML-IM interoperability

On 2 Dec 2016, at 15:44, Tobias M <tmarkm...@googlemail.com> wrote: > > >> On 2 Dec 2016, at 16:39, Kevin Smith <kevin.sm...@isode.com >> <mailto:kevin.sm...@isode.com>> wrote: >> >> They’re long and (as far as I can see at the moment) unnece

Re: [Standards] References and XHTML-IM interoperability

On 2 Dec 2016, at 15:37, Tobias M <tmarkm...@googlemail.com> wrote: >> On 2 Dec 2016, at 16:07, Kevin Smith <kevin.sm...@isode.com >> <mailto:kevin.sm...@isode.com>> wrote: >> >> I don’t see why the ids need to be UUIDs (indeed, it seems activel

Re: [Standards] Unread syncing

On 2 Dec 2016, at 15:26, forenjunkie wrote: > in a single chat conversation, it makes no sense to query unread messages. I’m not sure that’s true at all, but putting that to the side for the minute... > you could just query the last 10 MAM Messages, if no readmarker comes

Re: [Standards] References and XHTML-IM interoperability

On 2 Dec 2016, at 14:56, Sam Whited wrote: > > On Fri, Dec 2, 2016 at 6:00 AM, Tobias Markmann > wrote: >> One approach would be requiring IDs on the tags you want to reference. This >> way the reference tag could simple refer to that ID, which

Re: [Standards] Unread syncing

> On 2 Dec 2016, at 14:35, Christian Schudt wrote: > > >> Except that they’re not chat messages, so won’t be stored, and if they were >> you’d be potentially up to doubling the size of your archive (I guess adding >> a quarter to, on average) as you fill it with read

Re: [Standards] Unread syncing

> On 2 Dec 2016, at 13:42, Christian Schudt wrote: > >> I think you possibly don’t :) >> >> This is for synchronising the ‘read’ status between all of my clients, such >> that a) they’re consistent and b) when a new client comes online it can >> quickly determine

Re: [Standards] Unread syncing

ages. /K > > -- Christian > > Gesendet: Freitag, 02. Dezember 2016 um 12:44 Uhr > Von: "Kevin Smith" <kevin.sm...@isode.com> > An: "XMPP Standards" <standards@xmpp.org> > Betreff: [Standards] Unread syncing > A question

Re: [Standards] Unread syncing

> On 2 Dec 2016, at 11:44, Kevin Smith <kevin.sm...@isode.com> wrote: > > A question: > > I’ve always assumed that we would do sync of the unread (or, rather read) > status of messages between contacts via private PEP and, indeed, this is the > approach we verbally

[Standards] Unread syncing

A question: I’ve always assumed that we would do sync of the unread (or, rather read) status of messages between contacts via private PEP and, indeed, this is the approach we verbally specced at a summit a while back (which I have yet to write up). I’ve been thinking about this further, in

Re: [Standards] [Council] 2016-11-23 Council Meeting Minutes

On 29 Nov 2016, at 12:25, Daniel Gultsch wrote: >> >> ## 6a) https://github.com/xsf/xeps/pull/204 > > +1 > There has been some debate over where registry entries are actually > defined and whether this additional form value should be defined in > the XEP or directly in the

Re: [Standards] Verifiability of stanza-ids

> On 29 Oct 2016, at 11:51, Daniel Gultsch wrote: > > Hi, > > When an entity injects stanza-ids (for example to communicate) the MAM > archive id those IDs need to be verified by the receiving entity. > Meaning when I receive a stanza-id and later use that id to query my >

Re: [Standards] Proposed XMPP Extension: Message Deletion

On 18 Oct 2016, at 10:31, Guus der Kinderen <guus.der.kinde...@gmail.com> wrote: > On 18 October 2016 at 11:18, Kevin Smith <kevin.sm...@isode.com> wrote: >> >> On 18 Oct 2016, at 10:16, Guus der Kinderen <guus.der.kinde...@gmail.com> >> wrote: >&g

Re: [Standards] Proposed XMPP Extension: Message Deletion

On 18 Oct 2016, at 10:16, Guus der Kinderen <guus.der.kinde...@gmail.com> wrote: > On 18 October 2016 at 11:12, Kevin Smith <kevin.sm...@isode.com> wrote: >> On 18 Oct 2016, at 10:09, Guus der Kinderen <guus.der.kinde...@gmail.com> >> wrote: >> > I

Re: [Standards] Proposed XMPP Extension: Message Deletion

On 18 Oct 2016, at 10:09, Guus der Kinderen wrote: > I don't have much of an argument other than the obvious: both affect data > 'after-the-fact'. Concerns raised against one should likely also be tested > against the other - it's pretty much the same thing. As for

Re: [Standards] XEP-0050: Ad-Hoc Commands

On 18 Oct 2016, at 07:54, jorge - w wrote: > My view is that XEP-0050 is fine as an admin tool, just like XEP-0133. > > But what is fine for admins is not always the same for regular users. That's > why i think there should be a different interface for regular users mostly

Re: [Standards] XEP-0359 Client vs. non-client IDs

> On 2 Oct 2016, at 18:46, Florian Schmaus <f...@geekplace.eu> wrote: > > On 29.09.2016 20:18, Kevin Smith wrote: >> On 29 Sep 2016, at 19:08, Florian Schmaus <f...@geekplace.eu> wrote: >>> >>> On 29.09.2016 19:22, Guus der Kinderen

Re: [Standards] XEP-0308: Last Message Correction and Carbons

On 2 Oct 2016, at 18:47, Florian Schmaus <f...@geekplace.eu> wrote: > > On 30.09.2016 18:12, Kevin Smith wrote: >> On 30 Sep 2016, at 10:01, Dave Cridland <d...@cridland.net> wrote: >>> >>> On 30 September 2016 at 09:49, Kevin Smith <kevin.sm...

Re: [Standards] XEP-0308: Last Message Correction and Carbons

On 30 Sep 2016, at 17:25, Dave Cridland <d...@cridland.net> wrote: > > On 30 September 2016 at 17:12, Kevin Smith <kevin.sm...@isode.com> wrote: >> On 30 Sep 2016, at 10:01, Dave Cridland <d...@cridland.net> wrote: >>> >>> On 30 September 2016 at

Re: [Standards] XEP-0308: Last Message Correction and Carbons

On 30 Sep 2016, at 10:01, Dave Cridland <d...@cridland.net> wrote: > > On 30 September 2016 at 09:49, Kevin Smith <kevin.sm...@isode.com> wrote: >> >>> On 29 Sep 2016, at 22:58, Dave Cridland <d...@cridland.net> wrote: >>> >>> >&

Re: [Standards] XEP-0308: Last Message Correction and Carbons

> On 29 Sep 2016, at 22:58, Dave Cridland <d...@cridland.net> wrote: > > > On 29 Sep 2016 22:00, "Kevin Smith" <kevin.sm...@isode.com> wrote: > > > > On 29 Sep 2016, at 21:17, Dave Cridland <d...@cridland.net> wrote: > > >

Re: [Standards] XEP-0308: Last Message Correction and Carbons

On 29 Sep 2016, at 21:17, Dave Cridland wrote: > (And please, folks, unless you can think of something I can't, a > randomish string prefix and a counter is fine). The dangers of using counters in stanza IDs and leaking information :) /K

Re: [Standards] XEP-0359 Client vs. non-client IDs

On 29 Sep 2016, at 19:08, Florian Schmaus wrote: > > On 29.09.2016 19:22, Guus der Kinderen wrote: >> Hi, >> >> What's the purpose of the distinction between "Unique Stanza IDs" and >> "Client generated stanza IDs"? Why not add a unbounded list of stanza-id >> elements (each

Re: [Standards] XEP-0359 Client vs. non-client IDs

On 29 Sep 2016, at 18:22, Guus der Kinderen wrote: > What's the purpose of the distinction between "Unique Stanza IDs" and "Client > generated stanza IDs"? Why not add a unbounded list of stanza-id elements > (each with a unique 'by' attribute value), and not worry

Re: [Standards] XEP-0369 (MIX) - approach to Channel invitation

On 27 Sep 2016, at 17:18, Sam Whited wrote: > > On Tue, Sep 27, 2016 at 3:30 AM, Steve Kille wrote: >> A simple approach to address this more complex scenario is a two-step >> approach where the inviter starts by sending a message to the channel to >>

Re: [Standards] XEP-0308: Last Message Correction and Carbons

On 28 Sep 2016, at 21:18, Tobias M <tmarkm...@googlemail.com> wrote: > >> >> On 28 Sep 2016, at 18:38, Kevin Smith <kevin.sm...@isode.com> wrote: >> >> On 27 Sep 2016, at 10:06, Tobias M <tmarkm...@googlemail.com> wrote: >>> >

Re: [Standards] XEP-0308: Last Message Correction and Carbons

On 27 Sep 2016, at 10:06, Tobias M <tmarkm...@googlemail.com> wrote: > > >> On 27 Sep 2016, at 00:33, Kevin Smith <kevin.sm...@isode.com> wrote: >> >>> However, it has little discussion on why there is this restriction. While >>> it certainly

Re: [Standards] Deprecating Message Archiving

On 19 Sep 2016, at 18:09, Florian Schmaus wrote: > I think it's to early to deprecate Message Archiving while MAM is just > experimental. That said, I suggest adding a disclaimer to Message Archiving > stating that new installations should consider MAM instead. I think that

Re: [Standards] XEP-0308: Last Message Correction and Carbons

> On 16 Sep 2016, at 12:39, Tobias M wrote: > > Hi, > > Under 4. Business Rules XEP-0308 mentions: > >> A correction MUST only be allowed when both the original message and >> correction are received from the same full-JID. > > However, it has little discussion on

Re: [Standards] XEP-0369 (MIX) - Approach to options for per-user preferences

On 21 Sep 2016, at 16:21, Steve Kille wrote: > The sort of thing I am looking to avoid is where the server provides the > user with a form to fill in. By standardising common fields, we can avoid form requests in the common case without forcing clients to do the request

Re: [Standards] PAM Source Selection

On 7 Sep 2016, at 10:32, Dave Cridland <d...@cridland.net> wrote: > > > On 7 Sep 2016 11:28, "Kevin Smith" <kevin.sm...@isode.com> wrote: > > > > On 7 Sep 2016, at 10:22, Dave Cridland <d...@cridland.net> wrote: > > > > > If t

Re: [Standards] PAM Source Selection

On 7 Sep 2016, at 10:22, Dave Cridland wrote: > > > If this seems right, I'll write this up formally into the XEP and go from > > > there. > > > > It’s not clear to me that another stanza is necessary, and that this can’t > > come out of normal caps handling by the server.

Re: [Standards] PAM Source Selection

On 7 Sep 2016, at 10:20, Georg Lukas <ge...@op-co.de> wrote: > > * Kevin Smith <kevin.sm...@isode.com> [2016-09-07 11:19]: >> It’s not clear to me that another stanza is necessary, and that this >> can’t come out of normal caps handling by the server. It’s probab

Re: [Standards] PAM Source Selection

On 7 Sep 2016, at 10:07, Dave Cridland <d...@cridland.net> wrote: > > In the xsf@ chatroom, Georg Lukas, Ralph Meijer, Kevin Smith, and I had a > quick discussion on how clients might interact with PAM in order to select > and filter based on information type and source.

Re: [Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

t; is set >>> >>> In MUC it didn't have to be; infact, often joining a room was no different >> to >>> updating your presence. >> [Steve Kille] >> >> Kevin Smith responded on this point. > > The muc element is optional, see > https://xmpp.

Re: [Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

> On 6 Sep 2016, at 09:00, Daurnimator wrote: > > On 6 September 2016 at 00:59, XMPP Extensions Editor wrote: >> Version 0.3 of XEP-0369 (Mediated Information eXchange (MIX)) has been >> released. >> >> Abstract: This document defines Mediated

Re: [Standards] Proposed DTD fixes

On 30 Aug 2016, at 18:47, Steve Kille wrote: > Edwin, > >> Our DTD seems to reject the vast majority of our XEPs. In part, this is >> because there are true mistakes in XEPs – e.g., where the author >> actually >> should've used – which aren't converted to the expected

Re: [Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

On 23 Aug 2016, at 22:09, Dave Cridland wrote: > > > On 23 Aug 2016 21:56, "Georg Lukas" wrote: > > > > Hi Steve, > > > > thanks for the clarifications. I'm still not quite sure about the > > implications of some of the things though, maybe you can clarify...

Re: [Standards] MIX

On 15 Aug 2016, at 17:46, Dave Cridland wrote: > > (Just so people know, I'm referring to the branch pull/225/head - ie, > Github PR 225 - and the revision > 87496453cd26086d35156add535bdb1d6d6a0c94) > > A couple of procedural comments: > - This has been submitted by a new

Re: [Standards] [Council] 2016-07-20 Council Meeting

On 5 Aug 2016, at 17:01, Holger Weiß wrote: > > * Holger Weiß [2016-07-27 12:33]: >> * Tobias Markmann [2016-07-27 10:28]: ### XEP-0045: Define option name for enabling/disabling MAM

Re: [Standards] XEP-0375: View from Openfire

> On 12 Jul 2016, at 13:49, Ralph Meijer wrote: > > On 2016-07-12 05:11, Sam Whited wrote: >> I've tried to address some of this feedback here: >> >> https://github.com/xsf/xeps/pull/206 >> >> I think the only thing I left out was getting rid of the IM compliance >> suites (in

Re: [Standards] XEP-0313: MAM: RSM response data

On 7 Jul 2016, at 11:00, Dave Cridland wrote: > > Folks, > > XEP-0313 §4 says: > > "The final response MUST include an RSM element indicating > the UID of the first and last message of the (possibly limited) result set." > > This seems plausible, but looks like a

Re: [Standards] MIX progress

On 5 Jul 2016, at 11:21, Florian Schmaus <f...@geekplace.eu> wrote: > > On 05.07.2016 12:07, Kevin Smith wrote: >> On 5 Jul 2016, at 11:06, Florian Schmaus <f...@geekplace.eu> wrote: >>> >>> On 05.07.2016 11:10, Kevin Smith wrote: >>>> On 5

Re: [Standards] MIX progress

On 5 Jul 2016, at 11:07, Evgeny Khramtsov <xramt...@gmail.com> wrote: > > Tue, 5 Jul 2016 10:10:28 +0100 > Kevin Smith <kevin.sm...@isode.com> wrote: > >> On 5 Jul 2016, at 09:51, Florian Schmaus <f...@geekplace.eu> wrote: >>> XEP dev

Re: [Standards] MIX progress

On 5 Jul 2016, at 11:06, Florian Schmaus <f...@geekplace.eu> wrote: > > On 05.07.2016 11:10, Kevin Smith wrote: >> On 5 Jul 2016, at 09:51, Florian Schmaus <f...@geekplace.eu> wrote: >>> XEP development behind closed doors is not desirable. >> >>

Re: [Standards] MIX progress

On 5 Jul 2016, at 10:22, Dave Cridland <d...@cridland.net> wrote: > On 5 July 2016 at 10:10, Kevin Smith <kevin.sm...@isode.com> wrote: >> On 5 Jul 2016, at 09:51, Florian Schmaus <f...@geekplace.eu> wrote: >> > XEP development behind closed doors is not desi

Re: [Standards] MIX progress

On 5 Jul 2016, at 09:51, Florian Schmaus wrote: > XEP development behind closed doors is not desirable. To be fair, that isn’t what’s happening here, it’s just that Steve wants to double-check that the text reflects the Summit agreements before he submits. /K

Re: [Standards] Standard room configuration name for MUC MAM

On 4 Jul 2016, at 14:55, Holger Weiß wrote: > Would people be fine with defining a standard name for a room > configuration setting that enables/disables MUC MAM (e.g., > muc#roomconfig_mam)? That way, clients that don't want to present the > full configuration form

Re: [Standards] MIX progress

Hi Evgeny, On 5 Jul 2016, at 07:29, Evgeny Khramtsov wrote: > Is anyone working on the MIX (XEP-0369) spec? Can I look at > a preliminary updated version? I'm playing with MIX-MUC interaction > code and it seems like ACL and config interaction is the most > challenging part,

Re: [Standards] XEP-0045 join when already in MUC

> On 23 Jun 2016, at 23:35, Georg Lukas wrote: > > Hi, > > TL;DR: whenever a client (re)sends a join, the MUC service should return > everything a newly joining client needs to know. > > According to XEP-0045, an initial join presence needs to contain an 'x' > element with

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

On 23 Jun 2016, at 15:02, Sam Whited wrote: > > On Thu, Jun 23, 2016 at 2:49 AM, Florian Schmaus wrote: >> I also still think that we should clarify somewhere if the carbons state >> is kept after a stream resumption or not [1]. Not sure if the right >>

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

> On 13 Jun 2016, at 11:41, Matthew Wild wrote: > > On 12 June 2016 at 12:39, Daniel Gultsch wrote: >> Hi, >> >> I'm bumping this thread since it hasn't yielded too many responses since I >> originally voiced my concerns. >> >> To briefly summarize the

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

> On 13 Jun 2016, at 11:49, Kevin Smith <kevin.sm...@isode.com> wrote: > >> >> On 13 Jun 2016, at 11:41, Matthew Wild <mwi...@gmail.com> wrote: >> >> On 12 June 2016 at 12:39, Daniel Gultsch <dan...@gultsch.de> wrote: >>> Hi, >>

Re: [Standards] "Chronological" order in XEP-0313 (Message Archive Management)

On 19 May 2016, at 09:21, Georg Lukas wrote: > we just had a discussion in the prosody MUC, regarding message ordering > in MAM, and I realized there is some ambiguity in the XEP when handling > incoming elements. > > The XEP explicitly states that messages must be sorted

Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2016

> On 13 May 2016, at 17:30, Dave Cridland <d...@cridland.net> wrote: > > > > On 13 May 2016 at 17:10, Kevin Smith <kevin.sm...@isode.com>wrote: > On 13 May 2016, at 17:05, Dave Cridland <d...@cridland.net> wrote: > > There's a problem inherent

Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2016

On 13 May 2016, at 17:05, Dave Cridland wrote: > There's a problem inherent in this that we'd need to actually verify the > clients have actually implemented the features they claim, and that in turn > means some volunteer effort in testing them though. I believe that any

Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2016

> On 13 May 2016, at 14:16, Sam Whited wrote: > > As a compromise, perhapse it makes sense to split CSI out into a > separate "Mobile Compliance" section? This might be something good to > have in general. > > Thoughts appreciated. I think that might be reasonable. I

Re: [Standards] Proposed XMPP Extension: References

> On 21 Mar 2016, at 14:14, Dave Cridland <d...@cridland.net> wrote: > > > > On 21 March 2016 at 14:06, Kevin Smith <kevin.sm...@isode.com> wrote: > > > On 21 Mar 2016, at 11:48, Daniel Gultsch <dan...@gultsch.de> wrote: > > > > An upda

Re: [Standards] Proposed XMPP Extension: References

> On 21 Mar 2016, at 11:48, Daniel Gultsch wrote: > > An update to the 'arbitrary attributes' feature request. Even more important > than the before mentioned content-type, content-length and so forth are > probably description and a thumbnail. Information which can be

Re: [Standards] MUC: Opt-out of presence broadcasting

> On 9 Mar 2016, at 09:43, Mickaël Rémond wrote: > > Hello, > > On Mon, Feb 29, 2016 at 9:59 PM Sam Whited > wrote: > On Mon, Feb 29, 2016 at 2:25 PM, Dave Cridland

Re: [Standards] Proposed XMPP Extension: References

On 15 Feb 2016, at 14:03, Dave Cridland wrote: > 3) I'm mildly concerned that §3.4 radically alters the meaning of the > element. It seems to me that "This message refers to X" is > different to "That message refers to X" at a fairly fundamental level; the > former being

Re: [Standards] Proposed XMPP Extension: References

On 24 Feb 2016, at 11:57, Daniel Gultsch wrote: > 2016-02-14 22:33 GMT+01:00 Daniel Gultsch : > I would like to see this XEP support more or less arbitrary attributes like > content-type, content-length as well as resolution (x,y) for images and > videos as

Re: [Standards] Proposed XMPP Extension: References

Hi Goffi, On 8 Feb 2016, at 11:20, Goffi wrote: > Le vendredi 5 février 2016, 15:52:36 XMPP Extensions Editor a écrit : >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: References >> >> Abstract: This document defines XMPP protocol for

[Standards] 'by' attribute

We’ve just had the suggestion at the summit that Security Considerations need to be checked for incoming XEPs that if there’s some sort of stamping going on it needs a consideration for verification/replacing. Something for Council to consider. /K

Re: [Standards] Proposed XMPP Extension: Mediated Information eXchange (MIX)

Thanks Georg. On 26 Jan 2016, at 12:07, Georg Lukas wrote: > 1. Use same service JID for MIX and MUC: Parallel MIX/MUC operation is a > designated goal, however the intro states that MIX and MUC SHOULD be > hosted on different domains. I would like to ask the committee to revise

Re: [Standards] XEP-0313: why it is *really* not a good idea to use MAM with Pubsub

On 6 Jan 2016, at 11:08, Goffi wrote: > - All items a returned in separate stanza, wrapped in a > element, one item per stanza. This both is a waste of bandwidth and make the > task more difficult for the client as it must track each and the > > result to known when a

[Standards] Summit topics

Hi folks, Back a few weeks ago the Council set MIX and E2E as two big topics that need discussion at the Summit. Do those attending have other topics that they want to bring? I expect (although don’t know) that we’ll do the usual ‘gather topics at the start’ thing, and that things will flow

Re: [Standards] Summit topics

Taking this back to the summit list, let’s continue discussion there. On 23 Jan 2016, at 12:51, Goffi <go...@goffi.org> wrote: > > Le samedi 23 janvier 2016, 12:24:38 Kevin Smith a écrit : >> Hi folks, >> >> Back a few weeks ago the Council set MIX and E

Re: [Standards] Multi-client operation and read-until-X markers

Thread necromancy! On 2 Apr 2015, at 18:12, Georg Lukas wrote: > NOTIFICATIONS > > The first problem I encountered (after implementing carbons) is user > notification on mobile (i.e. play a ringtone, vibrate, display a popup > like

[Standards] Fwd: [Council] Minutes 2016-01-06

FYI > Begin forwarded message: > > From: Kevin Smith > Subject: [Council] Minutes 2016-01-06 > Date: 6 January 2016 at 16:28:48 GMT > To: XMPP Council > > Room logs: http://logs.xmpp.org/council/2016-01-06/ > > 0) Roll call > Lance, Peter, Dave, Tobi, Matt pre

Re: [Standards] [Operators] Source of the JIDs being spammed? -- Re: Suspicion of Jabbim services being hacked

On 23 Dec 2015, at 17:10, Kim Alvefur wrote: > > On 2014-12-19 15:24, Peter Viskup wrote: >> Hi all, >> thought it would be interesting to the audience of this mailinglist. >> >> http://pinky.jabb.im/2014/12/jabbim-bezpecnostni-problem-security.html >> >> Best regards, >> > >

Re: [Standards] namespace versioning for XEP-0176

On 11 Dec 2015, at 09:56, Dave Cridland wrote: > > > > On 11 December 2015 at 03:56, Peter Saint-Andre > wrote: > Folks, I am working on revisions [1] to XEP-0176 to bring it up to date with > both RFC 6544 (ice-tcp) and

Re: [Standards] namespace versioning for XEP-0176

> On 11 Dec 2015, at 10:40, Dave Cridland <d...@cridland.net> wrote: > > > > On 11 December 2015 at 10:07, Kevin Smith <kevin.sm...@isode.com > <mailto:kevin.sm...@isode.com>> wrote: > On 11 Dec 2015, at 09:56, Dave Cridland <d...@cridlan

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

On 13 Nov 2015, at 14:54, Thijs Alkemade wrote: > Hi all, > > To get the ball rolling, I’ll play devil’s advocate for a bit here: it is > impossible to implement OMEMO from scratch by the current documentation alone. > “Axolotl” has no standard, and it appears Open Whisper

Re: [Standards] Deprecating IBR

On 11 Nov 2015, at 10:06, Tomasz Sterna wrote: > Dnia 2015-11-10, wto o godzinie 17:10 -0600, Sam Whited pisze: >>> What do you suggest to replace it with? >> >> I suggest we replace it with nothing. > > Closing the network is not the answer. > People need a way of joining the

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