This message constitutes notice of a Last Call for comments on
XEP-0334.
Title: Message Processing Hints
Abstract:
This document defines a way to include hints to entities routing or
receiving a message.
URL: https://xmpp.org/extensions/xep-0334.html
This Last Call begins today and shall end at the close of business on
2024-04-08.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
Version 0.4.1 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:
* Add missing elements to XML Schema
* Add missing XMPP Registrar Considerations (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.5.0 of XEP-0334 (Message Processing Hints) has been
released.
Abstract:
This document defines a way to include hints to entities routing or
receiving a message.
Changelog:
Incorporate last call feedback from 2017.
Differences between this specification and XEP-0079 have been
clarified.
A note about handling of hints found in error stanzas has been added.
(mw)
URL: https://xmpp.org/extensions/xep-0334.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.
This message constitutes notice of a Last Call for comments on
XEP-0360.
Title: Nonzas (are not Stanzas)
Abstract:
This specification defines the term "Nonza", describing every top
level stream element that is not a Stanza.
URL: https://xmpp.org/extensions/xep-0360.html
This Last Call begins today and shall end at the close of business on
2024-03-25.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
Version 0.6.0 of XEP-0333 (Displayed Markers (was: Chat Markers)) has
been released.
Abstract:
This specification introduces a method to let the sender, or multiple
participants in a group chat, know that a client has displayed
messages up to a certain point.
Changelog:
* Add Business Rule about opportunistic Displayed Markers in 1:1 chats
(dg)
URL: https://xmpp.org/extensions/xep-0333.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.
This message constitutes notice of a Last Call for comments on
XEP-0388.
Title: Extensible SASL Profile
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
This Last Call begins today and shall end at the close of business on
2024-04-01.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
This message constitutes notice of a Last Call for comments on
XEP-0386.
Title: Bind 2
Abstract:
This specification provides a single-request replacement for several
activities an XMPP client needs to do at startup.
URL: https://xmpp.org/extensions/xep-0386.html
This Last Call begins today and shall end at the close of business on
2024-04-01.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
I have setup the membership application Wiki page for the application
period Q2 2024
Applications are encouraged from developers and others who are actively
involved in the Jabber/XMPP community. To apply, create a page about
yourself on the Wiki:
https://wiki.xmpp.org/web/Membership_Applications_Q2_2024
If you don't have a wiki account, send your full name, preferred
nickname and email address to me or one of the other Sysops:
https://wiki.xmpp.org/web/Sysops
Apply now!!!
Thanks,
Alex
Version 0.2.1 of XEP-0428 (Fallback Indication) has been released.
Abstract:
This specification proposes a mechanism by which message bodies or
parts thereof can be marked as being for fallback purposes, and
therefore to be ignored by anything that understands the original
intent of the message.
Changelog:
Change integer type of region start and end attributes in schema to
xs:unsignedInt. (lnj)
URL: https://xmpp.org/extensions/xep-0428.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.
Hi Matthew,
On Thu, Feb 23, 2017 at 1:53 PM Matthew Wild <mwild1(a)gmail.com> wrote:
>
> On 8 February 2017 at 23:47, Christian Schudt <christian.schudt(a)gmx.de> wrote:
> >
> >> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
> >
> > Partly.
> > XEP-0079: Advanced Message Processing already solves the same problem.
> >
> > drop forward => no-copy
> > drop stored => no-store
> >
>
> Maybe the document should go into more detail regarding differences
> with AMP. Some notes:
>
> - You can implement both specifications if desired
> - Over 10 years after publication, XEP-0079 is not widely
> implemented, I believe this is largely due to its complexity
> - XEP-0079 requires multiple discovery steps before you can actually
> send a message
> - XEP-0079 is relatively difficult to re-use in other XEPs
> - Lots of edge cases, e.g. interaction with MUC rooms. With hints the
> server is still free to choose the most sensible option given the info
> it has.
Council has Issued another Last Call on 0334¹ and I've been going over
the feedback from the last Last Call.
The Editor will start the Last Call next Monday.
I think it received mostly positive feedback back then and I have no
reason to believe it won’t pass Last Call this time.
However I think you were right that the document should go into more
detail regarding differences with AMP.
Furthermore a little down the thread Dave had feedback wrt hints in
Error messages:
"I noted that messages of type error are explicitly called out in §4.4,
however I think there needs to be a general rule that hints SHOULD be
ignored in messages of type='error'. Possibly MUST. Errors are
sometimes generated by bouncing the entire stanza, including original
contents, back to the sender, and these original contents might
include a hint; it seems sensible to always ignore these."
that also sounds like a sensible addition to me.
Maybe you have the time to make those changes before Last Call even
starts (next Monday)
Thank You
cheers
Daniel
¹: On February 8th 2023
