> Appserver might take notice that app didn't wake up after three
> content-update notification and send an alert notification on fourth
> attempt. We don't do that, however.
Well, that wouldn't make for good UX at all. Push notifications are sent for
non-body messages, too. Having an alert
On Tue, 2 Oct 2018, 22:32 Thilo Molitor, wrote:
> The appserver can not know which message has high priority and which one
> is low priority without the xmpp server telling it.
>
Appserver might take notice that app didn't wake up after three
content-update notification and send an alert
On Tue, 2 Oct 2018, 22:33 Sam Whited, wrote:
> On Tue, Oct 2, 2018, at 11:59, Ненахов Андрей wrote:
> > However, we do transmit account UUID in push notification, because a
> > client might often have more than one XMPP account, and it is a bad
> > idea to wake up all of them and check for
On Tue, Oct 2, 2018, at 11:59, Ненахов Андрей wrote:
> However, we do transmit account UUID in push notification, because a
> client might often have more than one XMPP account, and it is a bad
> idea to wake up all of them and check for content updates.
Why is that? The radio is already awake
The appserver can not know which message has high priority and which one is low
priority without the xmpp server telling it.
And for this to work the XEP has to be updated with a new field or the
last-message field has to be reused for this (that's what current
implementations do).
Content
вт, 2 окт. 2018 г. в 21:28, Thilo Molitor :
>
> This XEP needs at least a note discouraging the use of the fields "message-
> sender" and "message-body" because of privacy implications.
Indeed, we found out that best practice is to omit any personal
information in a message, no counters,
On Tue, Oct 2, 2018, at 11:29, Ненахов Андрей wrote:
> This is an extremely essential XEP, it is widely used in clients and
> servers alike. This should be moved to Draft, too.
I tend to agree. See also: the council minutes that just went out :)
We'll discuss and possibly recommend that the
This is an extremely essential XEP, it is widely used in clients and
servers alike. This should be moved to Draft, too.
вт, 2 окт. 2018 г. в 18:52, Jonas Schäfer :
>
> XEP-0359 (Unique and Stable Stanza IDs) has been Deferred because of
> inactivity.
>
> Abstract:
> This specification describes
вт, 2 окт. 2018 г. в 20:14, Sam Whited :
>
> On Tue, Oct 2, 2018, at 10:05, Ненахов Андрей wrote:
> > Is this enough, or is there some sort of special procedure for a nomination?
>
> Nope, there's no sort of special procedure (that I'm aware of). I've added it
> to the council agenda and we will
This XEP needs at least a note discouraging the use of the fields "message-
sender" and "message-body" because of privacy implications.
In the wild the field "message-body" is left empty for low priority pushes (in
short: pushes not related to message stanzas containing a body) and set to
This sounds interesting.
Did someone implement it?
Thilo
Am Dienstag, 2. Oktober 2018, 13:49:51 CEST schrieb Jonas Schäfer:
> XEP-0390 (Entity Capabilities 2.0) has been Deferred because of
> inactivity.
>
> Abstract:
> This document overhauls the XMPP protocol extension Entity
> Capabilities
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, Oct 2, 2018, at 10:05, Ненахов Андрей wrote:
> Is this enough, or is there some sort of special procedure for a nomination?
Nope, there's no sort of special procedure (that I'm aware of). I've added it
to the council agenda and we will discuss it sometime in the next few weeks
вт, 2 окт. 2018 г. в 19:47, Sam Whited :
>
> On Tue, Oct 2, 2018, at 09:08, Ненахов Андрей wrote:
> > Could someone please explain logic behind XSF workflow? 'Inactivity'? How
> > exactly do you measure that, no updates to XEP?
>
> That's correct, no updates for 12 months when in the experimental
On Dienstag, 2. Oktober 2018 16:08:23 CEST Ненахов Андрей wrote:
> Could someone please explain logic behind XSF workflow? 'Inactivity'? How
> exactly do you measure that, no updates to XEP?
>
> We use XEP-0357 to send notifications to Xabber iOS, Web and Android, and
> it's kinda not ok for it
On Tue, Oct 2, 2018, at 09:08, Ненахов Андрей wrote:
> Could someone please explain logic behind XSF workflow? 'Inactivity'? How
> exactly do you measure that, no updates to XEP?
That's correct, no updates for 12 months when in the experimental stage.
> We use XEP-0357 to send notifications to
Could someone please explain logic behind XSF workflow? 'Inactivity'? How
exactly do you measure that, no updates to XEP?
We use XEP-0357 to send notifications to Xabber iOS, Web and Android, and
it's kinda not ok for it to be just gone for no reason.
On Tue, 2 Oct 2018, 18:52 Jonas Schäfer,
Version 0.5 of XEP-0392 (Consistent Color Generation) has been
released.
Abstract:
This specification provides a set of algorithms to consistently
generate colors given a string. The string can be a nickname, a JID or
any other piece of information. All entities adhering to this
specification
XEP-0390 (Entity Capabilities 2.0) has been Deferred because of
inactivity.
Abstract:
This document overhauls the XMPP protocol extension Entity
Capabilities (XEP-0115). It defines an XMPP protocol extension for
broadcasting and dynamically discovering client, device, or generic
entity
XEP-0389 (Extensible In-Band Registration) has been Deferred because
of inactivity.
Abstract:
This specification defines an XMPP protocol extension for in-band
registration with instant messaging servers and other services with
which an XMPP entity may initiate a stream. It aims to improve upon
XEP-0388 (Extensible SASL Profile) has been Deferred because of
inactivity.
Abstract:
This document describes a replacement for the SASL profile documented
in RFC 6120 which allows for greater extensibility.
URL: https://xmpp.org/extensions/xep-0388.html
If and when a new revision of this XEP
XEP-0379 (Pre-Authenticated Roster Subscription) has been Deferred
because of inactivity.
Abstract:
This document defines a protocol and URI scheme for pre-authenticated
roster links that allow a third party to automatically obtain the
user's presence subscription. The goal of this is to make
XEP-0357 (Push Notifications) has been Deferred because of inactivity.
Abstract:
This specification defines a way for an XMPP servers to deliver
information for use in push notifications to mobile and other devices.
URL: https://xmpp.org/extensions/xep-0357.html
If and when a new revision of
XEP-0359 (Unique and Stable Stanza IDs) has been Deferred because of
inactivity.
Abstract:
This specification describes unique and stable IDs for messages.
URL: https://xmpp.org/extensions/xep-0359.html
If and when a new revision of this XEP is published, its status will
be changed back to
XEP-0278 (Jingle Relay Nodes) has been Deferred because of inactivity.
Abstract:
This documents specifies how Jingle Clients can interact with Jingle
Relay Nodes Services and how XMPP entities can provide, search and
list available Jingle Relay Nodes.
URL:
25 matches
Mail list logo
