Version 1.2.3 of XEP-0167 (Jingle RTP Sessions) has been released.
Abstract:
This specification defines a Jingle application type for negotiating
one or more sessions that use the Real-time Transport Protocol (RTP)
to exchange media such as voice or video. The application type
includes a straightforward mapping to Session Description Protocol
(SDP) for interworking with SIP media endpoints.
Changelog:
Make 'ssrc' attribute 'xs:unsignedInt' (32-bit) instead of 'xs:string'
to match RFC3550. (lnj)
URL: https://xmpp.org/extensions/xep-0167.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Version 0.4.0 of XEP-0455 (Service Outage Status) has been released.
Abstract:
This document defines an XMPP protocol extension that enables server
administrators to communicate issues with the server to all users in a
semantic manner.
Changelog:
Remove leftover pubsub references, add accessibility considerations.
(mp)
URL: https://xmpp.org/extensions/xep-0455.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Version 1.0.4 of XEP-0388 (Extensible SASL Profile) has been released.
Abstract:
This document describes a replacement for the SASL profile documented
in RFC 6120 which allows for greater extensibility.
Changelog:
Schema should use all instead of sequence (dg)
URL: https://xmpp.org/extensions/xep-0388.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Version 0.3.0 of XEP-0317 (Hats) has been released.
Abstract:
This specification defines a more extensible model for roles and
affiliations in Multi-User Chat rooms.
Changelog:
Add hat creation and detruction flows; add hue optional parameter; add
chatroom presence hats broadcast; complete disco#info; clarify how the
service should broadcast updated hats; typos; standardize the form
fields; (tj)
URL: https://xmpp.org/extensions/xep-0317.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Version 1.6.3 of XEP-0198 (Stream Management) has been released.
Abstract:
This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including
features for stanza acknowledgements and stream resumption.
Changelog:
Remove leftover <optional/> and <required/> children in <sm/> element.
(egp)
URL: https://xmpp.org/extensions/xep-0198.html
Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
Hello Schimon (etl al)
> I am working on a news service for XMPP, which sends messages according
> to status.
>
> When JID is offline, service should stop.
Sounds like you would benefit from using PEP (XEP-0163) which accomplishes this. The publisher publishes a PEP event with its new service namespace, and only online entities with a presence subscription, and a corresponding service-detectable feature requesting PEP events with the corresponding news namespace, will receive the event. In this case, there's no need for the service to manually check subscribers and their current online presence.
Best regards,
Peter Waher
Good day.
I am working on a news service for XMPP, which sends messages according
to status.
When JID is offline, service should stop.
Resources
---------
As XMPP is presence oriented, it is needed to set extra measures, such
as collecting detected resources, in order to be certain that a subject
JID is indeed offline.
This measure is still tested.
Signals
-------
I am experimenting with XEP-0199: XMPP Ping as a possible mean to
confirm that an account is offline.
However, while asking for a pong signal from a full JID (JID with a
resource) returns an empty respond, asking for a pong signal appear to
always to work when querying a bare JID (JID without a resource).
PONG: sch(a)pimux.de/gajim.TN7Y65AS None
PONG: sch(a)pimux.de 0.09115195274353027
PONG: sch(a)pimux.de/gajim.TN7Y65AS None
PONG: sch(a)pimux.de 0.10207772254943848
My expectation was to have no respond for bare JID, when there is no
connected instance to a given JID.
Please advise.
Kind reagrds,
Schimon
Good day.
I would want to ask the XSF members to reconsider XEP-0146 for a couple
of reasons.
* To educate and inform people of Ad-Hoc Commands, a feature which is
exclusive to XMPP.
* To control other clients when special situationn arises.
For several days I have a connected XMPP client instance from my Movim
instance which indicates that my JID is available, even though I deem
that it should be offline.
https://xmpp.org/extensions/xep-0146.xml
XEP-0146: Remote Controlling Clients
Kind regards,
Schimon
Good day.
Question
========
Is it possible for XMPP clients to actively probe for presence?
JabberCard
==========
I have created JabberCard, an HTML invitation page for XMPP.
https://git.xmpp-it.net/sch/JabberCardhttps://git.0ut0f.space/doesnm/JabberCard
JabberCard is based on the module Slixmpp and is an XMPPP client.
Idea
====
Months ago, I was advised to add support for status, mood, and activity.
I think that it is a good idea.
Presence
========
However, it appears that actively probing for presence by XMPPP clients
is not specified in the standard.
According to the standard, only servers handle that task.
4.3. Presence Probes
> Presence probes SHOULD NOT be sent by a client, because in general a
> client will not need to send them since the task of gathering
> presence from a user's contacts is managed by the user's server.
> However, if a user's client generates an outbound presence probe then
> the user's server SHOULD route the probe (if the contact is at
> another server) or process the probe (if the contact is at the same
> server) and MUST NOT use its receipt of the presence probe from a
> connected client as the sole cause for returning a stanza or stream
> error to the client.
https://xmpp.org/rfcs/rfc6121.html#presence-probe
Is it possible for XMPP clients to actively probe for presence?
Please advise.
Kind regards,
Schimon
Good day.
I have a question concerning to preferable practice in JID recognition.
Preface
-------
I am working on an XMPP service (i.e. "bot") for both private and group
chat. I utilize Slixmpp for that task.
Slixmpp
-------
Slixmpp has a "reply" function which automatically classifies the task,
due to information which is attached to IQ Stanza.
Concern
-------
However, when the service actively sends schedule messages, it needs to
classify the given JID to which it sends a message.
Database
--------
I have recently decided to classify subscribers of the service inside a
database, which also has fields of Private, MIX, and MUC.
Disco
-----
I was wondering whether should query JID addresses using "disco" (i.e.
XEP-0030: Service Discovery), or should I utilize the database?
Utilizing "disco" is prone to errors (e.g. when server blocks another
server - displaying "recepient-unavailable" - yet contacts can still
communicate).
Conclusion
----------
Please advise.
Kind regards,
Schimon
