[Standards] UPnP and XMPP
I haven’t heard anything from the XMPP/UPnP Liaisons, but I just stumbled over this on the UPnP homepage (http://upnp.org/news/2014/): https://www.youtube.com/watch?v=V-QpNnQrT2U&list=UUY7zsGPIO9PRbUDv1obTBWQ Personally I am hoping for some progress for Multi-Screen and XMPP which I have been working with for a while. Anyone know how I can get involved in this Committee? Any of you Liaisons that have been involved? I thought it might be interesting for you guys. :-) #Standards #XMPP #MUC #CLOUD -Cheers! /Steffen smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Disco presence subscription confusion
Am 11.06.2014 20:16, schrieb Graham King: 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? I thought I had an open issue with this because the requesting entity might also be authorized via directed presence... but can't find it right now. I like "sharing presence with the requesting entity". This covers both presence subscriptions and directed presence.
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
Re: [Standards] Disco presence subscription confusion
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 signature.asc Description: Message signed with OpenPGP using GPGMail
[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
