Hello,
Le lundi 14 janvier 2019, 02:41:57 CET Tedd Sterr a écrit :
> 3) Proposed XMPP Extension: Order-By -
> https://xmpp.org/extensions/inbox/order-by.html
>
> Georg thinks it's a very specific use case, and defines two hard-coded
> properties (creation and modification timestamp) for
2018-12-19 (expired 2019-01-02)
PASSED (-0:1:+4) Last Call: XEP-0410 (MUC Self-Ping (Schrödinger's Chat)) -
https://xmpp.org/extensions/xep-0410.html
2019-01-09 (expiring 2019-01-23)
Proposed XMPP Extension: Order-By -
https://xmpp.org/extensions/inbox/order-by.html
Dave: +0 (reserve the
http://logs.xmpp.org/council/2019-01-09/#16:00:55
Dave got around to writing an agenda, though it seems to have been missed by
many as it was not sent to 'standards', but only to the 'council' mailing list
(to which Jonas is, curiously, not subscribed - Kev offers to do the magic.)
1) Roll
On 2019/01/12, Jonas Schäfer wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0345.
>
> Note: Since this is a Procedural XEP under control of Board, the Last Call
> mail goes to both standards@ and members@ (only for XSF members) mailing
> lists. This may lead to
On Sonntag, 13. Januar 2019 17:33:38 CET Ненахов Андрей wrote:
> There is, however, a really big problem that no one seems to be
> talking about - it's not the protocol, but accompanying behaviour.
> Simple example: subscription request. It looks like very simple, but
> it's not. It is more or
On Sonntag, 13. Januar 2019 16:50:24 CET Jonas Schäfer wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Cryptographic Hash Function Recommendations for XMPP
> Abstract:
> This document provides recommendations for the use of cryptographic
> hash functions in
I have an issue with these compliance suites. I think for the most
part it's a pointless bureaucracy. Just listing XEPs makes it an
artificial metric that can be gamed easily. Typically if XMPP client
supports just one tiny part of a XEP, app developer immediately claims
this XEP support. We did
On Sonntag, 13. Januar 2019 17:02:21 CET Ненахов Андрей wrote:
> > Changelog:
> > * Remove XEP-0184 from server support (doesn't make sense)
>
> Actually, it does. Currently, when you start up a client (after some
> time offline or just a first start of an app) you don't have any
> information if
> Changelog:
> * Remove XEP-0184 from server support (doesn't make sense)
Actually, it does. Currently, when you start up a client (after some
time offline or just a first start of an app) you don't have any
information if message was delivered to or read by you chat partner.
This is massive
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Cryptographic Hash Function Recommendations for XMPP
Abstract:
This document provides recommendations for the use of cryptographic
hash functions in XMPP protocol extensions.
URL:
Version 0.4.0 of XEP-0412 (XMPP Compliance Suites 2019) has been
released.
Abstract:
This document defines XMPP protocol compliance levels.
Changelog:
* Fix mess-up with TLS: TLS itself is of course required, it is just
Direct TLS which is supposed to be advanced.
* Add XEP-0308 (Last Message
On Sonntag, 13. Januar 2019 16:12:04 CET Sam Whited wrote:
> On Sun, Jan 13, 2019, at 11:26, Jonas Schäfer wrote:
> > On Mittwoch, 12. Dezember 2018 18:05:26 CET Georg Lukas wrote:
> > > * Jonas Schäfer [2018-12-08 20:06]:
> > > > Title: XMPP Compliance Suites 2019
> > >
> > > thanks for taking
On Sun, Jan 13, 2019, at 11:26, Jonas Schäfer wrote:
> On Mittwoch, 12. Dezember 2018 18:05:26 CET Georg Lukas wrote:
> > * Jonas Schäfer [2018-12-08 20:06]:
> > > Title: XMPP Compliance Suites 2019
> >
> > thanks for taking up the work!
> > Some remarks:
> >
> > IMO XEP-0184 is sufficiently
Le dimanche 13 janvier 2019, 12:53:51 CET Evgeny a écrit :
> On Sun, Jan 13, 2019 at 2:40 PM, Goffi wrote:
> > Future XEPs may extend this, but in case where it's too complicated,
> > implementation has always the choice to not implement it, or to have
> > different features with different
On Sun, Jan 13, 2019 at 2:40 PM, Goffi wrote:
Future XEPs may extend this, but in case where it's too complicated,
implementation has always the choice to not implement it, or to have
different features with different backends.
I really don't see how this will work in practice.
1) a client
Le dimanche 13 janvier 2019, 12:28:09 CET Evgeny a écrit :
> On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote:
> > For Pubsub services based on SQL or NoSQL databases, it should not be
> > too hard to implement as ordering is most of time a part of API.
>
> Note however, that some NoSQL databases
Version 0.2.0 of XEP-0412 (XMPP Compliance Suites 2019) has been
released.
Abstract:
This document defines XMPP protocol compliance levels.
Changelog:
* Remove XEP-0184 from server support (doesn't make sense)
* Do not require Avatars for Core clients
* Add a note for RFC 7622 and do not require
Version 0.3 of XEP-0367 (Message Attaching) has been released.
Abstract:
This specification defines a method for indicating that a message
contains content which describes an earlier message in the
conversation and should be grouped with the earlier message.
Changelog:
Update to use unique
Version 0.2.1 of XEP-0394 (Message Markup) has been released.
Abstract:
This specification provides an alternative to XHTML-IM with rigid
separation of content and markup information, improving the resilience
against spoofing and injection attacks.
Changelog:
Adopt deferred XEP. (kks)
URL:
Le dimanche 13 janvier 2019, 12:24:45 CET Evgeny a écrit :
> On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote:
> > a XEP for XPATH like syntax
>
> And the server will process this XPATH query?
> Not sure if you're serious...
This is a future plan, not concerning the current proposal, and will be
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 all votes have been made, and has literally no idea what do
> > to about it as there is no
On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote:
For Pubsub services based on SQL or NoSQL databases, it should not be
too hard to implement as ordering is most of time a part of API.
Note however, that some NoSQL databases only support a single index
in the query, DynamoDB is such an example.
On Mittwoch, 12. Dezember 2018 18:05:26 CET Georg Lukas wrote:
> * Jonas Schäfer [2018-12-08 20:06]:
> > Title: XMPP Compliance Suites 2019
>
> thanks for taking up the work!
> Some remarks:
>
> IMO XEP-0184 is sufficiently important to become IM-Core, not just
> IM-Advanced.
I don’t think so.
On Montag, 24. Dezember 2018 13:30:04 CET Georg Lukas wrote:
> * Georg Lukas [2018-12-12 18:07]:
> > There are some pet XEPs I have that I'd like to integrate:
> And another one:
>
> Advanced IM Client: XEP-0333: Chat Markers
> (should also be used/usable for inter-client read-state sync)
I
On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote:
a XEP for XPATH like syntax
And the server will process this XPATH query?
Not sure if you're serious...
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe:
Hello,
I've read the council logs, I'll try to defend the protoXEP here (in addition
to what has already been said in this thread).
> it's a very specific use case, and it defines two hard-coded properties to
> order by. A clean approach would allow ordering by any field of the items,
>
Hi Wiktor,
On Freitag, 4. Januar 2019 11:48:23 CET Wiktor Kwapisiewicz wrote:
> Hello,
>
> I have noticed that XEP-0363: HTTP File Upload was recently updated with
> recommendations that make it possible to use from a web client, notably CORS
> headers. [0]
>
> [0]:
On Freitag, 11. Januar 2019 23:09:05 CET Sam Whited wrote:
> Hi,
>
> It's 2019 now, and we're back in the situation of having two compliance
> suites published, where the one that appears to be recommended doesn't seem
> to be current. This is a very confusing situation.
>
> Please consider
On Sonntag, 13. Januar 2019 11:41:01 CET Goffi wrote:
> Le samedi 12 janvier 2019, 20:50:25 CET Jonas Schäfer a écrit :
> > […]
> > The lack of clock synchronisation is a problem in any case, even when the
> > timestamps are generated on the server side, since XMPP is federated. I’d
> > even argue
Le samedi 12 janvier 2019, 20:50:25 CET Jonas Schäfer a écrit :
> They do, here’s how: You have two metadata fields, let’s call them Time and
> Author. You have the following data:
>
> Time Author Item ID
> 10:00 Alice1
> 11:00 Alice2
> 12:00 Bob 3
> 13:00 Bob 4
> 14:00
30 matches
Mail list logo
