Re: [Standards] forwarding stanzas when to=/from= values are absent
Is a message without to/from permitted, or possible? I think the rules here http://xmpp.org/rfcs/rfc6120.html#stanzas-attributes would prevent it: To: "A stanza with a specific intended recipient (e.g., a conversation partner, a remote service, the server itself, even another resource associated with the user's bare JID) MUST possess a 'to' attribute whose value is an XMPP address." From: "When a server receives an XML stanza from a connected client, the server MUST add a 'from' attribute to the stanza" Best regards, Graham On 14-11-24 03:44 PM, Kurt Zeilenga wrote: > While XEP 297 states the following requirement: > > * The original sender and receiver should be identified. > > It is not clear how this requirement is fulfilled when one wants to > forward the stanza: > Hello > > how is the sender and receiver to be identified (when known to the > forwarding entity)? Add to=/from=attributes with values implied when > absent?
[Standards] XEP-0186 (Invisible Command) and MUC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 When a user goes invisible (XEP-0186), do they leave any MUC they might be in? That seems to be what this implies: > the server MUST send presence from > the specified resource to all contacts who would receive > unavailable presence if the client sent type='unavailable'/>. The room would normally get the unavailable, and unavailable is how you leave a room. My team was discussing correct behavior today and our tentative conclusion was that invisible users should leave a chatroom. It's also possible that a user could remain in the room but not show presence, and be allowed to message the room, similarly to how they can message a single user whilst invisible. That seems risky because you de-cloak yourself to everyone in the room and anyone who might join and see your message in the history. Could the intended behavior be clarified in the XEP? Thanks in advance, Graham -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUYkfRAAoJEBJ8/NmzuSnSSEcP/jTVrz+ptL0h/gBoKhIN5SFg 2zf8IvjsmS3+9xAC1yN8AHl0rum0l43k1lv6MCo11sasKL3firtXzLJ6cfrT6O9d HIqMlxTSFN9oX+4JYMNyEDLA+gcRfsvS+B4nijCiEK5NapshZpgPJVWSFGqAm1VJ O9R1NNkCPoH4C4IptLPqAUv2wq58VF77aJo0/bNrVLC2dCZqEk/jFTQ5LoaiYmXz +k9V+cATVK3Ghrsr4KUtp4L4UCUy6CI+qYlsAztOnRoif2L2f7mx3ojCyps0jD93 WrcZFyifTXMgojiD5uauXFPNdzD37Lsw2rpKo9FA3XfQCPc0vPMhOFH6RQu0aaBT HIV7t4stjOl9fcE1c0UkpmjRc0x/hTk2jBEiI63c3eSh/LD5R+U1giH79DVYZ0ZS iwWEo4Uj2HT2HmPNGjCwIVv0E0zdVGPBQu3RcBNn8nSoelvaRROprMDks+byMSLt 69gSfcz+1Oah3elJ2jp2i2SbCXgA7WihNLMZJ9yRXwQrcwweC0GWFngn9Ym8cs2y Sc+KBgmqpaoZIq24Xh8deCtG/i16qAEkD0tMohWP7avrDnqjBFTHZcRTj53bGakk lkCnAx+aN4jvzKJtiOGGYxBsJVki9FGWSchzK+LlZMGRr5BrFh2wURlbDnqqGWOh 3C9k9mWS4Bw8fN7wztnu =uncM -END PGP SIGNATURE-
Re: [Standards] OTR
On 14-11-07 07:32 AM, Ashley Ward wrote: > > Just as long as Romeo and Juliet don’t commit suicide too. Wait, what’s that > you say…? > Surely Julius Caesar (http://shakespeare.mit.edu/julius_caesar/index.html) would be the appropriate source for examples, being the only person to have both a Shakespeare play and a cipher named after him.
[Standards] XEP-0045 MUC should mention component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, XEP-0045 (Multi-User Chat) doesn't say that it should be implemented as a Component (XEP-0114). I think it should mention that. I remember getting quite confused when I first worked on implementing MUCs because I was new to XMPP. All the examples use a sub-domain (conference), but it doesn't say that you have to. If you try doing MUCs on the same domain as the main server (i.e. without component protocol), the disco gets confusing. Is there a reason that's not mentioned (other than it being obvious to everyone else)? If not, could I send in a patch to get the ball rolling? Thanks, Graham -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTxsWBAAoJEBJ8/NmzuSnSmTgP/0zJi27AN5lAmP0KiPP7/Tu2 bTp8O2XSHQZISB+KRicE30DryGkCkLGp7iGdVbUBrPFxp+rzn6YovvKLO2IQziiw yjlbJ4LnEY5vFqyMfaMShCCvtLkNMl5slr32q4m+goGLxXTra8HE+g4lCMp+KI9V Vn4GJL0JjzjqLcEXD01Tfm9hNZipTADZRnntzhm3pQGa4KAZ/iaIHtfgcrzT8Msz 0Nk2nZPv717Jf+2FB17E3Ad/dA0s1Al8GaGXMzfYxQQXBZUH2h0rGi07fbYT7+8r U4VOCK2EEZiPNrQkc/PVLiHcNuG+cRmxbdY0sWVDB0bR+/aPbz6mPyyMdYd7pw/+ ZxDncKRE8JB57rIGZeGaqKb5YE3UD4Q/+Qc/dBJSrC0HBf9V4f0bkp5Z28JlEiGa wLQUtTS5FWkTDwISfhH+V+c+zx2FR3Ye0tMbqrulTSwEQ9n0cnNgGLn+ol4/4tpA 0kyAr7Uw2Ti8UoMSgtZCECCToGuJNo7QIjLThYN1kqGmbwap/fNxgCI81XJN+RUn t6ti5oXXkIVewYQvj276Yn+44YhxYg1MpUM9vLAZ7z9i6VFUALbUVRezJgnnGAED YfMWTYRcw57ZxBjZP9huzVY2nLRzFqdk1DYl9i0Dg6B1eUks3llCrI5wcSPPOrWa jYfwxY9TgIOo0Dg6xnhz =JRhv -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)
On 14-07-16 12:39 AM, Dave Cridland wrote: > On 15 July 2014 23:59, Graham King > > In 2. Requirements / point 2, it says "Invisible mode is active only > for the current session". Could it say ".. only for the current > *presence* session (as defined in RFC 6121 section 4.1)"? I puzzled > over what "session" meant. > > > A presence session only begins when available presence is sent, so > this would mean you'd only be able to become invisible after telling > everyone you were there. I would have thought that would go against > the requirements, but it turns out that's not explicitly stated. > > > In "3.2 User Becomes Visible" I think it would be worth mentioning > that a user can also become visible by ending their presence session, > sending an unavailable presence. > > > So in your model, I'm assuming you're flexible about when exactly a > presence session begins, but the sequence type='unavailable'/> would always implicitly clear invisibility? > > I have to say I dislike the implicit changes here. > > But you're right that the use of the term "session" with no explicit > definition is confusing. I thought that the term was actually > defined somewhere, but it turns out not to be. I thought it meant a > client stream, as (possibly) extended over multiple connections by > XEP-0198. > We both assumed a different meaning for 'session', so it would be great to have the XEP clarify that. I like your meaning better, that invisibility applies to an XML Stream (RFC 6121, section 4). That would for example have avoided the multiple 'unavailable' bug we experienced. Applying invisibility to the XML Stream also supports Kamil's question about sending invisible iq before initial presence. If 'session' means 'presence session' it's ambiguous if you can make a not-yet-existing presence session invisible. If it applies to the XML Stream you are currently in, the behavior is more obvious.
Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I have recently been working with XEP-0186, and I wanted to add notes from my experience. I think some minor clarifications around when invisibility stops could be added. In 2. Requirements / point 2, it says "Invisible mode is active only for the current session". Could it say ".. only for the current *presence* session (as defined in RFC 6121 section 4.1)"? I puzzled over what "session" meant. In "3.2 User Becomes Visible" I think it would be worth mentioning that a user can also become visible by ending their presence session, sending an unavailable presence. Finally as an implementation note, we noticed that Smack (3.2.2, over BOSH) was sending two unavailable stanzas when it disconnects. The first would end the presence session and implicitly the invisibility, so the second got forwarded, which was not the client's intention. An implementation note might want to remark that the user should stay invisible until they start a new presence session (rather than until the current one ends). We fixed this by not forwarding unavailable stanzas for an already unavailable user, probably something we should have been doing already. I would be happy to send a patch for any part of this. Best regards, Graham On 14-06-19 07:59 PM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on > XEP-0186 (Invisible Command). > > Abstract: This document specifies an XMPP-compatible protocol for > user invisibility. > > URL: http://xmpp.org/extensions/xep-0186.html > > This Last Call begins today and shall end at the close of business > on 2014-07-03. > > 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! > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTxbI0AAoJEBJ8/NmzuSnSBY4P/1i1rzM5I+F5BG+T29Yqre5z lZ0BPIY90LZEBSWT1sNECmZXP4/B+v5nfLuCgs6a6Ao4yN9Emvln9PeFHmjqORbK ZDFnhLOM3zRXMrahZko8j0nLY3m09NeZrpe4EkuRITkzQgwN9KPofaLmO6vV3lDs vIU1YxK9N+iG5TDFa3VO5ZDCahsnUgpCr9r8dBfqb2xm5MZWTtntGyiD8bEsYWds XvXWulAuc0Utur7VSc9uB67rOe8R0kzB7pEEf+EX4FMbClDHR/uHge0fjUSCw9fh aFgGfhdsvT0/DTEQ2tuPYo1EQrm0tXjfNWPemQiiOzzHk9QgwVWzWGM85/sRFA/j 2KhPtXriTTB2gLivx/0MfwMEEIepnD1M9WKRo5GLffMzAKQPblxLy5U4JxVyj/wa 3lqV1MGjWOiqs/QYQQ+lrTIkTFWzSuP+9NpppdW+RJJ2I9X83V7KFW/zJOdJ2jvL pHLtu5Evs3xTG2oHHZ5wIjkseDAYw0Amp6qBAWMQKuVRnkPsyM7Fmxt/4V9yryE3 SBQWGBJnQIO8h2t8da7D8nraj8VG4BMrwKhr8za7fL3JwL8lHxa6HRcCwV+OE9wJ RQyuF2AxMMKp+E0nLvvZijKka8c1wyrtEfF6KjLlxXvZIWF436Z6H5M0RoWrBpeL XmWTi2EMquoAqPdhmJ2L =ry5u -END PGP SIGNATURE-
Re: [Standards] Disco presence subscription confusion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 14-06-11 11:29 AM, Lance Stout wrote: > On Jun 11, 2014, at 11:16 AM, Graham King wrote: >> >> Is this a correct reading? From the code I think this is how Prosody >> interprets it, and it makes intuitive sense (to me at least!). If this >> reading is correct, could I submit a patch to the XEP to clarify? > > > Sounds right. Send a patch. > > —Lance > Great. Here it is, attached. Graham -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTmLHTAAoJEBJ8/NmzuSnSB1QP/0EnwKIChJHYQCj0BTipACL4 W9AbioYlfXKepsw7AC0iK8/RO5IBGwEYUHZcM9MCMQd4AgnujQJXyvWXI+TLS3dH bBRsidEd7XITQHcPp6gjQcabNDYHOk4Wl3IAwOBaaGKvZU5zwq8E/YHsPEmmYFp/ NUoLdClJ64gDSt/ODLHtpx42oCtg7whRi69/DUkiqORTgL6yCLUwSuM1MUFV9v8O Z7ryH9GWus2Lu0vDWxt44tz7JuP3UKkRHeZthhqhtjUix95Iz1dcU7BUV4pauYlO KGrYwTbtAmhS3b1BIS2FoeJFECmQgRyO9uBMHRNZl/x6oX6RMV8itvp4LEXV69C2 luLNgkWlsNDH8/G6vf/lnAIzYOrKmVv/0PsgppFIYIwvdrqoNBxGwDKiyihssjw6 h6oIEWevVJTQ0qWjliUFKxHQl7mK3y2eCeO3WEVnd/90idiLr1ZngSjNKuX8e60J CFxZqdIB56hDLZ9C5RXMIYFOPHlrbKoJOxZiwQwwK4IaElJtdSwXlTEBbqmoMwi5 AiqBS9qyijPJX0xtnElkRxcv/acjDoJ75WsXjlOoKfZ6tQdiHQPDzZ8dKYmcs8m9 ytaAniPNa90KNUrzi7GaJdXFZCsW12yT5C60/9ST7ZRX95OYvP3DWkVTePVMLwCS syeTfydTE23zJ/oo8SIM =/l4e -END PGP SIGNATURE- diff --git a/extensions/xep-0030.xml b/extensions/xep-0030.xml index aaf4538..ac3c023 100644 --- a/extensions/xep-0030.xml +++ b/extensions/xep-0030.xml @@ -674,14 +674,14 @@ In response to a disco#info request, the server MUST return a &unavailable; error if one of the following is true: The target entity does not exist (no matter if the request specifies a node or not). - The requesting entity is not authorized to receive presence from the target entity (i.e., via a presence subscription of type "both" or "from") or is not otherwise trusted (e.g., another server in a trusted network). + The requesting entity is not authorized to receive presence from the target entity (i.e., via the target having a presence subscription to the requesting entity of type "both" or "from") or is not otherwise trusted (e.g., another server in a trusted network). In response to a disco#items request, the server MUST return an empty result set if: The target entity does not exist (no matter if the request specifies a node or not). - The request did not specify a node, the only items are available resources (as defined in RFC 3921), and the requesting entity is not authorized to receive presence from the target entity (i.e., via a presence subscription of type "both" or "from") or is not otherwise trusted (e.g., another server in a trusted network). However, the server MAY return items other than available resources (if any). + The request did not specify a node, the only items are available resources (as defined in RFC 3921), and the requesting entity is not authorized to receive presence from the target entity (i.e., via the target having a presence subscription to the requesting entity of type "both" or "from") or is not otherwise trusted (e.g., another server in a trusted network). However, the server MAY return items other than available resources (if any). xep-0030-security-clarification.patch.sig Description: PGP signature
[Standards] Disco presence subscription confusion
Hi, In XEP-0030 (Service Discovery - http://xmpp.org/extensions/xep-0030.html#security), it says "the server MUST return a error if": > The requesting entity is not authorized to receive presence from the target > entity (i.e., via a presence subscription of type "both" or "from") That reads to me like the requesting entity needs a "both" or "from" subscription. That wouldn't make sense though, because a "from" would imply the target is not sharing presence with the requesting entity. To make it work I read it like this, capitals my additions: > The requesting entity is not authorized to receive presence from the target > entity (i.e., via [THE TARGET HAVING] a presence subscription [TO THE > REQUESTING ENTITY] of type "both" or "from") Is this a correct reading? From the code I think this is how Prosody interprets it, and it makes intuitive sense (to me at least!). If this reading is correct, could I submit a patch to the XEP to clarify? Thanks in advance, Graham
Re: [Standards] Fwd: RFC 7081 on CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)
On 13-12-02 04:24 PM, Evgeny Khramtsov wrote: > Mon, 02 Dec 2013 13:53:46 -0700 > Peter Saint-Andre wrote: > >> This document suggests some strategies for the combined use of the >> Session Initiation Protocol (SIP) and the Extensible Messaging and >> Presence Protocol (XMPP) both in user-oriented clients and in >> deployed servers. > > Do we really need this? It seems like SIP usage is totally limited to > VoIP hardware and other usages exist in theory only. > > I personally stopped any attempts in making SIP interoperable with XMPP > as this is mostly a waste of a time. > We're a team of six, currently building a SIP and XMPP server in Go. It's just IM, no VOIP. We're replacing Microsoft LCS (SIP/SIMPLE), and gradually migrating to XMPP. There will be a significant overlap of SIP users on a proprietary desktop client, and XMPP / BOSH users in a webapp, who need to talk to each other including in chatrooms. So for us at least, it's not entirely theoretical :-)
