Re: [Standards] [XEP-406] Questions
Hi Melvin, that's great! Thank you. I have another question, maybe you know how to implement it. When I send a change for the allowed node, what's the notification the other members subscribed to that node receive: the complete list for allowed items or only the elements I sent to be published/retracted? Kind regards, Manuel Rubio. El 2021-02-16 13:14, Melvin Keskin escribió: Hi Manuel, I am working on Kaidan's (https://kaidan.im) MIX implementation and will create a pull request with various fixes for the MIX XEPs including the wrong example you found. ___ 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-406] Questions
Hi Andrzej, ouch! I considered the version with "items" more reliable. I understand that examples are a clear way to understand what the XEP says so if that's wrong there is a possibility to get wrong implementations, IMHO that should be fixed. Kind regards, Manuel Rubio. El 2021-02-15 12:24, Andrzej Wojcik escribió: > Hi, > >> I'm doing an implementation of the MIX (XEP-0369) and now, I was >> implementing some administrative tasks, like config and info modification, >> but I was questioning about some parts, because, i.e. Example 7 in XEP-0406 >> (MIX-ADMIN) is saying: >> >> >> >> >> >> I mean, it's implementing "pubsub > publish > item" for the result, but then >> the Example 5 is implementing: >> >> >> >> >> >> >> It's adding "items" between "publish" and "item". Is it correct? > > I think that there should be no "items" between "publish" and "item" as MIX > is based (in this part) on XEP-0060 which uses "publish" > "item". > > Keep in mind that examples are not normative and it is better not to assume > that they are correct. In most parts related to PubSub it is best to verify > with XEP-0060. > >> And about the last part, all of the namespaces inside of XEP-406 says >> "urn:xmpp:mix:core:0", but XEP-0369 is implementing "urn:xmpp:mix:core:1", >> keeping in mind that Example 13 in XEP-0369 is showing an example exactly >> the same as Example 4 in XEP-406, what version should I use? should it be >> updated? > > I think you should use "urn:xmpp:mix:core:1" as current version of core > specification has namespace "urn:xmpp:mix:core:1" and XEP-0406 should be > updated to reflect that. > > At least that is what I did while I was implementing MIX. > > Regards, > Andrzej Wójcik > > XMPP: andrzej.woj...@tigase.org > Email: andrzej.woj...@tigase.net > > ___ > 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 ___
[Standards] [XEP-406] Questions
Hi, I'm doing an implementation of the MIX (XEP-0369) and now, I was implementing some administrative tasks, like config and info modification, but I was questioning about some parts, because, i.e. Example 7 in XEP-0406 (MIX-ADMIN) is saying: I mean, it's implementing "pubsub > publish > item" for the result, but then the Example 5 is implementing: It's adding "items" between "publish" and "item". Is it correct? And about the last part, all of the namespaces inside of XEP-406 says "urn:xmpp:mix:core:0", but XEP-0369 is implementing "urn:xmpp:mix:core:1", keeping in mind that Example 13 in XEP-0369 is showing an example exactly the same as Example 4 in XEP-406, what version should I use? should it be updated? Kind regards, Manuel Rubio. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0333 (Chat Markers)
Hi, XEP-0409 looks very nice, but it's not an option at this moment because it requires a modification more difficult to be performed inside of the XMPP server, while the sending back of a sent based on the message (when it's type=chat and it's sent by a user) it's easier for me. But I liked that a lot. If a have enough time it's possible when I start with the multi-device support in my development I use that instead of Carbon Copies. Kind regards, Manuel Rubio. El 2020-10-13 20:45, Jonas Schäfer escribió: Hi Manuel, On Dienstag, 13. Oktober 2020 10:35:40 CEST Manuel Rubio wrote: Yes, but I want something more explicit and don't linked to stream management. In that case I suggest you look into implementing IM Routing-NG (XEP-0409) in both client and server. In addition to some other fixes to the core routing, it also provides the client with reflections of the sent message (including the stanza-ID), which is even better than just placing a sent marker (because the stanza ID allows MAM synchronisation): XEP-0409, §3.3: When an entity wants to send a non-error message to be handled by all a user's IM-NG clients they will send it to the user's bare JID, which the receiving server then MUST send to all the contact's IM-NG resources, and the sending server must reflect to all the user's IM-NG resources. kind regards, Jonas ___ 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] UPDATED: XEP-0333 (Chat Markers)
Hi, Yes, but I want something more explicit and don't linked to stream management. Kind regards, Manuel Rubio. > El 13 oct 2020, a las 6:33, Philipp Hörist escribió: > > > Hi, > > You know that anyway because of stream management acks and if you received no > error. > > Regards > >> Am Di., 13. Okt. 2020 um 03:41 Uhr schrieb Manuel Rubio >> : >> Hi, >> >> sorry to get this message too old from the list but I wanted to ask if >> it's possible to add "sent" to the list of markers. >> >> The "sent" will be very useful when a message is sent, the server >> replies directly to the user with a "sent" marker and then we know the >> server has the message. >> >> Kind regards, >> Manuel Rubio. >> >> El 2020-04-21 12:43, p...@bouah.net escribió: >> > Version 0.4 of XEP-0333 (Chat Markers) has been released. >> > >> > Abstract: >> > This specification describes a solution of marking the last received, >> > displayed and acknowledged message in a chat. >> > >> > Changelog: >> > Add notes about usage within MUCs. (mw) >> > >> > 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. >> > ___ >> > 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 >> ___ > ___ > 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] UPDATED: XEP-0333 (Chat Markers)
Hi, sorry to get this message too old from the list but I wanted to ask if it's possible to add "sent" to the list of markers. The "sent" will be very useful when a message is sent, the server replies directly to the user with a "sent" marker and then we know the server has the message. Kind regards, Manuel Rubio. El 2020-04-21 12:43, p...@bouah.net escribió: Version 0.4 of XEP-0333 (Chat Markers) has been released. Abstract: This specification describes a solution of marking the last received, displayed and acknowledged message in a chat. Changelog: Add notes about usage within MUCs. (mw) 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. ___ 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] MIX (XEP-0369) channel discovery
Hi, even it's a bit more complicated in the context of MAM and MIX because you are storing conversations which could belongs to users who are not in the system anymore. I mean, if you created a bot, for example, that's an account with specific features, and it's registered to a MIX channel and sent to you some messages (directly and via that channel), if the bot removes its account, you can retrieve the conversations but when you try to obtain information about what was that exactly, you only can figure out that was an user (account) and that's all. Maybe something like a general record for JIDs, only to store information like features and kind of account (identities) could be a good idea in this case to keep the information about what is/was that JID. Kind regards. Manuel Rubio. El 2018-09-20 09:43, Ralph Meijer escribió: Hi, Recently I have been looking at discovery of entities to determine what kind of thing it is, knowing nothing more than its JID. The starting point is a client that shows a list of entities, based on past conversations (MAM), ordered by last interaction. Entities could be regular user accounts, bots, group chat rooms, etc. The core idea behind XEP-0030 (Service Discovery) is that given a JID, you can find out what kind of entity it is, by sending a Disco Info request and getting one or more identities in return. Additional information like supported features/protocols, and meta-data as Disco Extension Data Forms (XEP-0128), can be included there, too. Reading XEP-0369, section 6.3, on discovering channel information, I see that it currently requires the node attribute to be set to 'mix'. From what I understand this is to allow a particular JID to support both MUC and MIX, and have a way to request the MIX specific information. The problem I have with this, is that it requires prior knowledge of a certain JID (also) being a MIX channel. So you can't find out the identity (the thing that's telling you what a JID is) without knowing what the thing is. I do understand this works if you start out with discovering the MIX service first, but I don't believe that should be the only entry point. I don't see the need for explicitly asking for the MIX information (only). XEP-0030 and XEP-0128 support returning multiple identities as well as multiple extension forms. So a Disco Info result, without node, could look like this: urn:xmpp:mix:core:0 Witches Coven A location not far from the blasted heath where the three witches meet http://jabber.org/protocol/muc#roominfo The place for all good witches! Note that I included the channel info from section 6.5 here. I was surprised to find we aren't using XEP-0128 disco extensions instead of doing a pubsub items request here. I /do/ see the value for having the pubsub node as way to get notifications on changes, so having both would be even better. If you have to do a Disco Info request anyway, it saves one request. Finally, section 12, on Registrar Considerations, doesn't mention the required registration [1] of the identity conference/mix. Unfortunately one identity can have at most one extension form, so reusing conference/text is probably not a good idea. [1] https://xmpp.org/registrar/disco-categories.html#conference -- ralphm ___ 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] Presence Handling
Hi Steve, maybe you can add a only one request to retrieve the last activity for each participant in the list. This way, you can get the whole list of participants, if they are active (online) and which time was last time they were active. It could be considered as a brief of the presence requests, like history for presences or something similar. Kind regards. Manuel Rubio. El 2018-05-25 08:59, Steve Kille escribió: > Manuel, > > This is an interesting idea. > > Downsides: > > * For a large channel, this could lead to LOTS of extra presence traffic (n*n) > * It does not give a framework to solve channel presence distribution for JID > Hidden > > Steve > > FROM: Manuel Rubio <man...@altenwald.com> > SENT: 25 May 2018 00:08 > TO: XMPP Standards <standards@xmpp.org> > CC: Steve Kille <steve.ki...@isode.com> > SUBJECT: Re: [Standards] Presence Handling > > Hi, > > I think presence isn't important to have the real JID. If you know the real > JID for a participant you can subscribe to its real JID to receive the > presence directly from the user instead of both MIX and User. > > The point is the tag "" inside of the message. The way to add or use > real JIDs in presence makes no sense IMHO. > > Kind regards. > Manuel Rubio. > > El 2018-05-24 17:54, Steve Kille escribió: > >> Dave, >> >> That would also be problematic, since entities would then need to process >> presence rather differently, even more so than they do for MUC now. >> >> I was thinking simply: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _ _ >> >> _[STEVE KILLE]_ >> >> _SO WHAT VALUE IS THE PROXY JID GIVING, GIVEN THAT THE DATA WHICH THE CLIENT >> MIGHT HAVE DERIVED FROM THE PROXY JID IS NOW ENCODED IN THE MESSAGE??_ >> >> _ _ >> >> _I WAS SUGGESTING MESSAGE CAME FROM COVEN@MIX.EXAMPLE YOU ARE SUGGESTING IT >> COMES FROM 5Q3509Q759348#COVEN@MIX.EXAMPLE_ >> >> _ _ >> >> _WHAT BENEFIT IS THE PROXY JID GIVING TO THE CLIENT?_ >> >> _ _ >> >> _Steve_ >> >> _ _ >> >> ___ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards [1] >> Unsubscribe: standards-unsubscr...@xmpp.org >> ___ Links: -- [1] https://mail.jabber.org/mailman/listinfo/standards ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Presence Handling
Hi, I think presence isn't important to have the real JID. If you know the real JID for a participant you can subscribe to its real JID to receive the presence directly from the user instead of both MIX and User. The point is the tag "" inside of the message. The way to add or use real JIDs in presence makes no sense IMHO. Kind regards. Manuel Rubio. El 2018-05-24 17:54, Steve Kille escribió: > Dave, > > That would also be problematic, since entities would then need to process > presence rather differently, even more so than they do for MUC now. > > I was thinking simply: > > > > > > > > > > > > > > > > _ _ > > _[STEVE KILLE]_ > > _SO WHAT VALUE IS THE PROXY JID GIVING, GIVEN THAT THE DATA WHICH THE CLIENT > MIGHT HAVE DERIVED FROM THE PROXY JID IS NOW ENCODED IN THE MESSAGE??_ > > _ _ > > _I WAS SUGGESTING MESSAGE CAME FROM COVEN@MIX.EXAMPLE YOU ARE SUGGESTING IT > COMES FROM 5Q3509Q759348#COVEN@MIX.EXAMPLE_ > > _ _ > > _WHAT BENEFIT IS THE PROXY JID GIVING TO THE CLIENT?_ > > _ _ > > Steve > > _ _ > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards [1] > Unsubscribe: standards-unsubscr...@xmpp.org > ___ Links: -- [1] https://mail.jabber.org/mailman/listinfo/standards ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] MIX and ProxyJIDs
Hi, El 2018-05-24 16:24, Dave Cridland escribió: > always contains the real jid, if present. > always contains the proxy jid, but is only present if the real > jid is not. > > That seems to be what you're asking for, isn't it? Yes! that works for me. Thanks. Manuel Rubio. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] MIX and ProxyJIDs
Hi Steve, actually I never say anything about presence, we are not using presence at all. I'm talking about the messages and the "mix" tag inside. Anyway, about presence I can see this in the MIX-PRESENCE XEP regarding the information inside of the pubsub#event you can receive: dnd Making a Brew In this case, I can see the ID as the proxyJID inside of the packet. With the new configuration and keeping in mind you said the "from" will be the Proxy-JID, you can change the ID for the item tag to use the real-JID or add the "jid" attribute to include the real JID. Kind regards. Manuel Rubio. El 2018-05-24 15:56, Steve Kille escribió: Manuel, The problem here is not messages or privacy, but how to identify a user in presence. The hack that MUC uses to identify they user by putting the sender's nick in the resource is something we REALLY want to avoid in MIX. Presence has to come from the MIX domain, so you cannot use the sender's JID. Proxy JID lets you represent the sender in a JID that comes from the domain. Steve -Original Message- From: Standards <standards-boun...@xmpp.org> On Behalf Of Manuel Rubio Sent: 24 May 2018 14:51 To: 'XMPP Standards' <standards@xmpp.org> Subject: [Standards] MIX and ProxyJIDs Hi, I know that from MUC and probably even before the privacy for the user is a priority and it's compulsory to use Proxy-JIDs in some way. But, in my use case we have a closed system and all of the users know to the others. Even if the server is opened to others, the private groups only accessed using invitation have the same property, all of the participants know the others. For the users it's a waste of memory and network to ask all the time for who is the proxy-JID which is sending the message. I was thinking to use a new configuration param like: - 'User real JID' default to false. If that configuration is set to true, then the block: thirdwitch 123456#coven@mix.shakespeare.example hag66@shakespeare.example It could change to use only the real JID instead of the proxy JID, but I think that way is just enough. What do you think? Thanks. Manuel Rubio. ___ 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 ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] MIX and ProxyJIDs
Hi, I know that from MUC and probably even before the privacy for the user is a priority and it's compulsory to use Proxy-JIDs in some way. But, in my use case we have a closed system and all of the users know to the others. Even if the server is opened to others, the private groups only accessed using invitation have the same property, all of the participants know the others. For the users it's a waste of memory and network to ask all the time for who is the proxy-JID which is sending the message. I was thinking to use a new configuration param like: - 'User real JID' default to false. If that configuration is set to true, then the block: thirdwitch 123456#coven@mix.shakespeare.example hag66@shakespeare.example It could change to use only the real JID instead of the proxy JID, but I think that way is just enough. What do you think? Thanks. Manuel Rubio. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Update to MIX 0.9.7
Hello Steve, El 2018-05-09 15:53, Steve Kille escribió: 3. Mandatory presence (3.9.7). There is an option for a MIX channel to require presence. This allows a channel to specify the current MUC behaviour that online clients are visible with presence (and no "hidden" listeners, which some might object to on privacy grounds). This cannot be enforced by the MIX channel, so it is a policy that compliant MIX clients are expected to follow. I have clarified this in the text. It seems useful to me, but we could drop this option if people feel it will never be useful. I think presence SHOULD NOT be mandatory. In my particular case we're not using presence at all and I like the flexibility to include/exclude nodes in the features of the channel. 5. 6.3 (Ensuring Message Delivery) describes an important function for MIX. The detailed approach has issues, which Florian Schmaus flags. Jonas Wielicki also flagged the issues in Feb 2017. I am replacing this section with a reference to a (yet to be written) XEP.Rationale: - We clearly do not have the spec right - Reliable message delivery seems like a generic capability that could be used elsewhere. I still considere that XEP-0199 (ping) fits better than use "markable" that is confusing because of the use of the same tag in XEP-0333 (chat markers). It's not needed to write a whole new XEP for that IMO. Kind regards. Manuel Rubio. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0369 MIX uses MAM version 1 and/or version 2?
Hello, I was reviewing the part of MAM and looks like there are IQs using MAM version 1 and other using MAM version 2. Should it be unified to only the last version or is intended to do in that way to adjust to the specific and different versions that could be in use? Kind regards. Manuel Rubio. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0369: MIX - About create a room/channel
Hi, I'm not sure if there are use cases where Owners and/or Administrators can be on the lists without being Participants. In my opinion, these roles should be subsets. The "Participants" list is the superset, the "Administrators" list is a subset of "Participants" and "Owners" is a subset of "Administrators" list. In that way, it's easy to think that Owners should be Administrators and Participants. And if it's needed to have always an Owner, it's difficult to have inconsistencies and weird situations like Ralph says. Kind regards. Manuel Rubio. El 2018-04-25 09:26, Ralph Meijer escribió: On 2018-04-24 09:09, Steve Kille wrote: -Original Message- From: Standards <standards-boun...@xmpp.org> On Behalf Of Ralph Meijer Sent: 23 April 2018 21:41 So, does that mean you can create a room in such a way that you lack full control over? That doesn't sound optimal, although I like explicit over implicit. [Steve Kille] I agree that explicit is good. It is also clean if you want to create a room without an owner or with owners not yourself. What happens if you omit the Owners field? Is the default a single item, being the bare JID of the creator? [Steve Kille] 3.9.11 says: " Bare JIDs with Owner rights as defined in ACL node. When a channel is created, the JID creating the channel is configured as an owner, unless this attribute is explicitly configured to another value." This is effectively saying Owner is mandatory. I think that I will add text to explicitly say that a channel must have an owner. Does this make sense? Section 3.9.1 says two things: 1) Only owners are allowed to modify the channel configuration node. 2) There MUST always be at least one Owner for a Channel. Owners, Administrators, Participants, and Allowed are optional and do not need to be set. Where no owner is explicitly set, it is anticipated that a server administrator will have owner rights. [..] I think 1 follows from 2, simply because if you have no owner, there can be no changes to the Channel afterwards. So I do think that 2) makes sense. I'm a bit unsure about the part where it anticipates about server administrators, and how that interacts with the MUST in the previous sentence. If you value explicit over implicit, I'd do away with this bit of vagueness. The text for 2 continues with: “Rights are defined in a strictly hierarchical manner following the order of this table, so that for example Owners will always have rights that Administrators have.” This seems to imply that Administrators and Owners "have the rights of" Participants. Are they actually in the list of Participants? If so: - What does it mean to be in the list of Participants (including Administrators and Owners), if there was no explicit join from that bare JID? - Is such an entity just not subscribed to any nodes? - How do roster modifications work in this case? - Can an administrator modify this list with a PubSub publish, like the Allowed node? The above would also imply that you can add people to a channel without using the invite system in 6.1.16. - Does leaving the room affect these lists? - If so, what happens when the last Owner leaves the room? -- ralphm ___ 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-0369: MIX - About create a room/channel
Hi Steve, thanks for your answers. About one I think was omitted, if I (hag66) create a channel saying the owners are "hecate" and "greymalkin", am I an owner for that channel? Thanks. Manuel Rubio. El 2018-04-23 15:46, Steve Kille escribió: Manuel, -Original Message- From: Standards <standards-boun...@xmpp.org> On Behalf Of Manuel Rubio Sent: 23 April 2018 09:30 To: standards@xmpp.org Subject: [Standards] XEP-0369: MIX - About create a room/channel Hello, I was reading today the create form for the room creation. I have several doubts about that. First one, is it possible to include as many owners as I want and they are supposed to be included in the channel or only are intended to be owners when they join to the channel? [Steve Kille] Being an Owner is actually independent of joining the channel. It identifies JIDs that can manage configuration of the channel. For example you might have an Admin with owner rights who does not participate in the channel. urn:xmpp:mix:1 hecate@shakespeare.example greymalkin@shakespeare.example allowed jid-mandatory-visible true I this case hag66@shakespeare.example is adding to hecate and greymalkin as owners. Is intended "hag66" is the first owner and the others are owners as well? are they forced to be included in the channel? [Steve Kille] Owners do not need to be channel participants. I'll add a note in 3.9.1 to make this clear And, is it possible to add different fields? I understand (but it's not clear) these fields belongs to the configuration node, is it possible to add variables from information node like Name and Description? [Steve Kille] Yes. These are fields from the configuration node. I'll update 6.5.2 to make this clear.To modify other nodes, such as information node, you need to use the operations to modify those directly. Thanks. Manuel Rubio. [Steve Kille] Thanks for the input. I'll address the points in the next update I make Regards Steve ___ 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 ___
[Standards] XEP-0369: MIX - About create a room/channel
Hello, I was reading today the create form for the room creation. I have several doubts about that. First one, is it possible to include as many owners as I want and they are supposed to be included in the channel or only are intended to be owners when they join to the channel? urn:xmpp:mix:1 hecate@shakespeare.example greymalkin@shakespeare.example allowed jid-mandatory-visible true I this case hag66@shakespeare.example is adding to hecate and greymalkin as owners. Is intended "hag66" is the first owner and the others are owners as well? are they forced to be included in the channel? And, is it possible to add different fields? I understand (but it's not clear) these fields belongs to the configuration node, is it possible to add variables from information node like Name and Description? Thanks. Manuel Rubio. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: IM Routing-NG
Hi Evgeny, El 2018-03-29 07:34, Evgeny Khramtsov escribió: I was reading XEP-0344 (Impact of TLS and DNSSEC on Dialback). I understand that's for security connection between two XMPP servers (S2S). I meant XEP-0334 (Message Processing Hints) of course, sorry. I think the most important part of the XEP is the business rules. The behaviour for chat, groupchat and normal messages is changed. That's not provided by XEP-0334. I mean, based on RFC-6121 if I send a message to bare JID, that message should be dropped. Using this XEP, the message is routed using this alternative rules and it's delivered to all of the clients supporting the feature and logged in with the same bare JID. I saw this XEP isn't compatible with Carbons. So, how is it possible solve the issue when a user send a message and you want that message goes to all of the connected users for the same bare JID? Kind regards. Manuel Rubio. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: IM Routing-NG
Hi, for the name, please, change it for something like: - Alternative IM Routing - Improved IM Routing - Enhanced IM Routing - Updated IM Routing - ... NG is what marketing guys used 10 years ago for their products to indicate they are using the last technology or new technologies inside (i.e. routers, switches, ...). Kind regards. Manuel Rubio. El 2018-03-28 19:18, Jonas Wielicki escribió: The XMPP Extensions Editor has received a proposal for a new XEP. Title: IM Routing-NG Abstract: This specification provides a new set of routing rules for modern instant messaging. URL: https://xmpp.org/extensions/inbox/im-ng.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP. ___ 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] Proposed XMPP Extension: IM Routing-NG
Hi, I was reading XEP-0344 (Impact of TLS and DNSSEC on Dialback). I understand that's for security connection between two XMPP servers (S2S). I understood that IM-NG is a new way to route messages to JIDs with the same feature activated. Thinking about that, why sending the message to the bare JID isn't enough? I mean, at this moment if I connect two clients with the same priority and send a message to their bare JID, the same message should arrive to both of them. Why this NG is better? I think it could be better if instead of NG is RG (Resources Group) or GoR (Group of Resources). I disagree completely to use something la "modern" (modern age was betwen 1500 and 1800) or New Generation... if 5 years later you want to create another new generation it will be called NNG (New New Generation)? Kind regards. Manuel Rubio. El 2018-03-28 20:13, Evgeny Khramtsov escribió: Wed, 28 Mar 2018 17:18:36 - Jonas Wielicki (XSF Editor) <jo...@wielicki.name> wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: IM Routing-NG Abstract: This specification provides a new set of routing rules for modern instant messaging. Not sure why XEP-0344 can't be used for this. We just need to set in Example 6 and for other cases we need to introduce new element and a server's disco feature (I would rather use stream feature, but one can argue it should be negotiated blah-blah-blah). ___ 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 ___
[Standards] XEP-0369: 6.3 Ensuring Message Delivery
Hello, I was reading this XEP-0369 and I found in the section 6.3 it's in use "marker". For me this could be more similar to "ping" instead: And the result: That should work in the same way to ensure the client is there. At this moment reading "marker" I only think about XEP-0333 and that's a bit different from what you want to achieve here. Kind regards. Manuel Rubio. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)
Hi guys, I usually only read to understand and learn but sometimes I head up and freak out with some decision. I usually read RFC and when a new one is released it supersedes, deprecates or obsoletes another one. But, the status of that RFC usually is definitive. Obviously it's definitive until a better one is released (as Descartes always said there are nothing definitive only temporal until we can find a better solution/theory/explanation). In this case I can see you are putting "obsolete" to XEP-0071 and it's intended there are a new proposal better on the table... where? XEP-0071 has no explanation about why it was obsoleted only a vague description "Per a vote of the XMPP Council, advanced to Obsolete". I wanted to know "why". And more important, if the XEP-0071 is obsoleted because XEP-0393 is there... why XEP-0393 is experimental? I'm not pretty sure but looks like you are suggesting to use something experimental instead of something it was working for years. If XEP-0393 is the reason because XEP-0071 is obsoleted, I think it's fair enough to advance the state from experimental to something different for XEP-0393, IMO. Last thing, what's the usual flow for the states? I cannot find information here: https://xmpp.org/extensions/ ; there are only the possibility to filter based on those states but not information about what means each one or even how it could be advanced from one to another. Thanks. Manuel Rubio. El 2018-03-08 10:57, Goffi escribió: Le mercredi 7 mars 2018, 19:21:45 CET Kozlov Konstantin a écrit : Thank you for your reply. Yes, I know about those two. As for XEP-0394, I feel so bad the XEP idea, so I don't even want to discuss the XEP itself. Out of curiousity, what do you dislike in this XEP? I actually find the idea really good, it's a clean separation between content and style, which means that there is not need to send a text version as we have too with XHTML-IM. XEP-0393 on the other hand is totally mixing style and content, that's why I really dislike it. Goffi ___ 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 ___
