Re: [Standards] XEP-0215 and STUN/TURN
Peter Saint-Andre wrote: Yes, I think that SIP and XMPP can share TURN credentials. Why not? From the perspective of the TURN relay there is no difference between the two (as far as I can see). Actually there may be a problem when both SIP and XMPP server have its own embedded TURN server :-/ When in doubt, add another layer of indirection? :) +1. That's why I'm asking about shared secret request separation: we can implement only secret allocation in our server. If one wants to implement a discovery part as well in his own server - no problem ;) -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
[Standards] XEP-0175 feedback
In general, the proposed changes in v1.2 at http://xmpp.org/extensions/tmp/xep-0175-1.2.html are sound ones. I do however have some minor points to raise. 1) The current wording states that anonymous users SHOULD NOT be able to establish long term relationships. I believe this is too strong. I think that it will be quite common to use SASL ANONYMOUS clients to do things like pubsub scriptions and creating muc rooms. My team and I have done this in nearly every app we've written. I do however agree that it makes sense to tear these down once the session is over. I propose the following wording instead: Anonymous users MAY establish relationships with services and users if allowed by sever policy such as presence subscriptions, multi-user chat rooms, and pubsub subscriptions. If a server permits these relationships, it MUST cancel such relationships when the user's session ends. I might add another sentence as well: It is not recommended that SASL ANONYMOUS users add human contacts to their rosters, as this may create odd user experiences. 2) The next line states that users SHOULD NOT store things on the server, and that if so the server MUST delete them. This is also overly restrictive. I can see several use cases where one would want to temporarily store something on the server and retrieve it in another session, similar to an HTTP cookie. I think that it should be the server operators perogative to allow or disallow storage and to determine when that storage is undone. Perhaps changing the MUST to MAY is enough. I do think that Peter's previous feedback of there being two different scenarios is spot on. Some of us see this as what should SASL ANONYMOUS users be able to do on jabber.org and some of us are not running IM servers, but using SASL ANONYMOUS as a tool in a bigger application. I think the above wording proposals are good enough for both cases, but if people feel strongly otherwise, I think we may have to split this into two sections of recommendations for the different use cases. jack.
Re: [Standards] XEP-0175 1.2rc1
My use is more of a lazy hack. I want to use the anonymous JID resource to store information about BOSH clients. For example, we could have a number of web pages on different domains connecting via proxy to a single BOSH service and we would like to know at a glance the domain name of the site they are connecting from Wouldn't a better way to do this be the RFC 4505 trace data? You could put shuch data into the auth/ element and use it on the backend or whereever to identify users this way. I assume that is the purpose of trace data. This however, may not be well supported in servers. I only thought of it as I saw it mentioned at the end of the recommendation section of the XEP 175 changes. jack.
[Standards] FINAL: XEP-0202 (Entity Time)
Version 2.0 of XEP-0202 (Entity Time) has been released. Abstract: This specification defines an XMPP protocol extension for communicating the local time of an entity, including the time in UTC according to the entity as well as the offset from UTC. The time format itself conforms to the dateTime profile of ISO 8601 defined in XEP-0082. Changelog: Per a vote of the XMPP Council, advanced specification from Draft to Final. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0202.xml?r1=1555r2=3409 URL: http://xmpp.org/extensions/xep-0202.html
Re: [Standards] XEP-0175 feedback
Cheers, 2009/9/11 Jack Moffitt j...@collecta.com: In general, the proposed changes in v1.2 at http://xmpp.org/extensions/tmp/xep-0175-1.2.html are sound ones. I do however have some minor points to raise. 1) The current wording states that anonymous users SHOULD NOT be able to establish long term relationships. I believe this is too strong. I think that it will be quite common to use SASL ANONYMOUS clients to do things like pubsub scriptions and creating muc rooms. My team and I have done this in nearly every app we've written. I do however agree that it makes sense to tear these down once the session is over. I propose the following wording instead: Anonymous users MAY establish relationships with services and users if allowed by sever policy such as presence subscriptions, multi-user chat rooms, and pubsub subscriptions. If a server permits these relationships, it MUST cancel such relationships when the user's session ends. I agree. I also often allow SASL ANONYMOUS clients to have time based PubSub subscriptions (or even presence based on my tests). Same for muc rooms based stuff. When user's session ends the cleaning must be done accordingly of course. Good weekend for all, -- tuomas 2009/9/11 Jack Moffitt j...@collecta.com: I might add another sentence as well: It is not recommended that SASL ANONYMOUS users add human contacts to their rosters, as this may create odd user experiences. 2) The next line states that users SHOULD NOT store things on the server, and that if so the server MUST delete them. This is also overly restrictive. I can see several use cases where one would want to temporarily store something on the server and retrieve it in another session, similar to an HTTP cookie. I think that it should be the server operators perogative to allow or disallow storage and to determine when that storage is undone. Perhaps changing the MUST to MAY is enough. I do think that Peter's previous feedback of there being two different scenarios is spot on. Some of us see this as what should SASL ANONYMOUS users be able to do on jabber.org and some of us are not running IM servers, but using SASL ANONYMOUS as a tool in a bigger application. I think the above wording proposals are good enough for both cases, but if people feel strongly otherwise, I think we may have to split this into two sections of recommendations for the different use cases. jack.
Re: [Standards] XEP-0175 feedback
On Fri Sep 11 18:27:10 2009, Jack Moffitt wrote: Anonymous users MAY establish relationships with services and users if allowed by sever policy such as presence subscriptions, multi-user chat rooms, and pubsub subscriptions. If a server permits these relationships, it MUST cancel such relationships when the user's session ends. That's what I took it to mean by long term relationships. A pubsub subscription that only lasts a session is, IMHO, comfortably within the one-night-stand length. Still, I'd go for SHOULD NOT, I can conceive of cases whereby this rule may need breaking, at least locally. It is not recommended that SASL ANONYMOUS users add human contacts to their rosters, as this may create odd user experiences. This makes sense, too. I'd go for NOT RECOMMENDED, though. (== SHOULD NOT). 2) The next line states that users SHOULD NOT store things on the server, and that if so the server MUST delete them. This is also overly restrictive. I can see several use cases where one would want to temporarily store something on the server and retrieve it in another session, similar to an HTTP cookie. I think that it should be the server operators perogative to allow or disallow storage and to determine when that storage is undone. Perhaps changing the MUST to MAY is enough. Or SHOULD, with a note that there are cases where service operators may need to rely on storage of data by anonymous clients. SHOULD means Do this unless you know better. I do worry that although *you* certainly do know when to break these rules, a server implementor might think Oh, hey, I don't have to do that then. The note implies that a configuration option might be useful to control this. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
[Standards] NEW: XEP-0272 (Multiparty Jingle (Muji))
Version 0.1 of XEP-0272 (Multiparty Jingle (Muji)) has been released. Abstract: This specification defines an XMPP protocol extension for initiating and managing multiparty voice and video conferences within an XMPP MUC Changelog: Initial published version as accepted for publication by the XMPP Council. (psa) Diff: N/A URL: http://xmpp.org/extensions/xep-0272.html
Re: [Standards] XEP-0175 1.2rc1
On Sep 11, 2009, at 10:29 AM, Jack Moffitt wrote: My use is more of a lazy hack. I want to use the anonymous JID resource to store information about BOSH clients. For example, we could have a number of web pages on different domains connecting via proxy to a single BOSH service and we would like to know at a glance the domain name of the site they are connecting from Wouldn't a better way to do this be the RFC 4505 trace data? You could put shuch data into the auth/ element and use it on the backend or whereever to identify users this way. I assume that is the purpose of trace data. No! trace data should, at most, just be logged. It's intended to have no semantic value. By using it to identify a particular anonymous user (across sessions) you are adding a semantic. -- Kurt This however, may not be well supported in servers. Most SASL implementations I know of won't expose the trace information to the calling application program, except possibly as data to be logged. I only thought of it as I saw it mentioned at the end of the recommendation section of the XEP 175 changes. jack.
[Standards] DEFERRED: XEP-0246 (End-to-End XML Streams)
XEP-0246 (End-to-End XML Streams) has been Deferred because of inactivity. Abstract: This specification defines methods for communicating via end-to-end XML streams over a logical or physical connection that provides a reliable transport between two endpoints. URL: http://www.xmpp.org/extensions/xep-0246.html If and when a new revision of this XEP is published, its status will be changed back to Experimental.
[Standards] DEFERRED: XEP-0248 (PubSub Collection Nodes)
XEP-0248 (PubSub Collection Nodes) has been Deferred because of inactivity. Abstract: This specification defines the nature and handling of collection nodes in the XMPP publish-subsribe extension. URL: http://www.xmpp.org/extensions/xep-0248.html If and when a new revision of this XEP is published, its status will be changed back to Experimental.
[Standards] DEFERRED: XEP-0250 (C2C Authentication Using TLS)
XEP-0250 (C2C Authentication Using TLS) has been Deferred because of inactivity. Abstract: This document describes how to negotiate TLS extensions when using TLS for end-to-end XML streams between two clients. It covers X.509 certificates with an without CA, the use of OpenPGP, Shared Remote Passwords (SRP) and how to use one extension to bootstrap a trust relationship. URL: http://www.xmpp.org/extensions/xep-0250.html If and when a new revision of this XEP is published, its status will be changed back to Experimental.
Re: [Standards] DEFERRED: XEP-0248 (PubSub Collection Nodes)
On 11-Sep-2009, at 17:41, XMPP Extensions Editor wrote: XEP-0248 (PubSub Collection Nodes) has been Deferred because of inactivity. Abstract: This specification defines the nature and handling of collection nodes in the XMPP publish-subsribe extension. URL: http://www.xmpp.org/extensions/xep-0248.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. This saddens me, since I make a lot of use of it. Do you need help with it? -bjc
Re: [Standards] DEFERRED: XEP-0248 (PubSub Collection Nodes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/11/09 3:41 PM, XMPP Extensions Editor wrote: XEP-0248 (PubSub Collection Nodes) has been Deferred because of inactivity. Abstract: This specification defines the nature and handling of collection nodes in the XMPP publish-subsribe extension. URL: http://www.xmpp.org/extensions/xep-0248.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. I shall endeavor to publish a new version of this spec by the end of September, but until then XSF process says it needs to Deferred. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqqxIIACgkQNL8k5A2w/vxEPACfSNHCfn4XbI8Twn0vEMZlQWF6 Xg8AniRSwBxLTUzvjXIfmuK5rn458OiI =Cj5K -END PGP SIGNATURE-
Re: [Standards] DEFERRED: XEP-0248 (PubSub Collection Nodes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/11/09 3:43 PM, Brian Cully wrote: On 11-Sep-2009, at 17:41, XMPP Extensions Editor wrote: XEP-0248 (PubSub Collection Nodes) has been Deferred because of inactivity. Abstract: This specification defines the nature and handling of collection nodes in the XMPP publish-subsribe extension. URL: http://www.xmpp.org/extensions/xep-0248.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. This saddens me, since I make a lot of use of it. Do you need help with it? Don't be sad, it will be back soon. But if you'd like to help, feel free. I'll get to work on PubSub edits next week, but I shall put highest priority on XEP-0060. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqqxNAACgkQNL8k5A2w/vw7PwCffeZtn8KkyOiQyLVb8022J4Gp 28MAn3L3ZhNp9+gylo1qYyjzvNxgbWdT =ch/g -END PGP SIGNATURE-
