Re: [Standards] XEP Dependencies
> The others are Deferred, which means they've Expired - we do not, typically, > clean-up Deferred XEPs. Understandable, though I had assumed that Deferred meant "not recently maintained" rather than expiration - which suggests 'do not implement.' So then there is a question of whether there is an issue for current XEPs depending on deferred XEPs ...? (For reference: XEP-0280 on 0296; XEP-0369 on 0292, 0372; and XEP-0373 on 0334) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0386 (Bind 2.0)
XEP-0386 (Bind 2.0) has been Deferred because of inactivity. 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 If and when a new revision of this XEP is published, its status will be changed back to Experimental. 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 Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0060 (Publish-Subscribe)
Version 1.15.1 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 missing "retrieve-default-sub" feature to the XML Schema (sc) 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 Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0174 (Serverless Messaging)
Version 2.0.1 of XEP-0174 (Serverless Messaging) has been released. Abstract: This specification defines how to communicate over local or wide-area networks using the principles of zero-configuration networking for endpoint discovery and the syntax of XML streams and XMPP messaging for real-time communication. This method uses DNS-based Service Discovery and Multicast DNS to discover entities that support the protocol, including their IP addresses and preferred ports. Any two entities can then negotiate a serverless connection using XML streams in order to exchange XMPP message and IQ stanzas. Changelog: Fix incorrect STARTTLS examples. (cs) URL: https://xmpp.org/extensions/xep-0174.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 Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0383 (Burner JIDs)
XEP-0383 (Burner JIDs) has been Deferred because of inactivity. Abstract: A mechanism by which users may request anonymous, ephemeral "burner" JIDs. URL: https://xmpp.org/extensions/xep-0383.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. 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 Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] LAST CALL: XEP-0280 (Message Carbons)
This message constitutes notice of a Last Call for comments on XEP-0280. Title: Message Carbons Abstract: In order to keep all IM clients for a user engaged in a conversation, outbound messages are carbon-copied to all interested resources. URL: https://xmpp.org/extensions/xep-0280.html This Last Call begins today and shall end at the close of business on 2018-02-22. 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? 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! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP Dependencies
According to both https://github.com/xsf/xeps and https://xmpp.org/extensions : * XEP-0105 (Tree Transfer Stream Initiation Profile) [Deferred] * XEP-0135 (File Sharing) [Deferred] * XEP-0137 (Publishing Stream Initi-ation Requests) [Draft] * XEP-0159 (Spim-Blocking Control) [Deferred] * XEP-0241 (Encryption of Archived Messages) [Deferred] * XEP-0103 (URL Address Information) [Deferred] * XEP-0347 (Internet of Things - Discovery) [Deferred] * XEP-0169 (Twas The Night Before Christmas) [Active] * XEP-0264 (Jingle Content Thumbnails) [Deferred] Or is there another secret stash I don't know about? Thanks, this is a great help! We should probably be doing this periodically. > * XEP-0159 (Spim-Blocking Control) depends on: XEP-0016 This appears to be the only one that's not also already deprecated, so I've added deprecating it to the council's agenda. Thanks again! —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Quoting Jonas Wielicki : On Donnerstag, 8. Februar 2018 14:34:12 CET W. Martin Borgert wrote: I had another idea before coming up with the configuration variable, but I find it very ugly, but maybe others might find some beauty (or pragmatism) in it: A PubSub node could have a "magic" node We need to get this terminology straight. When you say "PubSub node", do you in fact mean a pubsub node (i.e. a specific @node value on a specific pubsub service with JID X) or a PubSub service with JID X? I hope to get the terminology right this time: A PubSub node could have a "magic" item. A PubSub service could have a "magic" node. Does this make sense? For e.g. Movim both a logo for service and for a node seems to be useful. I think specifying avatars for each PubSub *node* could be tricky. For services (which I assume you meant) see below. If there were a "magic" item on a node, it never must be removed automatically, but only on user request, right? The "magic id" (again, only for PubSub services, not for individual nodes) is obvious, I’d simply use the same the XEP-0084 uses. That could even work magically with client code. Nice! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP Dependencies
On 8 February 2018 at 15:35, Sam Whited wrote: > On Thu, Feb 8, 2018, at 09:23, Tedd Sterr wrote: >> After noticing that XEP-0137 depends on "Stream Initiation" which is now >> deprecated, I checked through all XEPs for their dependencies and found >> the following: > > Thanks, this is a great help! We should probably be doing this periodically. > Indeed, great work. > >> * XEP-0159 (Spim-Blocking Control) depends on: XEP-0016 > > This appears to be the only one that's not also already deprecated, so I've > added deprecating it to the council's agenda. > I think you meant XEP-0137 (SI-PUB), which is Draft. The others are Deferred, which means they've Expired - we do not, typically, clean-up Deferred XEPs. > Thanks again! > > —Sam > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP Dependencies
On Thu, Feb 8, 2018, at 09:23, Tedd Sterr wrote: > After noticing that XEP-0137 depends on "Stream Initiation" which is now > deprecated, I checked through all XEPs for their dependencies and found > the following: Thanks, this is a great help! We should probably be doing this periodically. > * XEP-0159 (Spim-Blocking Control) depends on: XEP-0016 This appears to be the only one that's not also already deprecated, so I've added deprecating it to the council's agenda. Thanks again! —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP Dependencies
After noticing that XEP-0137 depends on "Stream Initiation" which is now deprecated, I checked through all XEPs for their dependencies and found the following: == Strong Dependencies (the XEP is pointless without them) == * XEP-0105 (Tree Transfer Stream Initiation Profile) depends on: XEP-0095, XEP-0096 * XEP-0135 (File Sharing) depends on: XEP-0096 * XEP-0137 (Publishing Stream Initiation Requests) depends on: XEP-0095 * XEP-0159 (Spim-Blocking Control) depends on: XEP-0016 * XEP-0241 (Encryption of Archived Messages) depends on: XEP-0136 == Weak Dependencies (the XEP could probably be reworked to not require them) == * XEP-0103 (URL Address Information) depends on: XEP-0095 * XEP-0347 (Internet of Things - Discovery) depends on: XEP-0323, XEP-0324, XEP-0325, XEP-0326 * XEP-0169 (Twas The Night Before Christmas) depends on: XEP-0090, XEP-0112 == Mistakes (dependency listed, but apparently not used) == * XEP-0264 (Jingle Content Thumbnails) depends on: XEP-0096 XEP-0016 (Privacy Lists) [deprecated] XEP-0090 (Legacy Entity Time) [obsolete] XEP-0095 (Stream Initiation) [deprecated] XEP-0096 (SI File Transfer) [deprecated] XEP-0112 (User Physical Location) [obsolete] XEP-0136 (Message Archiving) [deprecated] XEP-0323 (Internet of Things - Sensor Data) [retracted] XEP-0324 (Internet of Things - Provisioning) [retracted] XEP-0325 (Internet of Things - Control) [retracted] XEP-0326 (Internet of Things - Concentrators) [retracted] ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
On Donnerstag, 8. Februar 2018 14:34:12 CET W. Martin Borgert wrote: > Quoting Daniel Gultsch : > > polling is a terrible idea traffic wise and very nontransparent for the > > user. > > > > I don't have an opinion on pubsub. > > I had another idea before coming up with the configuration variable, > but I find it very ugly, but maybe others might find some beauty > (or pragmatism) in it: > > A PubSub node could have a "magic" node We need to get this terminology straight. When you say "PubSub node", do you in fact mean a pubsub node (i.e. a specific @node value on a specific pubsub service with JID X) or a PubSub service with JID X? I think specifying avatars for each PubSub *node* could be tricky. For services (which I assume you meant) see below. > , i.e. with the magic id > "pubsub_logo". This node contains the logo, it can be upgraded and > notification to users would be immediate. But a "magic id"? Like > "favicon.ico"? The "magic id" (again, only for PubSub services, not for individual nodes) is obvious, I’d simply use the same the XEP-0084 uses. That could even work magically with client code. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Quoting Daniel Gultsch : polling is a terrible idea traffic wise and very nontransparent for the user. I don't have an opinion on pubsub. I had another idea before coming up with the configuration variable, but I find it very ugly, but maybe others might find some beauty (or pragmatism) in it: A PubSub node could have a "magic" node, i.e. with the magic id "pubsub_logo". This node contains the logo, it can be upgraded and notification to users would be immediate. But a "magic id"? Like "favicon.ico"? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Thu, 8 Feb 2018 14:21:49 +0100 Daniel Gultsch wrote: > 2018-02-08 13:43 GMT+01:00 Evgeny Khramtsov : > > Thu, 8 Feb 2018 13:17:14 +0100 > > Daniel Gultsch wrote: > > > >> at least for MUC I would prefer vCard + hash in presence from the > >> bare muc jid. (as discussed in our 34C3 meeting and/or various > >> discussions we had prior to this) > > > > What was the conclusion? (If any) > > > The question I had for the room was basically if any client would > break on receiving presence from the bare jid and everyone (in the > room) agreed that *their* client wouldn't break. > > On whether or not this is a good idea; I can't remember anyone voice > strong objections. Good. Then I will implement this in ejabberd. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
2018-02-08 13:43 GMT+01:00 Evgeny Khramtsov : > Thu, 8 Feb 2018 13:17:14 +0100 > Daniel Gultsch wrote: > >> at least for MUC I would prefer vCard + hash in presence from the bare >> muc jid. (as discussed in our 34C3 meeting and/or various discussions >> we had prior to this) > > What was the conclusion? (If any) The question I had for the room was basically if any client would break on receiving presence from the bare jid and everyone (in the room) agreed that *their* client wouldn't break. On whether or not this is a good idea; I can't remember anyone voice strong objections. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Thu, 8 Feb 2018 13:17:14 +0100 Daniel Gultsch wrote: > I don't have an opinion on pubsub. I guess that's not a problem for PubSub service to send notifications? :) A dedicated and well-known node should be enough for this. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Thu, 8 Feb 2018 13:17:14 +0100 Daniel Gultsch wrote: > at least for MUC I would prefer vCard + hash in presence from the bare > muc jid. (as discussed in our 34C3 meeting and/or various discussions > we had prior to this) What was the conclusion? (If any) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
at least for MUC I would prefer vCard + hash in presence from the bare muc jid. (as discussed in our 34C3 meeting and/or various discussions we had prior to this) polling is a terrible idea traffic wise and very nontransparent for the user. I don't have an opinion on pubsub. 2018-02-07 22:16 GMT+01:00 W. Martin Borgert : > Hi, > > this is an idea mainly for the "social network" aspect of XMPP: > A logo for a MUC or for a PubSub node, similar to a user avatar. > > Such a logo, emblem, or symbol can be a good indicator for users > to find the right MUC or PubSub node in a social network > application or graphical XMPP client. > > How about introducing two configuration variables, one in > https://xmpp.org/extensions/xep-0045.html#registrar-formtype-owneronfig: > > var='muc#muc_logo' > > And the second one in > https://xmpp.org/extensions/xep-0060.html#owner-configure: > > var='pubsub#node_logo' > > The value should be a element from > https://xmpp.org/extensions/xep-0221.html. > > IMHO, the value should be restricted to > 1. images, or would a sound make sense? Maybe... > 2. inline data, so that a link to a web resource cannot be > abused for snitching IP addresses > > What do you think? > > TIA & Cheers > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
On Donnerstag, 8. Februar 2018 13:01:17 CET W. Martin Borgert wrote: > Quoting Timothée Jaussoin : > > In the end I don't think that it's a big issue to have those info > > requested manually, having a cache of a few hours on the clients is > > an OK solution for me at the moment. > > Maybe a refresh or poll rate of e.g. 12..24 hours can "officially" > be suggested? Not really nice, but better than not having logos or > invent something complicated that will never be implemented... I think an Informational XEP would be the appropriate mean for this. It is really just a combination of protocols which makes sense, plus the refresh rule. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Quoting Timothée Jaussoin : In the end I don't think that it's a big issue to have those info requested manually, having a cache of a few hours on the clients is an OK solution for me at the moment. Maybe a refresh or poll rate of e.g. 12..24 hours can "officially" be suggested? Not really nice, but better than not having logos or invent something complicated that will never be implemented... ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high
On 08.02.2018 11:39, Guus der Kinderen wrote: > Thank you for all feedback. > > The general consensus appears to be in favor of this change, but that a > stream error definition should be added. > > None of the other RFC-6120-defined conditions appear to be fitting here, > so I suggest that `undefined-condition` is used. After a quick look at RFC 6120 § 4.9.3 I also found only undefined-condition suitable. > Additionally, we should add an application-specific condition element. I > suggest to add a single `mismatch` element, qualified by the namespace > as defined for this feature in the XEP. It may be a good idea to include the received 'h' value and the send stanza count in that element. This probably helps debugging. And an optional human readable text is also always a good idea. Hence my suggestion would be something like: You acknowledged 10 stanzas, but I only send you 8 so far. Something is odd. Please go fix it. > If we do more explicitly define the steam error, then it would be > fitting to also further specify the stream termination that's now > defined in the last lines of section 3: > > Note that a client SHALL only make at most one attempt to enable > stream management. If a server receives a second element > it SHOULD respond with a stream error, thus terminating the client > connection. > > > What would be a fitting error condition here? We have XEP-0198 § 6's example: unexpected-request seems fitting, not sure if we want to define an application specific condition element, e.g. duplicate-enable, in this case. > Lastly, section 5 defines another stream termination here: > > If the former stream is resumed and the server still has the stream > for the previously-identified session open at this time, the old > stream SHOULD be terminated. > > > Is this intended to be a termination without stream error? That might > cause confusion in the client being terminated. There shouldn't be an old client session any more, since the old client has resumed the session. It is nevertheless sensible that the server terminates the former stream. How this is done is currently underspecified. I would send a stream error, ending stream tag and then disconnect the transport layer connection. I believe that in this case 'conflict' (RFC 6120 § 4.9.3.3) is an appropriate stream error condition. - Florian ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high
Thank you for all feedback. The general consensus appears to be in favor of this change, but that a stream error definition should be added. None of the other RFC-6120-defined conditions appear to be fitting here, so I suggest that `undefined-condition` is used. Additionally, we should add an application-specific condition element. I suggest to add a single `mismatch` element, qualified by the namespace as defined for this feature in the XEP. If we do more explicitly define the steam error, then it would be fitting to also further specify the stream termination that's now defined in the last lines of section 3: Note that a client SHALL only make at most one attempt to enable stream > management. If a server receives a second element it SHOULD > respond with a stream error, thus terminating the client connection. What would be a fitting error condition here? Lastly, section 5 defines another stream termination here: If the former stream is resumed and the server still has the stream for the > previously-identified session open at this time, the old stream SHOULD be > terminated. Is this intended to be a termination without stream error? That might cause confusion in the client being terminated. Regards, Guus On 7 February 2018 at 20:57, Ruslan N. Marchenko wrote: > Am Mittwoch, den 07.02.2018, 08:40 +0100 schrieb Guus der Kinderen: > > > I propose that the XEP is updated with an instruction to, upon detection > of an invalid acknowledgement, terminate the stream with stream error. > > Thoughts? > > > I was always pretty sure this is actually de-facto behaviour. Ack > non-existing stanza means SM is out of sync or there's stream injection - > both non-recoverable and/or dangerous cases falling in SM misuse category. > No harm making it explicit though. > > --RR > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0060: max-nodes-exceeded error is not described.
Hi, Openfire does implement it. -- Christian Gesendet: Donnerstag, 08. Februar 2018 um 03:26 Uhr Von: "Peter Saint-Andre" An: standards@xmpp.org Betreff: Re: [Standards] XEP-0060: max-nodes-exceeded error is not described. On 2/7/18 2:04 AM, Christian Schudt wrote: > Hi, > > please consider this issue: > https://github.com/xsf/xeps/issues/581 > > I kindly ask the authors of XEP-0060 to describe the > "max-nodes-exceeded" error in the specification or to remove it from the > XML schema, if it should not be used. > > Although one can guess, when this error should be used, it's still not > clear, if it's a defined error or not. One can guess that this error could be returned if a node creation request would cause some limit to be exceeded (e.g., a node creator is not allowed to create more than X nodes on the service). Do any existing implementations include such a limit? Should they? If so, then defining this error case would be helpful. Peter ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___