[Standards] XMPP over Websocket vs XEP-0198
Hi, within Section 3.5[1] XMPP over Websocket states that the closing party MUST close the XMPP stream if it has been established. With hindsight of page transitions within legacy web apps this might not be wanted by the client as it might wish to resume the stream by use (abuse?) of XEP-0198 or some other technique. Now my questions are: * Is there some other best practice known how to deal with page transitions other than XEP-0198? * Would XEP-0198 be well suited for this scenario? * Do we need/want to support this scenario after all within this Draft? If not, why? Maybe this could be just one more topic on the summits agenda next week. I've seen there's already quite some demand discussing things regarding web related topics. Regards, Steve [1] https://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-01#section-3.5
[Standards] XEP-0198 and SASL-Anonymous
Hi, And now we are talking about XEP-0198, I think the security considerations should take some more situations in account for the session hijacking protection. When properly and securely authenticated, the authentication is enough protection against sesion hijacking. But when using SASL-Anonymous, the session id MUST be unpredictable AND the session MUST be encrypted, otherwise the session can be hijacked. Think it would be better to add that to the spec. Winfried
[Standards] some more questions about XEP-0198
Hi, Reading XEP-0198, I was wondering two things: - Is there a reason acking and resuming, imho two different and independent things, are in one XEP? - Is there also a XEP that takes care of resending a stanza when it does not get acked? Winfried
Re: [Standards] some more questions about XEP-0198
On 01/25/2013 03:16 PM, Stefan Strigler wrote: Hi, In order to resend unacknowledged stanzas upon resuming a stream you need to know about request and anwers. Clear answer, it made me realise I was thinking about a different case: what to do when only one or two stanzas are dropped but then the stream is continued? In that case the session is not resumed, but the acking fails... Winfried
Re: [Standards] XEP-0198 and SASL-Anonymous
On Jan 25, 2013, at 7:08 AM, Winfried Tilanus winfr...@tilanus.com wrote: Hi, And now we are talking about XEP-0198, I think the security considerations should take some more situations in account for the session hijacking protection. When properly and securely authenticated, the authentication is enough protection against sesion hijacking. But when using SASL-Anonymous, the session id MUST be unpredictable AND the session MUST be encrypted, otherwise the session can be hijacked. Think it would be better to add that to the spec. Those are good points, although transport encryption is only as trusted as the certificate in use (think of all the times we have clicked I understand the risks...). I think it should also be valid for the server to prohibit stream management resumption if using SASL ANONYMOUS. - mm Matthew A. Miller http://goo.gl/LK55L smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] XMPP over Websocket vs XEP-0198
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/25/13 9:42 AM, Winfried Tilanus wrote: On 01/25/2013 05:15 PM, Peter Saint-Andre wrote: Peter, [1] https://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-01#section-3.5 IMHO that spec needs quite a bit of work, still. New editors might be required to get it done. However, it appears that this document will probably become an official work item of the XMPP WG at the IETF (I sent proposed charter text to the chairs last night), so discussion there might be appropriate at some point too. Do you have an overview of issues with that draft? No, but I plan to review it in detail before the Summit. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlECtnoACgkQNL8k5A2w/vxIKACgh5Hhf4sg0y5JmIzzUqPapCtZ oxUAoIPbNuy1P6U0GXzPiRHpVtVONow/ =J9d+ -END PGP SIGNATURE-
Re: [Standards] Disco Search
On Friday, January 25, 2013 10:31:32 PM Dave Cridland wrote: b) A generalized mechanism for constructing node names programmatically to find such information? Say urn:xmpp:disco:search?owner=d...@jabber.org for example. XEP-303 suggests something exactly like this: 'A dynamic node accepts additional parameters by appending the parameters to the node name using a query-like notation. Parameters and values in the query string MUST be percent-encoded.' I think this would be a useful concept to share across pubsub-based specs. Justin
Re: [Standards] Disco Search
I too have been working with several extensions lately that need search capabilities, so this has been in my mind the last few days. I don't have fully formed ideas on how how it would look, etc, but I would be interested in experimenting with expanding (or drafting a replacement) XEP-0055 to include a node parameter to scope what is being searched and use that instead. Eg, with expanding the existing search XEP: query xmlns=jabber:iq:search node=urn:xmpp:somethingappropriate x xmlns=jabber:x:data type=submit field var=FORM_TYPEvalueurn:xmpp:pubsub:search/value/field field var=ownervalued...@jabber.org/value/field /x /query Or with some new XEP similar to RSM to augment a normal query: query xmlns=http://jabber.org/protocol/disco#items; search xmlns=urn:xmpp:search:0 x xmlns=jabber:x:data field var=FORM_TYPEvalueurn:xmpp:search:pubsub/value/field field var=ownervalued...@jabber.org/value/field /x /search /query As for disco node names with query parameters, it works and I know XEP-0303 uses it, but it opens up a can of worms of implementation details and variations that I'd prefer to avoid if possible. Lance On Jan 25, 2013, at 2:31 PM, Dave Cridland d...@cridland.net wrote: Hi folks, I have a use case for finding all pubsub nodes on a service for which the caller has an owner affiliation. I'm implementing this as a private extension comprising a well-known disco node, which when given a disco#items query would list such nodes. Is there any interest in standardizing: a) Such a node. b) A generalized mechanism for constructing node names programmatically to find such information? Say urn:xmpp:disco:search?owner=d...@jabber.org for example. Dave. smime.p7s Description: S/MIME cryptographic signature
