Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On Thu, Jul 21, 2011 at 5:41 AM, Waqas Hussain waqa...@gmail.com wrote: On Thu, Jul 21, 2011 at 2:36 AM, Dave Cridland d...@cridland.net wrote: On Tue Jul 19 17:03:00 2011, Peter Saint-Andre wrote: On Tue, Jul 19, 2011 at 09:00:36AM +0100, Dave Cridland wrote: My plan would be that implementers would host an XML description of their compliance levels, which the XSF's software listings would consume and render into the software list. This would mean that most changes (latest version, Core/Advanced, XEPs) would be implementer-driven. If there is interest, I'll sketch this out in more detail. Sounds intriguing. So the idea is that instead of saying to the XSF, Hey, we're Isode, and we do this server called M-Link, we'd say Hey, we're Isode, and we have an implementation description at http://www.isode.com/mlink.xml;. Now, mlink.xml would say something like: implementation xmlns='urn:xmpp:implementation-description' type='server' implementer url='http://www.isode.com/'Isode Ltd/implementer fullname url='http://www.isode.com/products/m-link.html'Isode M-Link/fullname versionR15.0v1/version xep num='220'/ xep num='198'/ xep num='45'/ xep num='163'/ xep num='60'/ !-- [... and so on ...] -- /implementation So the XSF gathers together all these in a magical way - such as having a file somewhere which says: software-list xi:include href='http://www.isode.com/mlink.xml'/ /software-list And then runs an XSLT over that periodically which spits out the HTML page, where this stuff is rendered. Now we can have that XSLT check to see what compliance levels are hit automatically, and add them in. Also added in would be a disclaimer to state that all information was provided by the developers and the XSF takes no position on its reliability - which is mechanically true. Dave. This is a nice idea. It has been discussed before, and attempts made. One similar though not equivalent project was by Kim Alvefur (https://github.com/Zash/XMPP-Features/tree/yaml), and vendors providing the data in an XML file was discussed in the Prosody room. There's just one problem: This requires that vendors provide sane data. As one example jabberd2 has XEP-0198 support listed on their home page: http://codex.xiaoka.com/wiki/jabberd2:start (the link on the page has been changed to an older version of the spec, which is better). Then require a version number in the XML from vendors, and then determine whether it's latest or not during the rendering :) /K
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On Thu Jul 21 05:41:31 2011, Waqas Hussain wrote: There's just one problem: This requires that vendors provide sane data. Vendors providing false or misleading data will get shot down soon enough. For commercial vendors (open source or not) such behaviour has legal impacts, so the XSF explicitly only presenting the vendor's data has advantages here, too. 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
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On Tue Jul 19 17:03:00 2011, Peter Saint-Andre wrote: On Tue, Jul 19, 2011 at 09:00:36AM +0100, Dave Cridland wrote: My plan would be that implementers would host an XML description of their compliance levels, which the XSF's software listings would consume and render into the software list. This would mean that most changes (latest version, Core/Advanced, XEPs) would be implementer-driven. If there is interest, I'll sketch this out in more detail. Sounds intriguing. So the idea is that instead of saying to the XSF, Hey, we're Isode, and we do this server called M-Link, we'd say Hey, we're Isode, and we have an implementation description at http://www.isode.com/mlink.xml;. Now, mlink.xml would say something like: implementation xmlns='urn:xmpp:implementation-description' type='server' implementer url='http://www.isode.com/'Isode Ltd/implementer fullname url='http://www.isode.com/products/m-link.html'Isode M-Link/fullname versionR15.0v1/version xep num='220'/ xep num='198'/ xep num='45'/ xep num='163'/ xep num='60'/ !-- [... and so on ...] -- /implementation So the XSF gathers together all these in a magical way - such as having a file somewhere which says: software-list xi:include href='http://www.isode.com/mlink.xml'/ /software-list And then runs an XSLT over that periodically which spits out the HTML page, where this stuff is rendered. Now we can have that XSLT check to see what compliance levels are hit automatically, and add them in. Also added in would be a disclaimer to state that all information was provided by the developers and the XSF takes no position on its reliability - which is mechanically true. 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
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On Thu, Jul 21, 2011 at 2:36 AM, Dave Cridland d...@cridland.net wrote: On Tue Jul 19 17:03:00 2011, Peter Saint-Andre wrote: On Tue, Jul 19, 2011 at 09:00:36AM +0100, Dave Cridland wrote: My plan would be that implementers would host an XML description of their compliance levels, which the XSF's software listings would consume and render into the software list. This would mean that most changes (latest version, Core/Advanced, XEPs) would be implementer-driven. If there is interest, I'll sketch this out in more detail. Sounds intriguing. So the idea is that instead of saying to the XSF, Hey, we're Isode, and we do this server called M-Link, we'd say Hey, we're Isode, and we have an implementation description at http://www.isode.com/mlink.xml;. Now, mlink.xml would say something like: implementation xmlns='urn:xmpp:implementation-description' type='server' implementer url='http://www.isode.com/'Isode Ltd/implementer fullname url='http://www.isode.com/products/m-link.html'Isode M-Link/fullname versionR15.0v1/version xep num='220'/ xep num='198'/ xep num='45'/ xep num='163'/ xep num='60'/ !-- [... and so on ...] -- /implementation So the XSF gathers together all these in a magical way - such as having a file somewhere which says: software-list xi:include href='http://www.isode.com/mlink.xml'/ /software-list And then runs an XSLT over that periodically which spits out the HTML page, where this stuff is rendered. Now we can have that XSLT check to see what compliance levels are hit automatically, and add them in. Also added in would be a disclaimer to state that all information was provided by the developers and the XSF takes no position on its reliability - which is mechanically true. Dave. This is a nice idea. It has been discussed before, and attempts made. One similar though not equivalent project was by Kim Alvefur (https://github.com/Zash/XMPP-Features/tree/yaml), and vendors providing the data in an XML file was discussed in the Prosody room. There's just one problem: This requires that vendors provide sane data. As one example jabberd2 has XEP-0198 support listed on their home page: http://codex.xiaoka.com/wiki/jabberd2:start (the link on the page has been changed to an older version of the spec, which is better). That said, I suppose I'm being too pessimistic. The idea is good enough to deserve an implementation. -- Waqas Hussain
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On Tue Jul 19 08:09:42 2011, Jacek Konieczny wrote: On Mon, Jul 18, 2011 at 03:23:26PM -0600, Peter Saint-Andre wrote: FYI, I've created version 0.0.2 of this ProtoXEP: http://xmpp.org/extensions/inbox/compliance2012.html I would prefer the 'Core' term to be left for the XMPP Core. XMPP is not IM only, and 'Core server' seems a good name for an entity witch implements only RFC 6120 (which is already 'XMPP Core') and RFC 6122 (required by 6120) – that is good enough for some non-IM communication purposes. This does not need to be defined in a XEP. I thought it was 'basic client' and 'basic server' in the XEP-242,243, but now I see it was already 'core'. Though, I think it still can be changed in the new XEPs. We switched to Core/Advanced some time back, when I was on Council. I pushed for the change, and asked Will (Sheward) to come up with new names. The problem is that - and I admit this hasn't really happened - these compliance XEPs are worthless unless they're used by implementers, consultants, and consumers to indicate high-level functionality, and nobody wanted to describe their server, for instance, as Basic in their marketing literature. (And by marketing literature, I include open-source project websites, for the avoidance of doubt). Core is a much more palatable term to use, and Advanced is obviously just fine. However, neither term has really caught on, and the XSF is not using it internally, even. If we choose to publish this document, I think we should consider adding implementer compliance statements to the software lists, to promote their use. I'd be happy to work on a specification to allow that, as well as (with my Isode hat on) provide such a statement. My plan would be that implementers would host an XML description of their compliance levels, which the XSF's software listings would consume and render into the software list. This would mean that most changes (latest version, Core/Advanced, XEPs) would be implementer-driven. If there is interest, I'll sketch this out in more detail. 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
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On Tue, Jul 19, 2011 at 09:00:36AM +0100, Dave Cridland wrote: On Tue Jul 19 08:09:42 2011, Jacek Konieczny wrote: On Mon, Jul 18, 2011 at 03:23:26PM -0600, Peter Saint-Andre wrote: FYI, I've created version 0.0.2 of this ProtoXEP: http://xmpp.org/extensions/inbox/compliance2012.html I would prefer the 'Core' term to be left for the XMPP Core. XMPP is not IM only, and 'Core server' seems a good name for an entity witch implements only RFC 6120 (which is already 'XMPP Core') and RFC 6122 (required by 6120) – that is good enough for some non-IM communication purposes. This does not need to be defined in a XEP. I thought it was 'basic client' and 'basic server' in the XEP-242,243, but now I see it was already 'core'. Though, I think it still can be changed in the new XEPs. We switched to Core/Advanced some time back, when I was on Council. I pushed for the change, and asked Will (Sheward) to come up with new names. The problem is that - and I admit this hasn't really happened - these compliance XEPs are worthless unless they're used by implementers, consultants, and consumers to indicate high-level functionality, and nobody wanted to describe their server, for instance, as Basic in their marketing literature. (And by marketing literature, I include open-source project websites, for the avoidance of doubt). Core is a much more palatable term to use, and Advanced is obviously just fine. Right. This is more about marketing than technology. Core and Advanced is fine with me. I also think that 2012 might be the year for us to define a Media suite for clients However, neither term has really caught on, and the XSF is not using it internally, even. If we choose to publish this document, I think we should consider adding implementer compliance statements to the software lists, to promote their use. I'd be happy to work on a specification to allow that, as well as (with my Isode hat on) provide such a statement. My plan would be that implementers would host an XML description of their compliance levels, which the XSF's software listings would consume and render into the software list. This would mean that most changes (latest version, Core/Advanced, XEPs) would be implementer-driven. If there is interest, I'll sketch this out in more detail. Sounds intriguing. /psa
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On 7/12/11 12:46 PM, Peter Saint-Andre wrote: On 7/11/11 6:26 PM, Waqas Hussain wrote: On Wed, Jul 6, 2011 at 10:26 PM, XMPP Extensions Editoredi...@xmpp.org wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: XMPP Compliance Suites 2012 Abstract: This document defines XMPP protocol compliance levels for 2012. URL: http://www.xmpp.org/extensions/inbox/compliance2012.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. Some thoughts: One caveat: that inbox item was simply copied without modification from the 2010 compliance suite (XEP-0270). We neglected to publish a compliance suite in 2011, so XEP-0270 reflects the state of the art in mid-2009. Why is BOSH included in the list when we say * Support can be enabled via an external component or an internal server module/plugin.? Any XMPP compliant server would pass that, so there's no point in making this an explicit item. See Dave's comments. RFC 6122 is missing. Yes, we need to add that. I'm assuming the XSF is using the compliance XEPs as a tool to encourage implementation. In part. Ideally we would use the compliance suites for testing purposes, but to do that we would need a testing program or protocol validator or something along those lines. Yet to be developed... If that is correct, then: There's a case to be made for caps support for Advanced Server, as some servers do flood users with PEP without taking caps into account. +1 (Although we have bugs to fix in XEP-0115...) What is the case for Chat State Notifications for Advanced Client? I mean it's useful, just like a hundred other XEPs, but is it useful enough to be made into a compliance requirement? I think it is. Now, things which are missing, but shouldn't be: Working file transfer should be a requirement for Advanced Client. We're pushing to finish the Jingle file transfer specs this year, but it might be too early to mandate support for them because their status is as follows: 1. XEP-0260 (Jingle SOCKS5 Bytestreams Transport Method) is currently in Last Call. Please review it and provide feedback. 2. XEP-0261 (Jingle In-Band Bytestreams Transport Method) is currently in Last Call. Please review it and provide feedback. 3. XEP-0234 (Jingle File Transfer) is still Experimental. It might need more work. I hope that the 2013 compliance suite for advanced clients can mandate XEP-0234 support. I'm not sure if audio/video support should be a compliance requirement for Advanced Client, but some would think so. In the past we talked about defining a Multimedia Client suite. Not all clients want or need to do audio/video. And finally, I'd personally like Message Receipts being included in more clients. They make a huge difference when you are on a bad network (e.g., most mobile networks outside of central city areas across the world). That's worth discussing. As Dave and Matthew noted, XEP-0198 would be very good to add to the compliance suite, too. FYI, I've created version 0.0.2 of this ProtoXEP: http://xmpp.org/extensions/inbox/compliance2012.html Still waiting to hear if Nathan Fritz has any objections before assigning it a XEP number... Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On Tue Jul 12 01:26:55 2011, Waqas Hussain wrote: Why is BOSH included in the list when we say * Support can be enabled via an external component or an internal server module/plugin.? Any XMPP compliant server would pass that, so there's no point in making this an explicit item. Bear in mind that these are marketing and/or procurement terms, primarily. So if you went up to a consultant and said We need an Advanced Server 2012, they would need to give you an XMPP solution that supported BOSH, whether or not they'd gone out and installed PunJab. RFC 6122 is missing. I'm assuming the XSF is using the compliance XEPs as a tool to encourage implementation. If that is correct, then: There's a case to be made for caps support for Advanced Server, as some servers do flood users with PEP without taking caps into account. Agreed - XEP-0115 is a requirement for PEP. There are also server cases, too. What is the case for Chat State Notifications for Advanced Client? I mean it's useful, just like a hundred other XEPs, but is it useful enough to be made into a compliance requirement? I'm ambivalent about this. I do appreciate it's one of those features with high user demand. Now, things which are missing, but shouldn't be: Working file transfer should be a requirement for Advanced Client. Agreed - really I think we want Jingle FT with IBB and S5B, but that also implies a need to support S5B proxying on the server. The trouble is, it's not clear we're ready with those specs. I'm not sure if audio/video support should be a compliance requirement for Advanced Client, but some would think so. I'm hoping that Jingle Voice etc become compliance bundles, so it's possible to say that MegaJabber 2.4 is Advanced Client 2012 with Jingle Voice. And finally, I'd personally like Message Receipts being included in more clients. They make a huge difference when you are on a bad network (e.g., most mobile networks outside of central city areas across the world). That implies we may want XEP-0198 as well. We've been play-testing that on mobile networks whilst on trains, and so on, and it's very effective. 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
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On 12 July 2011 07:03, Dave Cridland d...@cridland.net wrote: On Tue Jul 12 01:26:55 2011, Waqas Hussain wrote: Why is BOSH included in the list when we say * Support can be enabled via an external component or an internal server module/plugin.? Any XMPP compliant server would pass that, so there's no point in making this an explicit item. Bear in mind that these are marketing and/or procurement terms, primarily. So if you went up to a consultant and said We need an Advanced Server 2012, they would need to give you an XMPP solution that supported BOSH, whether or not they'd gone out and installed PunJab. RFC 6122 is missing. I'm assuming the XSF is using the compliance XEPs as a tool to encourage implementation. If that is correct, then: There's a case to be made for caps support for Advanced Server, as some servers do flood users with PEP without taking caps into account. Agreed - XEP-0115 is a requirement for PEP. There are also server cases, too. What is the case for Chat State Notifications for Advanced Client? I mean it's useful, just like a hundred other XEPs, but is it useful enough to be made into a compliance requirement? I'm ambivalent about this. I do appreciate it's one of those features with high user demand. Now, things which are missing, but shouldn't be: Working file transfer should be a requirement for Advanced Client. Agreed - really I think we want Jingle FT with IBB and S5B, but that also implies a need to support S5B proxying on the server. The trouble is, it's not clear we're ready with those specs. I'm not sure if audio/video support should be a compliance requirement for Advanced Client, but some would think so. I'm hoping that Jingle Voice etc become compliance bundles, so it's possible to say that MegaJabber 2.4 is Advanced Client 2012 with Jingle Voice. And finally, I'd personally like Message Receipts being included in more clients. They make a huge difference when you are on a bad network (e.g., most mobile networks outside of central city areas across the world). That implies we may want XEP-0198 as well. We've been play-testing that on mobile networks whilst on trains, and so on, and it's very effective. We definitely need more mobile clients to support it. I found it worked wonders when I was testing it similarly last year, but that was Lua on the command-line on Android [I was using it for alerts and not IM] :) Regards, Matthew
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On 7/11/11 6:26 PM, Waqas Hussain wrote: On Wed, Jul 6, 2011 at 10:26 PM, XMPP Extensions Editor edi...@xmpp.org wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: XMPP Compliance Suites 2012 Abstract: This document defines XMPP protocol compliance levels for 2012. URL: http://www.xmpp.org/extensions/inbox/compliance2012.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. Some thoughts: One caveat: that inbox item was simply copied without modification from the 2010 compliance suite (XEP-0270). We neglected to publish a compliance suite in 2011, so XEP-0270 reflects the state of the art in mid-2009. Why is BOSH included in the list when we say * Support can be enabled via an external component or an internal server module/plugin.? Any XMPP compliant server would pass that, so there's no point in making this an explicit item. See Dave's comments. RFC 6122 is missing. Yes, we need to add that. I'm assuming the XSF is using the compliance XEPs as a tool to encourage implementation. In part. Ideally we would use the compliance suites for testing purposes, but to do that we would need a testing program or protocol validator or something along those lines. Yet to be developed... If that is correct, then: There's a case to be made for caps support for Advanced Server, as some servers do flood users with PEP without taking caps into account. +1 (Although we have bugs to fix in XEP-0115...) What is the case for Chat State Notifications for Advanced Client? I mean it's useful, just like a hundred other XEPs, but is it useful enough to be made into a compliance requirement? I think it is. Now, things which are missing, but shouldn't be: Working file transfer should be a requirement for Advanced Client. We're pushing to finish the Jingle file transfer specs this year, but it might be too early to mandate support for them because their status is as follows: 1. XEP-0260 (Jingle SOCKS5 Bytestreams Transport Method) is currently in Last Call. Please review it and provide feedback. 2. XEP-0261 (Jingle In-Band Bytestreams Transport Method) is currently in Last Call. Please review it and provide feedback. 3. XEP-0234 (Jingle File Transfer) is still Experimental. It might need more work. I hope that the 2013 compliance suite for advanced clients can mandate XEP-0234 support. I'm not sure if audio/video support should be a compliance requirement for Advanced Client, but some would think so. In the past we talked about defining a Multimedia Client suite. Not all clients want or need to do audio/video. And finally, I'd personally like Message Receipts being included in more clients. They make a huge difference when you are on a bad network (e.g., most mobile networks outside of central city areas across the world). That's worth discussing. As Dave and Matthew noted, XEP-0198 would be very good to add to the compliance suite, too. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On Wed, Jul 6, 2011 at 10:26 PM, XMPP Extensions Editor edi...@xmpp.org wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: XMPP Compliance Suites 2012 Abstract: This document defines XMPP protocol compliance levels for 2012. URL: http://www.xmpp.org/extensions/inbox/compliance2012.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. Some thoughts: Why is BOSH included in the list when we say * Support can be enabled via an external component or an internal server module/plugin.? Any XMPP compliant server would pass that, so there's no point in making this an explicit item. RFC 6122 is missing. I'm assuming the XSF is using the compliance XEPs as a tool to encourage implementation. If that is correct, then: There's a case to be made for caps support for Advanced Server, as some servers do flood users with PEP without taking caps into account. What is the case for Chat State Notifications for Advanced Client? I mean it's useful, just like a hundred other XEPs, but is it useful enough to be made into a compliance requirement? Now, things which are missing, but shouldn't be: Working file transfer should be a requirement for Advanced Client. I'm not sure if audio/video support should be a compliance requirement for Advanced Client, but some would think so. And finally, I'd personally like Message Receipts being included in more clients. They make a huge difference when you are on a bad network (e.g., most mobile networks outside of central city areas across the world). -- Waqas Hussain
[Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
The XMPP Extensions Editor has received a proposal for a new XEP. Title: XMPP Compliance Suites 2012 Abstract: This document defines XMPP protocol compliance levels for 2012. URL: http://www.xmpp.org/extensions/inbox/compliance2012.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
