On Mon, 24 Jun 2019 at 20:43, Florian Schmaus wrote:
> On 18.06.19 13:05, Dave Cridland wrote:
> > On Mon, 17 Jun 2019 at 17:09, Florian Schmaus > <mailto:f...@geekplace.eu>> wrote:
> >
> > The solution back then was PEP, which is based on PubSub. Why
On Wed, 19 Jun 2019 at 16:00, Jonas Schäfer wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Stanza Content Encryption
> Abstract:
> The Stanza Content Encryption (SCE) protocol is intended as a way to
> allow clients to securely exchange arbitrary extension
On Sat, 22 Jun 2019 at 19:12, Dave Cridland wrote:
>
>
> On Thu, 20 Jun 2019 at 20:32, Kim Alvefur wrote:
>
>> Hi,
>>
>> While working on a fix for Prosodys XEP-0191 implementation¹ regarding
>> presence sent to a blocked JID to pretend that the blocking
On Thu, 20 Jun 2019 at 20:32, Kim Alvefur wrote:
> Hi,
>
> While working on a fix for Prosodys XEP-0191 implementation¹ regarding
> presence sent to a blocked JID to pretend that the blocking user is
> offline, and then re-send presence again if they unblock.
>
> However, since if you block
On Mon, 17 Jun 2019 at 17:09, Florian Schmaus wrote:
> The solution back then was PEP, which is based on PubSub. Why would you
> want to build a publish-subscribe mechanism not on XEP-0060 PubSub?
>
>
It's possible to put everything into XEP-0060 - indeed, XEP-0207 discusses
exactly this, and
The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests and issues marked "Needs Council":
https://github.com/xsf/xeps/labels/Needs%20Council
* Random mails from Standards List
* Random
I think the optimal ping, from the server's perspective, radically changes
depending on whether there are outstanding messages, and whether there's an
outstanding XEP-0198 ack.
>From a client's perspective it's really dependent on whether the user is
active, and if not, whether there is a push
bits from them all.
Just a high-level technical sketch would be really useful.
> ср, 29 мая 2019 г. в 16:12, Dave Cridland :
>
>> Having spent a while playing with - gasp! - non-XMPP based chat systems,
>> I'm quite taken with the notion that some kind of Inbox might be rather
&g
Hi all,
There would normally be an XMPP Council meeting today (Wednesday) at 1500
UTC, but there's nothing on the agenda, so we've decided to skip this week.
Expect a suitably witty set of non-minutes from Tedd Sterr.
The agenda is collated from (in order of reliability):
* Github pull requests
Having spent a while playing with - gasp! - non-XMPP based chat systems,
I'm quite taken with the notion that some kind of Inbox might be rather
useful to us.
Currently, there is Erlang Solutions (ESL)'s Inbox, which is essentially a
duplication of MAM with some chat state tracking. It's more
The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests and issues marked "Needs Council":
https://github.com/xsf/xeps/labels/Needs%20Council
* Random mails from Standards List
* Random
Standard response:
The process for XEPs in the XSF starts with the ProtoXEP submission - that
part is to decide if the XSF should take on the work.
If the XSF does, it takes copyright of the XEP, and works on the contents.
We do not have any IPR cover for something before this point, so I'm not
Also, I think we can squeeze on
X) https://github.com/xsf/xeps/pull/785 -
XEP-0260: Replace broken link with archive.org
I'm not sure if it's really more than Editorial given the nature of it, but
we may as well quickly discuss since it won't delay.
On Wed, 17 Apr 2019 at 09:23, Dave Cridland
Consider it on this week's agenda.
On Wed, 17 Apr 2019 at 06:39, Georg Lukas wrote:
> * Dave Cridland [2019-04-16 18:21]:
> > a) https://github.com/xsf/xeps/pull/736
> >
> > XEP-0308: Allow message correction in MUC
>
> While we are at it, I'd like to also add:
&
The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests and issues marked "Needs Council":
https://github.com/xsf/xeps/labels/Needs%20Council
* Random mails from Standards List
* Random
On Sun, 14 Apr 2019 at 19:44, Tedd Sterr wrote:
> *2019-03-20 (expired 2019-04-03)*
> PASSED (-0:0:+5) *Last Call: XEP-0353 (Jingle Message Initiation)* -
> https://xmpp.org/extensions/xep-0353.html
>
>
> *2019-03-27 (expired 2019-04-10)*
>
> PASSED (-0:2:+3)
> *Advance to Draft: XEP-0412 (XMPP
On Thu, 4 Apr 2019 at 17:26, Peter Saint-Andre wrote:
> On 4/1/19 12:59 PM, Florian Schmaus wrote:
> > On 30.03.19 16:48, Jonas Schäfer (XSF Editor) wrote:
> >> Version 0.1.0 of XEP-0418 (DNS Queries over XMPP (DoX)) has been
> >> released.
> >>
> >> Abstract:
> >> This specification defines an
t is a
signature nonetheless.
> Am 3. April 2019 18:12:47 MESZ schrieb "W. Martin Borgert" <
> deba...@debian.org>:
>>
>> Quoting Dave Cridland :
>>
>>> * But this is creating our own cryptography, and the XSF should not be
>>>
On Wed, 3 Apr 2019 at 15:34, Melvin Keskin wrote:
> You wrote in your first message on ATT:
> > This alone is absolutely not a blocker to adoption in my view.
>
> Then I read:
> > -1 - I don't think there's evidence of this being anything beyond a
> > very
> > high-level sketch. Designing a
On Sun, 31 Mar 2019 at 21:47, Tedd Sterr wrote:
> *2019-03-13 (expired 2019-03-27)*
>
> PASSED (-0:2:+3)
> *Proposed XMPP Extension: E2E Authentication in XMPP: Certificate Issuance
> and Revocation* - https://xmpp.org/extensions/inbox/eax-cir.html
> Dave: +1 (tentatively; seems in-scope)
>
Why is the IEEE working on this? Surely it would be considerably more
productive just to ask the XSF (or even the IETF, I can see arguments for
both) about the problem?
On Mon, 1 Apr 2019 at 10:51, Peter Waher wrote:
> Hello Paul, and those in the community interested in end-to-end encryption
>
On Sat, 30 Mar 2019 at 10:16, Daniel Gultsch wrote:
> Hi,
>
> I apologize in advanced for reiterating something that might have been
> obvious to anyone else but wasn’t to me:
>
> This XEP does two things:
> 1) Provide something that is basically equivalent to cross signing.
> Meaning if you
On Fri, 29 Mar 2019 at 14:02, Evgeny wrote:
>
>
> On Fri, Mar 29, 2019 at 4:57 PM, Dave Cridland
> wrote:
> >
> > That's interesting, because my understanding was that the result of
> > ATT was that if I manually verify one of your keys, I could then
> > tra
On Fri, 29 Mar 2019 at 13:08, Evgeny wrote:
> On Thu, Mar 28, 2019 at 8:23 PM, Dave Cridland
> wrote:
> > Overall, my view is that this specification is very unclear and
> > impossible to implement as written.
>
> I don't understand how this will work in practice i
On Tue, 26 Mar 2019 at 16:44, Jonas Schäfer wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Automatic Trust Transfer (ATT)
> Abstract:
> ATT specifies an automatic transfer of trust in public identity keys
> used by the end-to-end encryption protocol OMEMO.
Evgeny,
While I'm certain that Carlo is thick-skinned enough to ignore this remark,
I don't think it's helpful either to this thread or the community as a
whole. I appreciate it's hard not to react, I've done so myself many times
in the past, but I've learnt painfully that it is more useful to
On Wed, 27 Mar 2019 at 18:25, Sam Whited wrote:
> On Wed, Mar 27, 2019, at 17:14, W. Martin Borgert wrote:
> > 0393 is not bad, IMHO. It might need two or three additions, esp.
> > hyperlinks, but most typical use cases are covered.
>
> What is the use case for hyper links and who does it
On Tue, 26 Mar 2019 at 16:44, Jonas Schäfer wrote:
> Version 0.5.0 of XEP-0412 (XMPP Compliance Suites 2019) has been
> released.
>
> Abstract:
> This document defines XMPP protocol compliance levels.
>
> Changelog:
> * Taken over ownership.
> * Improved structure of category and level names.
>
On Mon, 25 Mar 2019 at 14:03, Florian Schmaus wrote:
> On 25.03.19 13:52, Dave Cridland wrote:
> >
> >
> > On Mon, 25 Mar 2019 at 12:26, Florian Schmaus > <mailto:f...@geekplace.eu>> wrote:
> >
> > On 25.03.19 12:48, Guus der Kinderen wrote:
&
On Mon, 25 Mar 2019 at 12:26, Florian Schmaus wrote:
> On 25.03.19 12: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
On Sat, 23 Mar 2019 at 09:14, Evgeny wrote:
> Hey, Georg, Dave.
>
> I think I have addressed all your concerns in my new local copy [1]
>
> [1] http://upload.zinid.ru/xep-eax-cir.html
>
>
Thanks, but for the avoidance of doubt, I had no concerns that needed to be
addressed prior to adoption.
>
On Fri, 22 Mar 2019 at 09:05, Evgeny wrote:
>
>
> On Fri, Mar 22, 2019 at 11:29 AM, Georg Lukas wrote:
> > * Tedd Sterr [2019-03-17 21:53]:
> >> Proposed XMPP Extension: E2E Authentication in XMPP: Certificate
> >> Issuance and Revocation -
> >> https://xmpp.org/extensions/inbox/eax-cir.html
On Mon, 18 Mar 2019 at 18:08, Ralph Meijer wrote:
> In general, I think that explicit is usually better than implicit. While
> I can see how a sensible default might be useful. It brings up some
> issues with users that use multiple different clients.
>
Yeah, and bots, and so on. I'm convinced
On Mon, 18 Mar 2019 at 17:07, Steve Kille wrote:
> Dave,
>
>
>
> Thanks for all this input. Let me go over it.
>
>
>
>
>
> *From:* Standards *On Behalf Of *Dave
> Cridland
> *Sent:* 12 March 2019 12:01
> *To:* XMPP Standards
> *Subject:* [Sta
On Thu, 14 Mar 2019 at 15:12, Peter Saint-Andre wrote:
> On 3/14/19 6:17 AM, Dave Cridland wrote:
> >
> >
> > On Thu, 14 Mar 2019 at 11:25, Ненахов Андрей
> > mailto:andrew.nenak...@redsolution.ru>>
> > wrote:
> >
> >
> > People
On Thu, 14 Mar 2019 at 15:14, Peter Saint-Andre wrote:
> On 3/14/19 5:05 AM, Dave Cridland wrote:
> >
> >
> > On Wed, 13 Mar 2019 at 21:46, Ralph Meijer > <mailto:ral...@ik.nu>> wrote:
> >
> > On 13/03/2019 22.16, Kevin Smith wrote:
> >
On Thu, 14 Mar 2019 at 11:25, Ненахов Андрей
wrote:
>
> People send comments on the list, and we answer their questions, propose
>> modifications to the text of the document, submit or process pull
>> requests, etc. For a small spec like this, it should be pretty simple.
>> Plus if you are a
On Wed, 13 Mar 2019 at 21:46, Ralph Meijer wrote:
> On 13/03/2019 22.16, Kevin Smith wrote:
> >
> >
> >> 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
Philipp, Peter,
Do either of you want to remain involved with this one?
Andrew,
If they don't, would you be able to handle processing Last Call feedback?
On Wed, 13 Mar 2019 at 13:14, Ненахов Андрей
wrote:
> Hello, everyone.
>
> Could we please advance XEP-0353: Jingle Message Initiation
>
Hi all,
I've been writing a quick and dirty implementation of MIX.
So far, I've started with an even quicker and dirtier PubSub, and glued in
the MIX stuff on top. There's no MAM etc yet.
The following are comments I've had so far, in no particular order:
* is sent to the sender for
On Mon, 4 Mar 2019 at 10:13, Severino Ferrer de la Peñita
wrote:
> On Monday, March 4, 2019 5:42:24 AM CET Ненахов Андрей wrote:
> > I think that the whole idea of making compliance suites as a xep is
> flawed
> > and creates unnecessary bureaucracy for bureaucracy sake.
> >
> > It could have
Who are you arguing *with*?
I agree it's ridiculous, but I also note that the number of comments on the
2019 one is considerably below 20, and possibly less than 15, depending on
how one counts. The number of people involved in the discussion outside
Council is less than 5 (and I'm including your
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 have
> capabilities to signal type of user activity beyond just "composing a
> message", but also
The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1600 UTC. The agenda is collated from (in order of reliability):
* Github pull requests and issues marked "Needs Council":
https://github.com/xsf/xeps/labels/Needs%20Council
* Random mails from Standards List
* Random
This looks very interesting - I'd not come across RELOAD before.
I'd note that the extent and complexity of this proposal means that the
Experimental phase is likely to be quite long, and I'm not clear if there's
enough interest for advancing, but I don't see any blockers for adoption as
a XEP.
On Mon, 4 Feb 2019 at 19:41, Jonas Schäfer wrote:
> On Sonntag, 3. Februar 2019 18:18:20 CET Tedd Sterr wrote:
> > PR #743 - XEP-0156: Add implementation notes suggesting CORS -
> > https://github.com/xsf/xeps/pull/743 Dave: +1 (doesn't actually
> recommend *
> > just uses it as an example, this
On Tue, 29 Jan 2019, 18:01 Sam Whited On Tue, Jan 29, 2019, at 17:41, Dave Cridland wrote:
> > a) Clients can make some assertion that they will generate a
> > globally-unique @id on stanzas.
>
> I like that, but would servers now have to remember which messages were
Thanks for this.
On Tue, 29 Jan 2019 at 23:04, Tedd Sterr wrote:
> *2019-01-09 (expired 2019-01-23)*
>
> PASSED (-0:1:+4)
> *Proposed XMPP Extension: Order-By* -
> https://xmpp.org/extensions/inbox/order-by.html
> Dave: +0 (reserve the right to change that while others are still on-list)
>
Let's assume, for a moment, that we do not wish to attempt to solve
deliberate duplication of ids, and instead assume that any duplication is a
bug.
Let's further assume that "if only" the @id attribute of a stanza were both
always present, and globally unique, it'd work.
What if:
a) Clients
On Fri, 25 Jan 2019 at 12:08, Evgeny wrote:
> On Fri, Jan 25, 2019 at 1:45 PM, Dave Cridland
> wrote:
> > I'm hearing "no", here - which is fine - but I do have a design for
> > enforced password changes and password resets, too. The former is
> > built around
On Thu, 24 Jan 2019 at 20:03, Evgeny wrote:
> On Thu, Jan 24, 2019 at 9:15 PM, Dave Cridland
> wrote:
> > XMPP-Grid (that draft) essentially says both servers and clients MUST
> > implement EXTERNAL, SCRAM-SHA1, SCRAM-SHA1-PLUS, SCRAM-SHA-256, and
> > SCRAM-SHA-256-PL
There's an ongoing discussion about
https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ - a document
currently about to be voted on by the IESG - which includes a slightly
different set of SASL mechanisms as Mandatory To Implement.
Our current MTI is from RFC 6120, and can be summarized
The XMPP Council will be holding it's regular meeting today (Wednesday) at
1600 UTC. The agenda is collated from (in order of reliability):
* Github pull requests and issues marked "Needs Council":
https://github.com/xsf/xeps/labels/Needs%20Council
* Random mails from Standards List
* Random
On Thu, 17 Jan 2019 at 17:41, Ненахов Андрей
wrote:
> чт, 17 янв. 2019 г. в 15:38, Ralph Meijer :
> > This is explicitly not how our standards process has been set up. The
> > idea here is that having a published document as a starting point makes
> > it more likely that people are not
On Thu, 17 Jan 2019 at 10:38, Ralph Meijer wrote:
> Unfortunately, XEP-0001 seems to require an updated version for moving
> it out of Deferred back to Experimental. I doesn't seem a reasonable
> requirement to need changes to move (indirectly) to Proposed:
>
>
I think this isn't quite right.
On Thu, 17 Jan 2019 at 09:19, Ненахов Андрей
wrote:
> I'd suggest not accepting XEPs without any kind of existing technical
> implementation in the future. If one suggests a standard extension, he
> should provide a working software that supports it.
>
>
I'm highly against this. Our process is
On Wed, 16 Jan 2019 at 20:48, Tedd Sterr wrote:
> I think the first issue is to decide the actual purpose Deferred is meant
> to be serving - according to XEP-0001, that is essentially "was
> experimental, but has had no attention for 12 months;" I don't think anyone
> has a problem with that.
On Fri, 11 Jan 2019 at 13:10, Matthew Wild wrote:
> Dear Council,
>
> I would like to request that XEP-0335 be considered for Last Call. It
> is a fairly small XEP that has implementations in the wild and
> deserves to advance in my opinion.
>
Thanks, I've added this as #733:
On Tue, 8 Jan 2019 at 18:23, Florian Schmaus wrote:
> On 08.01.19 17:00, Jonas Schäfer wrote:
> > On Dienstag, 8. Januar 2019 16:50:43 CET Georg Lukas wrote:
> >> * Jonas Schäfer [2018-12-14 16:18]:
> >>> I think adding a distinct feature is a good idea. Even if clients don’t
> >>> act on it
Yes, I think a distinct feature is needed, and that feature should indicate
support for the optimisation in §3.3.
On Fri, 14 Dec 2018 at 15:01, Georg Lukas wrote:
> Hello,
>
> I'd like to ask for a Last Call for XEP-0410. It's got implemented in
> two clients and two servers so far:
>
> -
On Tue, 8 Jan 2019 at 16:55, Jonas Schäfer wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0410.
>
> Title: MUC Self-Ping (Schrödinger's Chat)
> Abstract:
> This protocol extension for XEP-0045 Multi User Chat allows clients to
> check whether they are still joined
On Tue, 8 Jan 2019 at 16:54, Jonas Schäfer wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0280.
>
> Title: Message Carbons
> Abstract:
> In order to keep all IM clients for a user engaged in a conversation,
> outbound messages are carbon-copied to all interested
On Wed, 2 Jan 2019 at 17:07, Evgeny wrote:
> On Wed, Jan 2, 2019 at 7:49 PM, Dave Cridland wrote:
> > Out of curiosity, do we know if the cryptographic properties involved
> > in sending a known set of plaintext about like that stack up?
>
> I wonder how everyone is fixated
You'd be most welcome to write this down and submit it as a XEP - it's
really not as hard as it sounds, and you don't need to worry about too much
detail at this stage.
Out of curiosity, do we know if the cryptographic properties involved in
sending a known set of plaintext about like that stack
Hi folks,
There were two heavy chunks of "Process" in this meeting. Surprisingly, I
hate process - as anyone I've worked with can attest - but I'm usually the
one defending it, so here I go again.
The reason we have a process is not to make our lives more difficult, but
to make everyone's lives
Hi Jonas,
Thanks for sorting this out, and my apologies for the formal process hoops
to jump through.
I'm amazed this has never happened before, actually.
Dave.
On Thu, 20 Dec 2018 at 16:13, Jonas Schäfer wrote:
> Hi list,
>
>
> I published this specification (XEP-0412) ahead of time. The
Hi folks,
I'm thinking of asking the Editor to issue a Call For Experience on
XEP-0288.
I would do so now, but I'm not entirely sure who actually implements it.
So, who does implement it? (And is your implementation open source)?
Dave.
___
Standards
Looks like a problem worth solving, but note below.
I'd prefer - non blockingly - the following:
* A click element. I feel that having an id and a click is superior given
the ambiguity of a text string.
* The examples should be changed to include a Big Red Button. I think the
worthwhile gag
On Mon, 26 Nov 2018 at 12:09, Ненахов Андрей
wrote:
> пн, 26 нояб. 2018 г. в 17:02, Dave Cridland :
> >> Yes, so? Anyway we're discussing a XEP for Unique and Stable Stanza
> >> ID, and we like it as it currently is, precisely because we can count
> >> on origin-i
On Mon, 26 Nov 2018 at 11:01, Ненахов Андрей
wrote:
> пн, 26 нояб. 2018 г. в 15:12, Dave Cridland :
> > But surely if a client connects and doesn't send an origin-id, you know
> the message id might not be unique?
>
> Yes, so? Anyway we're discussing a XEP for Unique and
On Mon, 26 Nov 2018 at 10:00, Ненахов Андрей
wrote:
> пн, 26 нояб. 2018 г. в 14:48, Georg Lukas :
> > If your client is using them to associate message reflections, I am sure
> > you can make them unique client-side, right? So just because it's not
> > REQUIRED is not an argument to make it
Hi all,
Sorry about last Wednesday, unfortunately I've had a bit of a family crisis
which needed a lot of attention - it should now be in hand, but my head
hasn't really had the space to think until now.
On Thu, 15 Nov 2018 at 19:40, Tedd Sterr wrote:
>
On Sat, 13 Oct 2018, 19:10 Tedd Sterr, wrote:
> > *2) PR #706 - Update BCP 14 language to comply with RFC 8174* -
> https://github.com/xsf/xeps/pull/706
>
> I have to wonder whether "an implementation must" could mean anything
> different from "an implementation MUST" -- how else could it be
>
olution. It's not even clear to me
if any MUC clients actually use the disco#items at all. I know some *can*,
but I think only in generic "Service Discovery" UIs.
If MIX allows hundreds or thousands of participants in a channel, the MUC
disco interface is going to be pretty useless and/or del
Folks,
The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests marked "Needs Council".
* Trello at https://trello.com/b/ww7zWMlI/xmpp-council-agenda
* Random mails from Standards List
*
On Tue, 25 Sep 2018 at 18:49, Timothée Jaussoin wrote:
> I just reviewed the XEP-: MUC Avatars and I would like to discuss some
> ideas about it before proposing adjustments.
>
> The core idea of this XEP is to expose the Vcard hash in the bare MUC JID
> disco#info and notify it using a
Ralph,
As I vaguely recall, the problem wasn't disco#info clashing between MUC and
MIX - as you say, those shouldn't clash.
The problem is disco#items, where MIX and MUC use disco#items to yield
entirely different information. MUC will respond with room occupants,
whereas MIX responds with
Folks,
The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests marked "Needs Council".
* Trello at https://trello.com/b/ww7zWMlI/xmpp-council-agenda
* Random mails from Standards List
*
On 6 August 2018 at 20:07, Georg Lukas wrote:
> * Dave Cridland [2018-08-06 17:54]:
> > > I’m pending being persuaded that the PR is right, rather than the
> original
> > > issue being a typo, BTW. -1 unless someone manages that (or similar).
> >
> > The
On 6 August 2018 at 16:45, Kevin Smith wrote:
> 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
>
Folks,
The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests marked "Needs Council".
* Trello at https://trello.com/b/ww7zWMlI/xmpp-council-agenda
* Random mails from Standards List
*
On 12 July 2018 at 12:24, Florian Schmaus wrote:
> On 12.07.2018 12:39, Kevin Smith wrote:
> > 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
On 9 July 2018 at 13:30, Tedd Sterr wrote:
> One can certainly send a disco#info to server on which you don't have an
> account, and the response is as expected, but that still requires an
> account on _a_ server - so the reply can be directed to you.
>
>
This is probably the best bet. But note
On Sat, 23 Jun 2018, 12:24 Tedd Sterr, wrote:
> http://logs.xmpp.org/council/2018-06-20/#15:00:27
>
> *1) Roll Call and Sandwich Orders*
> Present: Kev, Sam, Daniel
> Stuck in endless meetings: Dave
> Deep under-cover behind enemy lines: Georg
>
So... I wasn't stuck in meetings this time,
Short answer: Yes, see the MLS work within the IETF.
On Tue, 26 Jun 2018, 15:00 Niels Ole Salscheider, <
niels_...@salscheider-online.de> wrote:
> Hi,
>
> when XEP-0384 (OMEMO) became experimental last year, it was said that it
> was
> to document what was implemented at that time in the real
On 13 June 2018 at 21:59, Tedd Sterr wrote:
> http://logs.xmpp.org/council/2018-06-13/#15:03:33
>
> Dave apologises for not preparing an agenda; apparently, having a day job
> is distracting.
>
> *1) Roll Call*
> Present: Kev, Daniel, Sam, Dave
> Away on a top-secret mission: Georg
>
*1½) Isn't
On 10 June 2018 at 06:09, Daniel Corbe wrote:
> Because it would seem to me as if one would need to read the entire stream
> one byte at a time and wait for valid input before passing the message off
> to a parser. IE, I’m looking for that final closing > before I can reply.
>
>
Eeeek.
> Is
On 6 June 2018 at 17:30, Jonas Wielicki wrote:
> On Mittwoch, 6. Juni 2018 16:52:27 CEST Sam Whited wrote:
> > I'm not af an of how this one was done. -1 for now. I'd like to discuss
> how
> > this can be done better though; it seems to me that it would fit very
> well
> > as part of extensible
On 31 May 2018 at 01:22, Tedd Sterr wrote:
> http://logs.xmpp.org/council/2018-05-30/#15:00:13
>
> *1) Roll Call* - https://en.wikipedia.org/wiki/Roll_Call
> Present: Kev, Daniel, Georg, Sam
> Better things to do: Dave
>
> *2) Isn't it nice that Tedd Sterr does the minutes?*
> There are no
Folks,
The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests marked "Needs Council".
* Trello at https://trello.com/b/ww7zWMlI/xmpp-council-agenda
* Random mails from Standards List
*
hat if I'd got a silly name for you? Or
misspelled your name? Autocorrect really hates it, after all.
These aren't technical interoperability, but they do harm to user
experience and might even be a privacy leak.
On Mon, 4 Jun 2018, 19:53 Steve Kille, wrote:
>
>
>
>
> *From:* Stand
On 4 June 2018 at 07:53, Steve Kille wrote:
> This can be a client choice. The client could show JID, or MIX provided
> Nick, or a user-assigned Nick for the participant. MIX is not mandating
> what gets shown.
>
I actually think it should have an opinion on what the client shows, at
;least
On 2 June 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,
On 4 June 2018 at 15:43, Jonas Wielicki wrote:
> I think this is a good point, and I’ve run into this quite a few times
> when
> implementing MUC. Branching on the message type where 'groupchat' is
> somehow
> special, but then again only if it does *not* come from the bare JID, and
> if
> it
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:
> >>
> >> To support IQs in MIX-CORE, there needs to be an addressing and rou
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 Kev's variant 4).
>
> The rationale for having a different scheme is
On 3 June 2018 at 15:30, Ненахов Андрей
wrote:
> To whom it may concern, we're working on group chat solution for XMPP.
>
> It is quite a simple solution that we feel is good enough to counter most
> issues of XEP-0045.
>
> It is quite simple:
>
>- Group chat is listed in a roster, we use
On 4 June 2018 at 09:28, Kevin Smith wrote:
> 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
On 2 June 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
On 1 June 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 presence should come
> from the channel’s JID,
301 - 400 of 1591 matches
Mail list logo
