Re: [Standards] [Fwd: WG Action: Extensible Messaging and Presence Protocol (xmpp)]
Am 04.06.2009 um 04:00 schrieb Peter Saint-Andre: Nothing says that we can't finish things sooner than defined by the milestones on the charter (I'm not quite sure how those got defined, because I think we can finish sooner, but Working Group chairs and IETF Area Directors tend to be conservative about milestones). That's good to hear and quite a relief. The current situation of having only XEP-0027 for E2E encryption is quite limiting. Feel free to help in that effort instead of continually beating the dead horse of ESessions. Indeed, once I convert XEP-0210 to an Internet-Draft that specifies our requirements, you are free to write an Internet-Draft that proposes ESessions as the preferred direction for end-to-end encryption to meet those requirements (yes, the IETF is an open standards organization!). I'm not quite familiar with how such processes at the IETF work, but if my time allows me to, I will look how the process works and help where I can. (Keep in mind I have no PhD in cryptography, my only concern was that we were reinventing the wheel because we already had stuff that even works. I'm fine with another standard than ESessions, but no matter which standard it will be, it needs to get done ASAP. We've been talking about this for over a year already and there's still no standard everybody agreed on, not even to talk about a client implementing it). -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] [Fwd: WG Action: Extensible Messaging and Presence Protocol (xmpp)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/3/09 6:34 PM, Jonathan Schleifer wrote: > Am 29.05.2009 um 21:43 schrieb Peter Saint-Andre: > >> Goals and Milestones: >> >> Mar 2010 Decide upon a direction for server-to-server connection reuse. >> Aug 2010 Deliver rfc3920bis and rfc3921bis to the IESG. >> Dec 2010 Decide upon a direction for end-to-end encryption. >> Jan 2011 Define a framework for SIP-XMPP interworking. >> Feb 2011 Define a solution for server-to-server connection reuse. >> Aug 2011 Define a solution for end-to-end encryption. > > Great, so maybe we see some client being released in a stable version > that supports it in about 3 years. Nothing says that we can't finish things sooner than defined by the milestones on the charter (I'm not quite sure how those got defined, because I think we can finish sooner, but Working Group chairs and IETF Area Directors tend to be conservative about milestones). Feel free to help in that effort instead of continually beating the dead horse of ESessions. Indeed, once I convert XEP-0210 to an Internet-Draft that specifies our requirements, you are free to write an Internet-Draft that proposes ESessions as the preferred direction for end-to-end encryption to meet those requirements (yes, the IETF is an open standards organization!). 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 iEYEARECAAYFAkonKrEACgkQNL8k5A2w/vxnZACeLMLiYPk9IeIYgeT87/MbjXQg JM8AoPconqbGQIRkWFwtWfAL58j0uV0o =LFIx -END PGP SIGNATURE-
Re: [Standards] [Fwd: WG Action: Extensible Messaging and Presence Protocol (xmpp)]
Am 29.05.2009 um 21:43 schrieb Peter Saint-Andre: Goals and Milestones: Mar 2010 Decide upon a direction for server-to-server connection reuse. Aug 2010 Deliver rfc3920bis and rfc3921bis to the IESG. Dec 2010 Decide upon a direction for end-to-end encryption. Jan 2011 Define a framework for SIP-XMPP interworking. Feb 2011 Define a solution for server-to-server connection reuse. Aug 2011 Define a solution for end-to-end encryption. Great, so maybe we see some client being released in a stable version that supports it in about 3 years. I know you hate to hear this, but I think if we would have put some effort into ESessions, we would have had something usable much earlier. In fact, at least one client even has a stable release with ESessions. But it's too late now, things are decided and we have to wait until about the beginning of 2012 to have it in a stable release of a client… -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
[Standards] UPDATED: XEP-0198 (Stream Management)
Version 0.9 of XEP-0198 (Stream Management) has been released. Abstract: This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements, stream resumption, and throttling notifications. Changelog: [See revision history] (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0198.xml?%40diffMode=u&%40diffWrap=s&r1=3028&r2=3223&u=3&ignore=&k= URL: http://xmpp.org/extensions/xep-0198.html
Re: [Standards] LAST CALL: XEP-0198 (Stream Management)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/3/09 1:21 PM, Joe Hildebrand wrote: >> Peter Saint-Andre wrote: > >> I'm fine with starting at zero on reset, but we have already said that >> 'h' starts at 1 the first time around. I'd prefer to start in the same >> place each time. :) > > Let's always start with 0, then. WFM. /psa -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkom+xMACgkQNL8k5A2w/vzVmQCg8D0NffFQuGJUeFXLqokjkxOO PlcAn0/zim5D2o9HGSMgfhi2YJ1I9PEL =yVFj -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0198 (Stream Management)
On Wed Jun 3 21:32:59 2009, Justin Karneges wrote: I'm not sure about BOSH, but certainly any kind of plain TCP-based connection manager. If you have an intermediate client connection manager that does not do acks, but your server core does acks, then you'd want to ensure the connection manager doesn't try to be clever and filter anything. IMO this is a silly warning, and anyone designing a scalable server should know how to design appropriately. It's also more of an implementation note than a security note. Sure, but as far as XMPP is concerned, there are no intermediate client connection managers. The architecture is C2S, S2S, and P2P - no proxy involved. (The reality may well be different, and the reality may also include significant security issues, but I think this would need documenting somewhere else entirely). 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] FINAL: XEP-0199 (XMPP Ping)
Version 2.0 of XEP-0199 (XMPP Ping) has been released. Abstract: This specification defines an XMPP protocol extension for sending application-level pings over XML streams. Such pings can be sent from a client to a server, from one server to another, or end-to-end. Changelog: Per a vote of the XMPP Council, advanced status to Final. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0199.xml?%40diffMode=u&%40diffWrap=s&r1=934&r2=3220&u=3&ignore=&k= URL: http://xmpp.org/extensions/xep-0199.html
[Standards] UPDATED: XEP-0025 (Jabber HTTP Polling)
Version 1.2 of XEP-0025 (Jabber HTTP Polling) has been released. Abstract: This document defines an XMPP protocol extension that enables access to a Jabber server from behind firewalls which do not allow outgoing sockets on port 5222, via HTTP requests. Changelog: Per a vote of the XMPP Council, changed status to Obsolete. (psa) Diff: N/A URL: http://xmpp.org/extensions/xep-0025.html
[Standards] UPDATED: XEP-0023 (Message Expiration)
Version 1.3 of XEP-0023 (Message Expiration) has been released. Abstract: This specification documents an historical protocol that was used to specify expiration dates for messages; this protocol has been deprecated in favor of XEP-0079: Advanced Message Processing. Changelog: Per a vote of the XMPP Council, changed status to Obsolete. (psa) Diff: N/A URL: http://xmpp.org/extensions/xep-0023.html
[Standards] UPDATED: XEP-0011 (Jabber Browsing)
Version 1.3 of XEP-0011 (Jabber Browsing) has been released. Abstract: This document defines a way to describe information about Jabber entities and the relationships between entities. Note: This document is superseded by XEP-0030: Service Discovery. Changelog: Per a vote of the XMPP Council, changed status to Obsolete. (psa) Diff: N/A URL: http://xmpp.org/extensions/xep-0011.html
[Standards] UPDATED: XEP-0003 (Proxy Accept Socket Service (PASS))
Version 1.4 of XEP-0003 (Proxy Accept Socket Service (PASS)) has been released. Abstract: This document defines a method for relaying media via proxies on the Jabber/XMPP network. Changelog: Per a vote of the XMPP Council, changed status to Obsolete. (psa) Diff: N/A URL: http://xmpp.org/extensions/xep-0003.html
Re: [Standards] LAST CALL: XEP-0198 (Stream Management)
On Wednesday 03 June 2009 07:49:44 Peter Saint-Andre wrote: > On 6/2/09 3:42 PM, Dave Cridland wrote: > > I don't think it needs to mention intermediate proxies - that one had me > > bewildered until I realised it means transparent proxies between client > > and server. > > I suppose it means things like BOSH connection managers. Justin? I'm not sure about BOSH, but certainly any kind of plain TCP-based connection manager. If you have an intermediate client connection manager that does not do acks, but your server core does acks, then you'd want to ensure the connection manager doesn't try to be clever and filter anything. IMO this is a silly warning, and anyone designing a scalable server should know how to design appropriately. It's also more of an implementation note than a security note. -Justin
Re: [Standards] LAST CALL: XEP-0198 (Stream Management)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dave, thanks for the review. On 6/2/09 3:42 PM, Dave Cridland wrote: > On Thu May 28 21:50:34 2009, XMPP Extensions Editor wrote: > >> 4. Do you have any security concerns related to this specification? > > The Security Considerations section is a bit weak You're right! > - I think it should > make it clear that clients mustn't be allowed to resume other people's > streams, and discuss how this is prevented. (Answer, don't allow > unauthenticated clients to resume streams, etc). Yes, I will add some text about that. > I don't think it needs to mention intermediate proxies - that one had me > bewildered until I realised it means transparent proxies between client > and server. I suppose it means things like BOSH connection managers. Justin? >> 5. Is the specification accurate and clearly written? > > Mostly. I think it would be useful to define "handled" stanzas by way of > transfer of responsibility. > > That is to say, each stanza, under XEP-0198, is either the > responsibility of the sender (to send) or the receiver (to process, > forward, etc). Until a sender receives an ack for the stanza, it has > responsibility, and once the receiver sends an ack, it assumes > responsibility. Good point. > Example 12 uses the wrong single letter element local-name - doesn't it? Fixed. > I'll probably send more comments later. Thanks. 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 iEYEARECAAYFAkomjYgACgkQNL8k5A2w/vw7oQCg7VPKSbcvwQz40xx7FTUQrrlq ymEAnRsE4B8wwGhhHjTHornWUbLbSNr4 =IWTc -END PGP SIGNATURE-
[Standards] [Fwd: [Council] meeting minutes, 2009-06-03]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI. - Original Message Subject: [Council] meeting minutes, 2009-06-03 Date: Wed, 03 Jun 2009 13:35:32 -0600 From: Peter Saint-Andre Reply-To: XMPP Council To: XMPP Council Results of the XMPP Council meeting held 2009-06-03... Agenda: http://xmpp.org/council/agendas/2009-06-03.html Log: http://logs.jabber.org/coun...@conference.jabber.org/2009-06-03.html Scribe: Peter Saint-Andre 0. Roll call Present: Dave Cridland, Ralph Meijer, Jack Moffitt, Peter Saint-Andre, Kevin Smith. Absent: None. Quorum achieved. 1. Agenda bashing None. 2. XEP-0166: Jingle 3. XEP-0167: Jingle RTP Sessions 4. XEP-0176: Jingle ICE-UDP Transport Method 5. XEP-0177: Jingle Raw UDP Transport Method Advance from Experimental to Draft? Dave, Ralph, Jack, and Peter +1. Kev to vote on the list. 6. XEP-0199: XMPP Ping Are the implementation notes acceptable? All Council members +1, Peter will advance it to Final. 7. XEP-0003: Proxy Accept Socket Service (PASS) 8. XEP-0011: Jabber Browsing 9. XEP-0023: Message Expiration 10. XEP-0025: Jabber HTTP Polling Change from Deprecated to Obsolete? All Council members +1. 11. Any other business? None. 12. Next meeting Wednesday, July 17, 2009 http://xmpp.org/xsf/XSF.ics /psa -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkom0KcACgkQNL8k5A2w/vwhzACfeXlzvq11bZZUxwFOiVMCtbgo EOoAoMgupQkqBu26smVFOJkWjG1v56B7 =+/Ru -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0198 (Stream Management)
> Peter Saint-Andre wrote: > I'm fine with starting at zero on reset, but we have already said that > 'h' starts at 1 the first time around. I'd prefer to start in the same > place each time. :) Let's always start with 0, then.
