[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))
On Sun, 10 Mar 2024 at 15:19, Daniel Gultsch wrote: > 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@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? > > No. Many of you have heard my views on this before. I argued against this XEP from the outset and I have seen nothing to change my view. Sorry for rehashing this argument, for those of you who have heard me on this before, but I still feel strongly that this is a very poor idea. Introducing new words - not just new terms, but new collections of letters that have previously never had a meaning at all - seems like a very poor way to make specifications (and simply our technology) more approachable. I have always avoided this new word, and will continue to do so, as the rare specification that introduces a new top-level element will never be made more simple by saying "This specification adds a new furbley bloople ding dong - now go and read XEP-0987 for an entire document on what this might mean.". As an industry, we are rightly chastised for introducing pointless jargon. It is a clear barrier to entry for newcomers, and should always be avoided. The situation becomes even worse in the circumstances of a chatroom or conversation, by making it more impenetrable that it likely already is. Casual conversations do not have convenient footnotes and reference sections. Of course jargon inevitably accumulates - stanza is an obvious example, but if I mention CSI, or PEP most people on this list will know what those mean - but these are essentially shorthands for a large volume of information. This specification simply introduces a word for top-level elements that are not stanzas. That's six words to cover the entire XEP. The rest of the XEP just adds additional words. These are sometimes questionable, and other times useless. Section 4 says that usually, top-level elements that are not stanzas that are exchanged prior to resource binding are request-response. And after resource binding, they're usually not request/response. Though in fact, some of the most common examples are the reverse - XEP-0198 uses and exchanges, whereas has no response as such. Section 5 tells me that top-level elements that aren't stanzas MUST NOT be routed. So, wait - a server that's compliant to this won't route these elements? OK. And if a server isn't compliant to this, what does this mean? These are not interoperability requirements, these are just statements of fact. Stanzas being routable top-level elements, it is axiomatic that a top-level element that is not a stanza is not routed. We do not need to wave an RFC 2119 statement around to ensure this is the case. Is a server that offers XEP-0114 not compliant with XEP-0360, since XEP-360 references only RFC 6120? Or do we use the informal definition that talks about "element name" - does this mean the local name? Does this mean that a top-level element of is in fact a Stanza by the definition of XEP-0360? None of this serves - or can serve - to clarify an existing protocol to a new reader. > 2. Does the specification solve the problem stated in the introduction > and requirements? > > I dispute there was ever a problem, whereas it has added a new problem by its existence. As I recall, one of the suggested problems was that people might be confused about what top-level elements to count in XEP-0198, maybe around whether to count CSI elements - yet neither specification has ever introduced the term. > 3. Do you plan to implement this specification in your code? If not, > why not? > > I have never used the new word in a specification I have written or contributed to, and will continue to avoid doing so. "This specification introduces a new top-level element , qualified by the urn:xmpp:bar:0 namespace - it is not routable and MUST NOT be considered a stanza." Infinitely simpler, and usually overkill. > 4. Do you have any security concerns related to this specification? > My concerns are not security related. > 5. Is the specification accurate and clearly written? > > Anything that introduces a new made-up word cannot, almost by definition, count as clearly written. > Your feedback is appreciated! > ___ > Standards mailing list -- standards@xmpp.org > To unsubscribe send an email to standards-le...@xmpp.org > ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to
[Standards] Re: Proposed XMPP Extension: Message Displayed Synchronization
On Mon, Mar 11, 2024 at 6:43 PM Stephen Paul Weber wrote: > > >* The server assist was added because of the feature request that the > >server parses . However > >this puts unnecessary burden on the server because the server then has > >to look up the stanza-id from the message-id (which is used by > >Displayed Markers (Chat Markers)). So with that feature request / > >requirement in mind NOT allowing otherwise empty messages doesn’t take > >anything away. > > I would ideally prefer this burden on the server over the way it is specced > now, but there would need to be some way for the server to know that eg in > MUC the id is in fact the stanza id vs doing the lookup in MAM for non-MUC. What you are proposing depends on the message being archived. The specification as written notably does not. cheers Daniel ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))
On Montag, 11. März 2024 10:14:36 CET Daniel Gultsch wrote:
> On Sun, Mar 10, 2024 at 4:18 PM Daniel Gultsch wrote:
> > This message constitutes notice of a Last Call for comments on
> > XEP-0360.
> > […]
> > Please consider the following questions during this Last Call and send
> > your feedback to the standards@xmpp.org discussion list:
> >
> > 1. Is this specification needed to fill gaps in the XMPP protocol
> > stack or to clarify an existing protocol?
>
> I’m honestly not convinced that the problem the XEP introduces "This
> leads to the unfortunate situation where some submitted XEPs erroneous
> refer to non-Stanza top level stream elements as 'Stanzas'." exists.
> Or if introducing a new term fixes the issue. We have terminology
> ("element", "stream element") for that.
The issue I have with the "stream element" terminology is that it may also
include Stanzas. Sometimes, we need to talk about things which are stream
elements, but not Stanzas. Having an agreed-upon word for that is useful, IMO.
> I briefly checked with some
> XEPs (Bind 2, SM, CSI) and they all seem to be fine without this new
> term.
Actually, looking at Stream Management (XEP-0198), I think it benefits from a
clear definition of what a Stanza even is.
RFC 6120 doesn't clearly state whether *only* the elements defined by RFC 6120
are stanzas. The text is at least ambiguous. To quote the introduction of RFC
6120 section 8:
> Three kinds of XML stanza are defined for the 'jabber:client' and
> 'jabber:server' namespaces: , , and . In addition,
> there are five common attributes for these stanza types. These common
> attributes, as well as the basic semantics of the three stanza types, are
> defined in this specification; more detailed information regarding the
> syntax of XML stanzas for instant messaging and presence applications is
> provided in [XMPP-IM], and for other applications in the relevant XMPP
> extension specifications.
(In addition to that, note the comments by pep in regards to XEP-0114.)
To me, it's not fully clear that this is the complete definition of the word
Stanza. And Stream Management only uses that term, which means that depending
on your interpretation of RFC 6120, you may be counting Nonzas, such as CSI
changes.
Even if we consider Nonzas worth counting (I'm not sure they are, and there's
certainly a loop to avoid with / in '198), that should be spelled
out clearly.
> Also - and this is probably something that might have changed since
> this XEP was first introduced - we don’t have that many XEPs that use
> custom stream elements after bind (after routing is enabled). CSI and
> SM seem to be the only major one. We didn’t see an influx in them.
True. Nontheless worth documenting, don't you think?
kind regards,
Jonas
signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Message Displayed Synchronization
* The server assist was added because of the feature request that the server parses . However this puts unnecessary burden on the server because the server then has to look up the stanza-id from the message-id (which is used by Displayed Markers (Chat Markers)). So with that feature request / requirement in mind NOT allowing otherwise empty messages doesn’t take anything away. I would ideally prefer this burden on the server over the way it is specced now, but there would need to be some way for the server to know that eg in MUC the id is in fact the stanza id vs doing the lookup in MAM for non-MUC. signature.asc Description: PGP signature ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Message Displayed Synchronization
On Mon, Mar 11, 2024 at 4:28 PM Jonas Schäfer wrote: > - Server assist should specify exactly when the modification of the > stanza happens. In particular, the interaction with MAM, Carbons and > potentially IM-NG should be spelled out (i.e.: is the xmlns="..mds.."/> part of the archive and/or the carbons reflection?). You are right. I will prepare wording to be added after the XEP has been accepted. > - Server assist could be extended to make the server discard the message iff > the element is the only content in that message. > That way, server assist could also be used with non-contacts or similar > situations. I’m against this for the following reasons. * The server assist was added because of the feature request that the server parses . However this puts unnecessary burden on the server because the server then has to look up the stanza-id from the message-id (which is used by Displayed Markers (Chat Markers)). So with that feature request / requirement in mind NOT allowing otherwise empty messages doesn’t take anything away. * It is not that hard to just do a regular PEP publish * Overloading the semantic of "sending a stanza to x" with "performing an operation on the account that involves x" is a slippery slope that I’m really trying to avoid. I don’t want to set precedence to for example to use "" to block "foo". This has come up in the group chat before. Maybe I'll add something to the Design Considerations cheers Daniel ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Remove requirement to send disco#info feature in XEP-0030
>From XEP-0001, regarding Final XEPs, "limited modifications may be made as >long as they are optional, backwards-compatible extensions rather than >modifications to the core protocol itself." XEP-0030 requires that entities return "one or more elements and one or more elements", so the otherwise redundant 'disco#info' feature ensures this will always be the case, even in the (seemingly unlikely) situation where an entity somehow supports disco#info without supporting any additional features. So, is removing the requirement for this feature an optional, backwards-compatible extension? An obvious, and maybe more realistic, retort is "but will it break anything?" So, would it cause problems for implementations if they were to receive a reply containing zero features (since they were originally implemented expecting there will always be at least one)? Equally, would implementations have problems calculating the caps hash (XEP-0115) with zero features (the algorithm doesn't explicitly account for this)? It's also worth considering whether leaving it as-is causes harm. It's nice (desirable, even) to clean things and remove 'warts' like this, and there are likely many more scattered throughout the protocol, so it's worth noting for XMPP 2.0, but this has been the status quo for 22 years without being an issue. As for benefits: many implementations would now be 'correct' for not complaining when the feature isn't present (if implementations don't follow the specification, just change the specification); and there is a minor reduction in data transferred from having one less feature, though that's less notable where XEP-0115 is used (and there may be an initial increase caused by most hashes now being unknown, until that settles.) (Semi-relevant: https://github.com/xsf/xeps/pull/961 ) ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Remove requirement to send disco#info feature in XEP-0030
On Montag, 11. März 2024 12:41:17 CET Florian Schmaus wrote: > On 10/03/2024 17.27, Jonas Schäfer wrote: > > Dear community, > > > > it's been a while I spoke up here. > > > > I would like to discuss the removal of the following part-sentence from > > > > XEP-0030 (in Final status!): > >> every entity MUST support at least the > >> 'http://jabber.org/protocol/disco#info' feature > > I agree that this is a wart of the specification, but personally, I am > not sure if the its worth fixing it. That said, I do not have a strong > opinion on that. However, I want to point out that… > > > Announcing that feature is redundant: An entity which replies with a > > properly constructed ` > xmlns="http://jabber.org/protocol/disco#info"/>` element is bound to (and > > has always been bound to) have implemented XEP-0030 to the best of its > > knowledge. > > > > As this is a Final(!) status XEP, here is my estimate of the impact this > > change has: > > > > - Implementations which required the presence of this feature on the > > > >receiving side would now become non-compliant: They might assume > >that the remote entity did not really support XEP-0030 and fail with > >an error. > > > >Such implementations would need to be adapted in order to be able to > >interoperate with implementations which follow a revised version of > >XEP-0030. > > > > I don't see any other impact. > > ...there is another impact regarding the caps cache: the footprint of > the caps cache would increase, at least during the period where old > versions announce the feature, while the updated implementation may not. > Furthermore, implementations that persist the caps cache would end up > with more-or-less useless entries (which will eventually be pushed out > of the cache). > > That itself is probably not a big deal, but it nicely demonstrates that > it is often hard to understand the full impact of a change. I did actually consider that, but found it negligible; I wouldn't expect implementations which already emit it to drop the disco#info feature deliberately, or if they do, it's unlikely that it happens without other changes which may in turn add/remove other feature vars anyway. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Message Displayed Synchronization
Hello list, daniel, On Samstag, 9. März 2024 21:15:16 CET dan...@gultsch.de wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Message Displayed Synchronization > Abstract: > This specification allows multiple clients of the same user to > synchronize the displayed state of their chats. > > URL: https://xmpp.org/extensions/inbox/xep-mds.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. I would like to point out two things in regards to this specification: - Server assist should specify exactly when the modification of the stanza happens. In particular, the interaction with MAM, Carbons and potentially IM-NG should be spelled out (i.e.: is the part of the archive and/or the carbons reflection?). - Server assist could be extended to make the server discard the message iff the element is the only content in that message. That way, server assist could also be used with non-contacts or similar situations. Thanks for the spec! kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] XMPP Council Agenda 2024-03-12
Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, March 12 2024 at 16:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update * Proposed XMPP Extension: Message Displayed Synchronization * LAST CALL: XEP-0392 (Consistent Color Generation) * LAST CALL: XEP-0360 (Nonzas (are not Stanzas)) and a bunch more updates. check your email 4) Items for voting a) Proposed XMPP Extension: Message Displayed Synchronization (https://xmpp.org/extensions/inbox/xep-mds.html) 5) Pending votes * Travis on XEP-0313: Add XEP-0136 to superseded specifications See the all new spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfaRQb5Atdg/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Remove requirement to send disco#info feature in XEP-0030
On 10/03/2024 17.27, Jonas Schäfer wrote: Dear community, it's been a while I spoke up here. I would like to discuss the removal of the following part-sentence from XEP-0030 (in Final status!): every entity MUST support at least the 'http://jabber.org/protocol/disco#info' feature I agree that this is a wart of the specification, but personally, I am not sure if the its worth fixing it. That said, I do not have a strong opinion on that. However, I want to point out that… Announcing that feature is redundant: An entity which replies with a properly constructed `http://jabber.org/protocol/disco#info"/>` element is bound to (and has always been bound to) have implemented XEP-0030 to the best of its knowledge. As this is a Final(!) status XEP, here is my estimate of the impact this change has: - Implementations which required the presence of this feature on the receiving side would now become non-compliant: They might assume that the remote entity did not really support XEP-0030 and fail with an error. Such implementations would need to be adapted in order to be able to interoperate with implementations which follow a revised version of XEP-0030. I don't see any other impact. ...there is another impact regarding the caps cache: the footprint of the caps cache would increase, at least during the period where old versions announce the feature, while the updated implementation may not. Furthermore, implementations that persist the caps cache would end up with more-or-less useless entries (which will eventually be pushed out of the cache). That itself is probably not a big deal, but it nicely demonstrates that it is often hard to understand the full impact of a change. Again, I do not favor removing it, nor do I want to keep it. But personally, I feel like there is not much to gained by fixing this. - Florian ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Remove requirement to send disco#info feature in XEP-0030
On 11 March 2024 10:51:39 CET, Kevin Smith wrote: > > [..] > >It seems to me that, although this has always seemed like a strange wart, the >fact that it might cause implementations to need to be updated (whether such >implementations are known of by The Internet or not), making the change is >inconsistent with the requirements of Final (XEP-0001) so shouldn't be made. > >/K Agreed. This is a wart that we'll have to keep for hysterical raisins. -- ralphm ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Remove requirement to send disco#info feature in XEP-0030
-- Original Message -- From "Jonas Schäfer" To standards@xmpp.org Date 10/03/2024 16:27:07 Subject [Standards] Remove requirement to send disco#info feature in XEP-0030 Dear community, it's been a while I spoke up here. I would like to discuss the removal of the following part-sentence from XEP-0030 (in Final status!): every entity MUST support at least the 'http://jabber.org/protocol/disco#info' feature Announcing that feature is redundant: An entity which replies with a properly constructed `http://jabber.org/protocol/disco#info"/>` element is bound to (and has always been bound to) have implemented XEP-0030 to the best of its knowledge. As this is a Final(!) status XEP, here is my estimate of the impact this change has: - Implementations which required the presence of this feature on the receiving side would now become non-compliant: They might assume that the remote entity did not really support XEP-0030 and fail with an error. Such implementations would need to be adapted in order to be able to interoperate with implementations which follow a revised version of XEP-0030. I don't see any other impact. I also strongly suspect that the set of implementations which follow XEP-0030 to the letter is rather slim (I only know of a single one, which would be the Rust XMPP library xmpp-rs [1]). The reason why this came up: There have in the past been cases ([2] and another, not-yet-filed issue against Prosody IM where the disco#info feature is missing from MUCs) where implementations didn't emit this feature. The seeming pointlessness and lack of information conveyed by this feature var make it easy to overlook and low-priority to fix. The fact that this has gone undiscovered for at least one Prosody IM release cycle further supports the assumption that the number of implementations which rely on that part of the spec is rather small. It seems to me that, although this has always seemed like a strange wart, the fact that it might cause implementations to need to be updated (whether such implementations are known of by The Internet or not), making the change is inconsistent with the requirements of Final (XEP-0001) so shouldn't be made. /K ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))
-- Original Message --
From "Daniel Gultsch"
To standards@xmpp.org
Date 11/03/2024 09:14:36
Subject [Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))
On Sun, Mar 10, 2024 at 4:18 PM Daniel Gultsch wrote:
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@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
I’m honestly not convinced that the problem the XEP introduces "This
leads to the unfortunate situation where some submitted XEPs erroneous
refer to non-Stanza top level stream elements as 'Stanzas'." exists.
Or if introducing a new term fixes the issue. We have terminology
("element", "stream element") for that. I briefly checked with some
XEPs (Bind 2, SM, CSI) and they all seem to be fine without this new
term.
Also - and this is probably something that might have changed since
this XEP was first introduced - we don’t have that many XEPs that use
custom stream elements after bind (after routing is enabled). CSI and
SM seem to be the only major one. We didn’t see an influx in them.
And XEPs like Bind2 an SASL2 are fairly normal in their usage of
stream elements I would say.
2. Does the specification solve the problem stated in the introduction
and requirements?
I guess. But my argument is mostly that the problem isn’t an actual problem.
3. Do you plan to implement this specification in your code? If not,
why not?
No. If I were to write a new XEP I would rather not use the word nonza.
4. Do you have any security concerns related to this specification?
No
5. Is the specification accurate and clearly written?
Yes.
I'm largely with Daniel on this.
/K
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))
On Sun, Mar 10, 2024 at 4:18 PM Daniel Gultsch wrote:
>
> 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@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
I’m honestly not convinced that the problem the XEP introduces "This
leads to the unfortunate situation where some submitted XEPs erroneous
refer to non-Stanza top level stream elements as 'Stanzas'." exists.
Or if introducing a new term fixes the issue. We have terminology
("element", "stream element") for that. I briefly checked with some
XEPs (Bind 2, SM, CSI) and they all seem to be fine without this new
term.
Also - and this is probably something that might have changed since
this XEP was first introduced - we don’t have that many XEPs that use
custom stream elements after bind (after routing is enabled). CSI and
SM seem to be the only major one. We didn’t see an influx in them.
And XEPs like Bind2 an SASL2 are fairly normal in their usage of
stream elements I would say.
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
I guess. But my argument is mostly that the problem isn’t an actual problem.
> 3. Do you plan to implement this specification in your code? If not,
> why not?
No. If I were to write a new XEP I would rather not use the word nonza.
> 4. Do you have any security concerns related to this specification?
No
> 5. Is the specification accurate and clearly written?
Yes.
cheers
Daniel
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0392 (Consistent Color Generation)
On Sun, Mar 10, 2024 at 3:24 PM Daniel Gultsch wrote: > > This message constitutes notice of a Last Call for comments on > XEP-0392. > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Yes > 2. Does the specification solve the problem stated in the introduction > and requirements? Yes > 3. Do you plan to implement this specification in your code? If not, > why not? Yes I have implemented this in Conversations. (And I’m also using this in my email client) > 4. Do you have any security concerns related to this specification? No > 5. Is the specification accurate and clearly written? Yes. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] UPDATED: XEP-0001 (XMPP Extension Protocols)
Version 1.25.0 of XEP-0001 (XMPP Extension Protocols) has been released. Abstract: This document defines the standards process followed by the XMPP Standards Foundation. Changelog: Add note that editorial changes do not affect Deferred state (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0001.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. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] NEW: XEP-0489 (Reporting Account Affiliations)
Version 0.1.0 of XEP-0489 (Reporting Account Affiliations) has been released. Abstract: This specification documents a way for an XMPP server to report to other entities the relationship it has with a user on its domain. Changelog: * Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0489.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. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] NEW: XEP-0488 (MUC Token Invite)
Version 0.1.0 of XEP-0488 (MUC Token Invite) has been released. Abstract: This specification provides a way to generate tokens to invite users to a MUC room. Changelog: * Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0488.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. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] UPDATED: XEP-0060 (Publish-Subscribe)
Version 1.26.0 of XEP-0060 (Publish-Subscribe) has been released. Abstract: This specification defines an XMPP protocol extension for generic publish-subscribe functionality. The protocol enables XMPP entities to create nodes (topics) at a pubsub service and publish information at those nodes; an event notification (with or without payload) is then broadcasted to all entities that have subscribed to the node. Pubsub therefore adheres to the classic Observer design pattern and can serve as the foundation for a wide variety of applications, including news feeds, content syndication, rich presence, geolocation, workflow systems, network management systems, and any other application that requires event notifications. Changelog: Add examples for publishing item without ID (melvo) URL: https://xmpp.org/extensions/xep-0060.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. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
