Re: [jdev] Jabber Certification Program
On Sun, 4 Jul 2004 22:14, Mikael Hallendal wrote: > Being the author of a jabber client (Gossip) targeting this audience my > biggest concerns are the lack of "standard" on how a server is > configured. You can never count on for example group chat to be > available on the server the user happens to use. You can't count on > transports being available, search functionality being configured etc. > > While I like the generic nature of Jabber since it makes it really great > for a large number of uses it also makes it harder to use. > > So my point is that I think it would make more sense to have a > certification program for public servers rather then clients. Most users > stick with the client they are first shown (be it from a distribution, > or something a friend installed). What makes MSN, ICQ etc so easy to use > is that you don't have to chose a server, you just register an account > and connect. For jabber to have a chance against these services for > those users we need some way of doing that aswell. Couldn't client authors who wish their clients to have this kind of functionality run their own servers for it? (I guess the other option would be for a server to offer its own branded client, which connects only to that server.) I don't like the idea of one of my future servers being marked "bad" just because one day I decide that the server doesn't need MUC on it, or that I don't want to run buggy transports. TX -- 'Every sufficiently advanced technology is indistinguishable from magic' - Arthur C Clarke 'Every sufficiently advanced magic is indistinguishable from technology' - Tom Graves Email: Trejkaz Xaoza <[EMAIL PROTECTED]> Web site: http://xaoza.net/trejkaz/ Jabber ID: [EMAIL PROTECTED] GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F A62C B8C7 BC8B 037E EA73 ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
On tor, 2004-06-17 at 16:48 -0400, Rachel Blackman wrote: Hi, While I agree that Jabber is a bit too technical for the avarage end user (like current MSN/ICQ/IChat users) I don't agree that the problem is on the client side (which I kinda got the feeling that you where targeting with this proposal). Being the author of a jabber client (Gossip) targeting this audience my biggest concerns are the lack of "standard" on how a server is configured. You can never count on for example group chat to be available on the server the user happens to use. You can't count on transports being available, search functionality being configured etc. While I like the generic nature of Jabber since it makes it really great for a large number of uses it also makes it harder to use. So my point is that I think it would make more sense to have a certification program for public servers rather then clients. Most users stick with the client they are first shown (be it from a distribution, or something a friend installed). What makes MSN, ICQ etc so easy to use is that you don't have to chose a server, you just register an account and connect. For jabber to have a chance against these services for those users we need some way of doing that aswell. Best Regards, Mikael Hallendal -- Imendio HB, http://www.imendio.com/ ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
On Fri, 18 Jun 2004 08:53, Rachel Blackman wrote: > If you write it as a hobby, though, do you necessarily need the banner > on your page? To put it another way, not every webpage author is going > to strive for absolute W3C HTML4 compliance, but if you achieve it and > get it verified by one of those test programs, you can put the button > up for bragging rights. As a result, there are web authors out there > who feel driven to achieve that. Does it mean that a W3C compliance > badge or similar associated programs have a negative impact on the rest > of the world? This supports my view of the world. HTML4 is a finalised specification. XHTML-IM is an experimental specification (not even in draft.) Having certification for finalised parts of the specification would probably be a good idea, and then I think it would be fine to go through some sort of logo testing (as long as it didn't cost money, of course...) but requiring people to be certified for a feature which isn't even in draft like XHTML-IM would be tantamount to putting bragging stickers on your web site saying your site is valid XHTML 2.0 (which is actually in draft though, unlike XHTML-IM.) TX -- 'Every sufficiently advanced technology is indistinguishable from magic' - Arthur C Clarke 'Every sufficiently advanced magic is indistinguishable from technology' - Tom Graves Email: Trejkaz Xaoza <[EMAIL PROTECTED]> Web site: http://xaoza.net/trejkaz/ Jabber ID: [EMAIL PROTECTED] GPG Fingerprint: 26CF 8621 223F 3916 8872 65C5 9A27 F3C0 130F C71A ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
This point is absolutly valid. Though there still seems to be confusion on what excactly is proposed. Eg. certification on features vs. profiles (your reply to Matthew Millar seems to conflict with the earlier idea of profiles such as "minimal, intermidiate, extended). How deep would certification go, etc. Okay. Clearly, I've described this all badly; I think the flaws are in my own communication rather than the core concept, based on the fact that those who I've run this by in IM rather than on-list seem to understand where I am coming from, based on our conversations, and does not see (nor do I) the sort of conflicts you take issue at. But every time I try to address one of the points in these mails, I'm clearly not conveying this idea in a way that makes sense to certain others, or else there would not be so much fuss about it. I had thought the proposal would be good to toss out there, to consider whether or not the process should be something done by the JSF -- lending it an official stamp of approval, and giving it the weight of having a certification mean something in terms of being on the official client list -- but instead it's turned into a debate about whether or not experimental JEPs should be implemented, about how it's bad to 'force' authors to implement various features, and so on. I'm buried in code right now anyway, and can't devote the brainpower needed to trying to get past my evident shortcoming in effectively communicating this proposal. So I'm going to back off and leave this be until I can figure out a way of phrasing it which will not cause misunderstanding or massive philosophical and political disputes. It's obvious there's a vocal portion of the populace who consider it too fundamentally flawed; I feel these perceived flaws are due to misunderstanding rather than a flaw in the concept, thus I'm obviously not communicating the concept properly in some way. Given this, the discussion can go on until we're blue in the faces, and I think I'm failing to communicate well enough to resolve the fundamental misunderstanding. I'll resubmit when I have a clear charter written up as a proposal, rather than just an informal one. Consider the proposal retracted for now, at least as far as I'm concerned. I apologize for the miscommunication! --Rachel PGP.sig Description: This is a digitally signed message part ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
On Fri, 18 Jun 2004 13:33:20 -0400, Rachel Blackman <[EMAIL PROTECTED]> wrote: The thing is, there are all these very cool Jabber featuresets out there, but lots of them are not necessarily supported. Nor (other than peer pressure) is there much incentive for people to implement certain things. I can look at Jabber and go 'wow, pubsub is a cool backend system, Stream Initiation will let me do a lot of really cool things down the line' and be excited, but your average IM user (for instance, my mother or father) will look at Jabber and go 'why can't I set a nice little picture like under MSN? And why can't I use bold in my messages?' and so on. To me *that* sounds like you're saying: there are all kinds of cool specifications out there, but noone is using them. I think I phrased this badly, so I'll try again in a moment to summarize my intent in this proposal. However, I would submit that you are getting rather sidetracked by making this a debate over motives rather than benefits or drawbacks to this; regardless of /my/ intent in putting this proposal out there, surely you have your own opinions on what benefits or drawbacks this proposal has? That was in large part what I was interested in hearing from others. ;) Isn't the motive behind setting up a profiles specification or certification program important? The worries I stated is that good ideas (certification and client profiles) can go bad if it drifts towards setting up a system that is simulair of entangled with the JEP process. Your text below confirms this in part. Okay. Trying to summarize my intent again. Right now, there are lots of features out there. To use XHTML as an example (or file transfer in the older days), because of the fact there is an attitude (rightly or wrongly) that implementation of experimental JEPs should be discouraged, sometimes we see custom extensions to clients as interim solutions. (Witness various client-specific mutant HTML-marked-up message implementations.) These (file transfer, XHTML) are in fact based on semi-standards from *before* the JEP process (simulair to iq:search, iq:agents, etc.) I don't think you should compare those with anything that's in or comes out of the current JEP process! Avatars is a better example, this was actually one of the first JEPs. As far as I know implementations are compatible. They're just not implemented in every client that would be intrested in this because the way it's done is rejected by many client authors and the council. So let's take this example and bring it to the certification proposal. What should we have done with avatars? Should it have been put in the certification when the spec was designed? Or when it was first implemented? Should it ever have gone from "recommended" to "required" even though it never made DRAFT if many clients picked up on it (No, right?)? Now the JEP is RETRACTED, but there's still no alternative. Should you still recommend a RETRACTED JEP (from the JEP: " This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.")?? If not, then wouldn't it have been strange to "recommend" a JEP for a feature for 3 years, and then have the whole feature itself removed as either recommendation or requirment? How will that help users? The minute you start hand picking features while they're still in the middle of "emerging" through the JEP proces you're creating a parallel and incompatible structure. A certification program would: 1) Encourage standardization and interoperability, as anything 'certified' would be pretty much guaranteed to interoperate probably with the other certifications. This point is absolutly valid. Though there still seems to be confusion on what excactly is proposed. Eg. certification on features vs. profiles (your reply to Matthew Millar seems to conflict with the earlier idea of profiles such as "minimal, intermidiate, extended). How deep would certification go, etc. 2) Indicate (through 'recommended' features in each year's certification definition) features which are not yet required for certification but which will likely be required in the following year. (Including experimental JEPs.) However this point simply interferes with the JEP process, the "emerging" of features through the JEP process. Take the example of avatars. 3) 1 and 2 together; instead of spending effort making an 'interim solution' specific to your client while there is no clear non-experimental solution, all the client authors striving for certification and interested in a feature would thus have an incentive to concentrate their efforts on making a standard. The JEP process is supposed to be driven not only by the Council but by the community, and this would drive community action. Let's say someone wants a webcam solution in their client, but the only webcam JEP is Experimental and unfinished, not in a state where it can yet be
RE: [jdev] Jabber Certification Program
Well if it is an issue then I think we can realistically say that it would be resolved by sending the maintainer of the feature list a note. The list maintainer should be king (or queen) and decide if the feature should be taken off the clients supported feature list. I think we need a lightweight process as a first step. The compliance issue has been discussed for as long as I can remember (years?). I sincerely doubt anyone is going to create a full fledged compliance infrastructure and maintain it any time soon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Mullins Sent: Friday, June 18, 2004 3:03 PM To: Jabber software development list Subject: RE: [jdev] Jabber Certification Program Stephen Pendleton Wrote: > The client author(s) would need to submit this information. I don't > think mispresentation by the client authors would be an issue. I believe that misrepresentation would be an issue. This could probably be dealt with via policies - if a client is misrepresenting an issue, there should be a pretty clear process for getting it resolved. Unfortunately, this process must assume that the entity in question is actively attempting to misrepresent themselves. -- Chris Mullins ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
RE: [jdev] Jabber Certification Program
Stephen Pendleton Wrote: > The client author(s) would need to submit this information. I > don't think mispresentation by the client authors would be an > issue. I believe that misrepresentation would be an issue. This could probably be dealt with via policies - if a client is misrepresenting an issue, there should be a pretty clear process for getting it resolved. Unfortunately, this process must assume that the entity in question is actively attempting to misrepresent themselves. -- Chris Mullins ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
RE: [jdev] Jabber Certification Program
I don't think you need an entire certification process for this. We could simply rearrange the client list to indicate which clients support which features. The client author(s) would need to submit this information. I don't think mispresentation by the client authors would be an issue. Even this level of work requires considerable effort to organize. This would be a good first step I think. > How could certification help? If we had certification, it would be a > certainty that a list of certified clients would be available. A user > could obtain the list of clients "certified for file transfer", and > know that their chances of success are vastly greater than if they > just started downloading clients. ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
RE: [jdev] Jabber Certification Program
Hey all, I 100% agree that a certification process would help drive adoption of JEP's. The long JEP list is simply way too daunting for new client authors at the moment, and knowing which JEP's are "blessed" by the community would help those authors greatly, and would encourage them to do the extra work of supporting more than basic XMPP. I think a big part of this debate has boiled down to semantics. It's pretty easy to agree that it would be useful for client authors to know which experimental JEP's will likely soon be required for certification (after those JEP's are no longer experimental). What to actually label those JEP's is another question. They could be "recommended", or "upcoming", or some other label -- basically it should just tell people that they should start working on supporting a set of experimental JEP's so that: 1) They can be ready for when they are required during ceritification. 2) They can provide practical feedback on the JEP and help move it from experimental to certified. The label debate shouldn't distract from the larger issue, though, which is that it would be great to have a certification process in place. Regards, Matt > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rachel Blackman > Sent: Friday, June 18, 2004 10:33 AM > To: Jabber software development list > Subject: Re: [jdev] Jabber Certification Program > > >> The thing is, there are all these very cool Jabber featuresets out > >> there, but lots of them are not necessarily supported. Nor (other > >> than peer pressure) is there much incentive for people to > implement > >> certain things. I can look at Jabber and go 'wow, pubsub > is a cool > >> backend system, Stream Initiation will let me do a lot of > really cool > >> things down the line' and be excited, but your average IM > user (for > >> instance, my mother or father) will look at Jabber and go > 'why can't > >> I set a nice little picture like under MSN? And why can't > I use bold > >> in my messages?' and so on. > > > > To me *that* sounds like you're saying: there are all kinds of cool > > specifications out there, but noone is using them. > > I think I phrased this badly, so I'll try again in a moment > to summarize my intent in this proposal. However, I would > submit that you are getting rather sidetracked by making this > a debate over motives rather than benefits or drawbacks to > this; regardless of /my/ intent in putting this proposal out > there, surely you have your own opinions on what benefits or > drawbacks this proposal has? That was in large part what I > was interested in hearing from others. ;) > > Okay. Trying to summarize my intent again. > > Right now, there are lots of features out there. To use > XHTML as an example (or file transfer in the older days), > because of the fact there is an attitude (rightly or wrongly) > that implementation of experimental JEPs should be > discouraged, sometimes we see custom extensions to clients as > interim solutions. (Witness various client-specific mutant > HTML-marked-up message implementations.) > > A certification program would: > > 1) Encourage standardization and interoperability, as > anything 'certified' would be pretty much guaranteed to > interoperate probably with the other certifications. > > 2) Indicate (through 'recommended' features in each year's > certification definition) features which are not yet required > for certification but which will likely be required in the > following year. > (Including experimental JEPs.) > > 3) 1 and 2 together; instead of spending effort making an > 'interim solution' specific to your client while there is no > clear non-experimental solution, all the client authors > striving for certification and interested in a feature would > thus have an incentive to concentrate their efforts on making > a standard. The JEP process is supposed to be driven not > only by the Council but by the community, and this would > drive community action. Let's say someone wants a webcam > solution in their client, but the only webcam JEP is > Experimental and unfinished, not in a state where it can yet > be implemented; if that webcam JEP is on the 'recommend' list > for certification, then instead of going 'well, that JEP will > not be Draft for a long time so I will just make my own > client-specific solution for now,' the developer has an > incentive to really push the JEP process forward, flesh out > th
Re: [jdev] Jabber Certification Program
Ms. Blackman is not advocating certification for its own sake. The piece that I think was left unsaid was that there's all these cool specs for features, and users have a real desire to have those features, yet client haven't implemented them. As a case in point, I refer to a fairly-recent thread in this very list on a "deficiency of the protocol"[1] for file transer. The findings: not every client tested implemented file transfer according to spec. Yet the file transfer specs have been available for nearly a year. How could certification help? If we had certification, it would be a certainty that a list of certified clients would be available. A user could obtain the list of clients "certified for file transfer", and know that their chances of success are vastly greater than if they just started downloading clients. Yes! Thank you for saying what I've been trying to say, in a much more concise and straightforward manner than I was. :) --Rachel PGP.sig Description: This is a digitally signed message part ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
The thing is, there are all these very cool Jabber featuresets out there, but lots of them are not necessarily supported. Nor (other than peer pressure) is there much incentive for people to implement certain things. I can look at Jabber and go 'wow, pubsub is a cool backend system, Stream Initiation will let me do a lot of really cool things down the line' and be excited, but your average IM user (for instance, my mother or father) will look at Jabber and go 'why can't I set a nice little picture like under MSN? And why can't I use bold in my messages?' and so on. To me *that* sounds like you're saying: there are all kinds of cool specifications out there, but noone is using them. I think I phrased this badly, so I'll try again in a moment to summarize my intent in this proposal. However, I would submit that you are getting rather sidetracked by making this a debate over motives rather than benefits or drawbacks to this; regardless of /my/ intent in putting this proposal out there, surely you have your own opinions on what benefits or drawbacks this proposal has? That was in large part what I was interested in hearing from others. ;) Okay. Trying to summarize my intent again. Right now, there are lots of features out there. To use XHTML as an example (or file transfer in the older days), because of the fact there is an attitude (rightly or wrongly) that implementation of experimental JEPs should be discouraged, sometimes we see custom extensions to clients as interim solutions. (Witness various client-specific mutant HTML-marked-up message implementations.) A certification program would: 1) Encourage standardization and interoperability, as anything 'certified' would be pretty much guaranteed to interoperate probably with the other certifications. 2) Indicate (through 'recommended' features in each year's certification definition) features which are not yet required for certification but which will likely be required in the following year. (Including experimental JEPs.) 3) 1 and 2 together; instead of spending effort making an 'interim solution' specific to your client while there is no clear non-experimental solution, all the client authors striving for certification and interested in a feature would thus have an incentive to concentrate their efforts on making a standard. The JEP process is supposed to be driven not only by the Council but by the community, and this would drive community action. Let's say someone wants a webcam solution in their client, but the only webcam JEP is Experimental and unfinished, not in a state where it can yet be implemented; if that webcam JEP is on the 'recommend' list for certification, then instead of going 'well, that JEP will not be Draft for a long time so I will just make my own client-specific solution for now,' the developer has an incentive to really push the JEP process forward, flesh out the JEP and so on. Someone wanting certification is not required to implement the webcam JEP or participate in moving it forward, but might want to watch it if it is a potential for, say, the next year's 'Jabber Media Client' certification or whatever. (This is not to say I think webcams will ever be a requirement on any certification, but I needed an example to pull from thin air.) If we had this certification proces I don't think the number of clients who would have implemented those obsolete ways would be that much greater either. The very reason those ways are declared obsolete is cause a large part of the developers do not agree with the methods used. Nor would we have more clients who adopted the new ways (because these are limited by others factors, the JEPs are still new, server infrastructure is still missing (eg. IBB)), nor would it have sped up the creation of new JEPs (having an installed base of the old-now-obsolete experimental JEP that is also "certified" won't do much good there!). To uses your example, let's say that the old avatar specification was 'certified' one year, and then it's found to be bad, and it's replaced. Now you put the new avatar specification into the certification; those who want to keep their 'certified' status implement this. Those who do not implement it do not get certification again. I would say the problem is twofold. First, there is not a direct incentive to work on pushing JEPs forward -- implementing them, experimenting, finding their flaws and strengths and thus revising them so they mature -- and in fact (as has been seen in this thread), there are developers who actively /discourage/ people from implementing Experimental status JEPs, meaning they sit and languish. Secondly, there is no direct incentive to update to more current JEPs (save for interoperability) when ones go away. With existing clients doing the old-style deferred avatar method, I will bet you that many will not consider it a priority to move to the newer avatar specification when
Re: [jdev] Jabber Certification Program
Ms. Blackman is not advocating certification for its own sake. The piece that I think was left unsaid was that there's all these cool specs for features, and users have a real desire to have those features, yet client haven't implemented them. As a case in point, I refer to a fairly-recent thread in this very list on a "deficiency of the protocol"[1] for file transer. The findings: not every client tested implemented file transfer according to spec. Yet the file transfer specs have been available for nearly a year. How could certification help? If we had certification, it would be a certainty that a list of certified clients would be available. A user could obtain the list of clients "certified for file transfer", and know that their chances of success are vastly greater than if they just started downloading clients. - LW [1] http://www.jabber.org/pipermail/jdev/2004-June/018627.html Tijl Houtbeckers wrote: On Thu, 17 Jun 2004 20:04:27 -0400, Rachel Blackman <[EMAIL PROTECTED]> wrote: I shouldn't really define certification as something you 'lose'; it'd be something you have to strive to /gain/ each year. Ofcourse that sounds fair enough! Let me quote you on what started this thread: The thing is, there are all these very cool Jabber featuresets out there, but lots of them are not necessarily supported. Nor (other than peer pressure) is there much incentive for people to implement certain things. I can look at Jabber and go 'wow, pubsub is a cool backend system, Stream Initiation will let me do a lot of really cool things down the line' and be excited, but your average IM user (for instance, my mother or father) will look at Jabber and go 'why can't I set a nice little picture like under MSN? And why can't I use bold in my messages?' and so on. To me *that* sounds like you're saying: there are all kinds of cool specifications out there, but noone is using them. My question is: how do you think certification will help with that? We all know some of those specs you mention will one day be a final standard, but some others will probably go from experimental to dereffered and some will change heavily before becoming draft and final. Do you predict that client authors will wait till there the certification guidelines are known, and then implement these JEPs? Or do you think they will start implementing JEPs in the hope they will be part of the certification? Or another possibility I am missing? However *this* has a different sound to it; If you don't want to make changes to your client, that's fine. You don't suffer anything, you just don't get a new little badge with a new year on it, and you don't get in the next year's list of certified clients. Meanwhile, someone who wants to use Jabber and goes to the list of certified clients knows that the features on one client that are part of the certification (such as, say, file transfer) /will/ work with the other certified clients on the list. So if I'm on Windows, and I have a friend on MacOS X, I can point them at a MacOS X Jabber client on the certified list, pick a Windows client myself, and know that the file transfer between them will work because both are certified. To me this sounds like: if we have a certification for clients it will help our end user pick clients that work together. And who would not agree with that? Perhaps you think that having a framework for compatibility will also increase the rate of adoption for features. You could be right, which would validate the piece of text I quoted from the beginning of the thread. I don't *think* it will matter a great deal, but I admit I'd be lieing if I said I am sure you are wrong on that. If your driving force is compatibility though, you should really focus on *that*. After all, if you fail on that all of the attractions it brings along to users and developers (including the potential speed up in feature adoption) will fade away with it. Is it still a good idea then to bring experimental JEPs into this process? You were right on the mark opening this thread that what matters to users is not JEPs but features. However the process through which these features evolve often involves not on but many JEPs and JEP revisions steered by a whole bunch of different factors; technical reviews, the energy put into them by their respective authors, compromises, politics, etc. To "certify" something when it's in the middle of that process..? I don't think you should expect (or encourage!) widespread "certified" implementation and usage before that process has ended, and the feature has "emerged", accompanied by fairly stable JEPs (which usually means there's some form of implementation ready too). Maybe this is at the core of your worries; the process for those features to emerge through the JEP process can be agonizingly slow. And having certifications can speed this up! All this really acc
Re: [jdev] Jabber Certification Program
On Thu, 17 Jun 2004 20:04:27 -0400, Rachel Blackman <[EMAIL PROTECTED]> wrote: I shouldn't really define certification as something you 'lose'; it'd be something you have to strive to /gain/ each year. Ofcourse that sounds fair enough! Let me quote you on what started this thread: The thing is, there are all these very cool Jabber featuresets out there, but lots of them are not necessarily supported. Nor (other than peer pressure) is there much incentive for people to implement certain things. I can look at Jabber and go 'wow, pubsub is a cool backend system, Stream Initiation will let me do a lot of really cool things down the line' and be excited, but your average IM user (for instance, my mother or father) will look at Jabber and go 'why can't I set a nice little picture like under MSN? And why can't I use bold in my messages?' and so on. To me *that* sounds like you're saying: there are all kinds of cool specifications out there, but noone is using them. My question is: how do you think certification will help with that? We all know some of those specs you mention will one day be a final standard, but some others will probably go from experimental to dereffered and some will change heavily before becoming draft and final. Do you predict that client authors will wait till there the certification guidelines are known, and then implement these JEPs? Or do you think they will start implementing JEPs in the hope they will be part of the certification? Or another possibility I am missing? However *this* has a different sound to it; If you don't want to make changes to your client, that's fine. You don't suffer anything, you just don't get a new little badge with a new year on it, and you don't get in the next year's list of certified clients. Meanwhile, someone who wants to use Jabber and goes to the list of certified clients knows that the features on one client that are part of the certification (such as, say, file transfer) /will/ work with the other certified clients on the list. So if I'm on Windows, and I have a friend on MacOS X, I can point them at a MacOS X Jabber client on the certified list, pick a Windows client myself, and know that the file transfer between them will work because both are certified. To me this sounds like: if we have a certification for clients it will help our end user pick clients that work together. And who would not agree with that? Perhaps you think that having a framework for compatibility will also increase the rate of adoption for features. You could be right, which would validate the piece of text I quoted from the beginning of the thread. I don't *think* it will matter a great deal, but I admit I'd be lieing if I said I am sure you are wrong on that. If your driving force is compatibility though, you should really focus on *that*. After all, if you fail on that all of the attractions it brings along to users and developers (including the potential speed up in feature adoption) will fade away with it. Is it still a good idea then to bring experimental JEPs into this process? You were right on the mark opening this thread that what matters to users is not JEPs but features. However the process through which these features evolve often involves not on but many JEPs and JEP revisions steered by a whole bunch of different factors; technical reviews, the energy put into them by their respective authors, compromises, politics, etc. To "certify" something when it's in the middle of that process..? I don't think you should expect (or encourage!) widespread "certified" implementation and usage before that process has ended, and the feature has "emerged", accompanied by fairly stable JEPs (which usually means there's some form of implementation ready too). Maybe this is at the core of your worries; the process for those features to emerge through the JEP process can be agonizingly slow. And having certifications can speed this up! All this really accomplishes is that we have a simular process parralell to the JEP proces. We'd have "certified" clients using avatars, we'd have certified clients publishing their music info and with filetransfers. Because yes, those clients excist today, for example avatars can be found in quite a few (they just don't have the certified sticker)! They just do this in ways we've declared to obsolete (in this case through presence instead of pubsub, through HTTP or DTCP instead of Bytestreams, etc.). If we had this certification proces I don't think the number of clients who would have implemented those obsolete ways would be that much greater either. The very reason those ways are declared obsolete is cause a large part of the developers do not agree with the methods used. Nor would we have more clients who adopted the new ways (because these are limited by others factors, the JEPs are still new, server infrastructure is
RE: [jdev] Jabber Certification Program
I believe that the reason that client developers do not implement these particular JEP's is because there may be no demand for them at this time in their XMPP applications, not just because they are marked as 'experimental'. There are JEP's that have some value to me (pubsub, sasl, geoloc, CAP, JEP-0076), but others that I have no interest in currently (XHTML, client webtabs). This doesn't mean that those JEP's are worthless, but there may not be immediate value to implementing them in the near future. Other applications may find that these JEP's are critical. I suggest as a first step we setup the client list to indicate what major features that each client supports (file transfer based on the correct JEP (bytestream?), MUC, etc). This should ensure that if a user grabs a client that claims to support file transfer, they can be reasonably assured that it will work with other clients that support that feature. I believe that stpeter was looking into doing this at some point. I think a certification program is a lot of work and can be considered later on if the client list reorganization doesn't solve the interoperability problems. --- I think part of the point of all this -- at least over in the jdev chatroom, and in off-channel discussions -- is that the 'oh, experimental, bad don't touch it, it will bring plague upon your project ugh' mindset is itself a bad thing and that maybe that language is a little too strong and too discouraging. It might be better to have something like: ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
On Jun 18, 2004, at 5:21 AM, Justin Karneges wrote: I may have had a cynical tone in my post, but I wasn't rehashing an argument. Standards, procedures, and policies are important. Maybe I wasn't happy with what happened back then, but if you re-read my text above you'll see that I'm actually "on your side" now. - Don't implement Experimental JEPs. - Do implement Draft JEPs. - Too bad if you implemented something that got superceded. Those were the words of the council, and these are my words now. Rachel was suggesting that the certification program might want to recommend experimental JEPs, and I'm just trying to explain that this is a bad idea. I can't imagine the JSF have a certification program involving experimental JEPs, when you consider the nice red warning text that is currently at the top of all of them. Left hand, meet right hand? "my side" does not state don't implement experimental JEPs. It advocates being responsible if you choose to do so, but implementing should be a fundamental part of the JEP development process, as I stated in the email, and we'll get to again in a sec. Perhaps non draft JEPs are not fully certified, but I don't see why they couldn't be ear marked into a certain certification level. This would cause people to look at impls or start them, and then clean up the JEP more quickly. Once it's approved it could become an official part of the certification. Maybe times have changed, because back then you (read: council) made a big deal about not implementing Experimental JEPs. I mean it was a really big deal, like a "don't even touch it" kind of thing. But it has been awhile, so who knows anymore... but I think this led to the adding of the red warning text in the JEPs. But heck, by all means, change this policy if you want. To me, it doesn't matter, as long as we are all on the same page. However, if the new position is that implementations of Experimental JEPs are to be encouraged, then the red text probably shouldn't contain "not recommended" (which, to put things in perspective, is also in the Deferred and Retracted text). -Justin OK, I just reread all the appropriate threads to make sure my statements aren't off base. First, it wasn't a don't touch it kind of thing. It's pretty much always been, don't put it in a fully production system or something that you are unwilling to change. The red warning on the JEPs even clearly allows for impls in an "exploratory fashion". We don't need that debate again though, we just need some clear rules about how they fit into the design of a certification process, perhaps my idea above works? As to policy changing, I would say it's loosened ever so slightly, but is still the same as it was back then. --temas p.s. - Maybe I'm misreading your tone in this email, where it seems you are for the implementation of experimental JEPs on a wider scale, back then you had the "tough cookies" sentiment ;-) ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
Greetings, I would offer one thought about this "Should I implement Experimental JEPs" question that seems to be arising from the discussion about certification. The original point of the JEP was that it was an extension PROPOSAL and as such, it was assumed that whomever was making the proposal would offer some proof-of-concept. I.e. if you write a JEP, be prepared to back up your words with actions. We have, for better or worse, evolved into a society where JEPs are put forth by people who have no intention of actually implementing, they are just writing a JEP because they _think_ the extension would be cool. Perhaps the fundamental disagreement over experimental JEPs is derived from this mindset. D. ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
Rachel was suggesting that the certification program might want to recommend experimental JEPs, and I'm just trying to explain that this is a bad idea. Again, even if this has been the mindset in the past, it's not necessarily such now. I can't imagine the JSF have a certification program involving experimental JEPs, when you consider the nice red warning text that is currently at the top of all of them. Left hand, meet right hand? I think part of the point of all this -- at least over in the jdev chatroom, and in off-channel discussions -- is that the 'oh, experimental, bad don't touch it, it will bring plague upon your project ugh' mindset is itself a bad thing and that maybe that language is a little too strong and too discouraging. It might be better to have something like: "WARNING: This Standards-Track JEP is currently classified as Experimental, and may be subject to change or replacement in the future; the publication of this JEP does not imply acceptance or approval of this proposal by the Jabber Software Foundation as part of the official Jabber specification. Developers who implement this extension MUST be prepared to change or replace their implementation as the status of this JEP." Basically... no, you shouldn't implement every experimental JEP. And if you /do/ implement an experimental JEP, you should be prepared that it might still change and thus you might need to change your code; don't go in assuming that the protocol for an experimental JEP is set in stone, but don't assume it's a biohazard you must not touch, either. In certifications, an Experimental JEP would only be able to be a 'recommended' feature, not a required one, and the majority of features would ideally not be 'experimental' ones anyway, but it would be a way to encourage focus on certain JEPs. To bring this thread back a little more on topic while still focusing on your issue: a certification level would never /require/ an experimental JEP. That would be silly. But there would be some experimental JEPs which you look at and go, huh, that looks like something we would have be required for this certification level /if/ it were draft... so we'll put it into the 'recommended' feature set. Then authors who are going for that certification can also see a preview of what might well be requirements for the certification the following year; if they choose to start implementing the experimental JEP (and following any changes to it), then if or when the JEP goes to draft status (and thus potentially becomes part of the next certification set), they've already got that feature in place. I do not think this process would force client authors to adopt new methods of development. If you do not want to implement experimental JEPs, as you apparently do not, you do not have to; no one is going to force you to do so, and no certification level would require experimental JEPs. You could still get a certification without writing the experimental JEPs. Let's say XHTML-IM (which is Experimental) is a recommendation one year for one particular certification; you do not need to implement it, but you know that it is something which will likely become a requirement once it is draft. If you choose to implement it, yay, you get in ahead of the game, have the structures to support it in place, and you help explore implementation of the JEP. If you do not choose to implement it, there's no penalty. But then let's say XHTML-IM advances to Draft status. So the same certification for the next year now has XHTML-IM as a requirement. Those who did not implement the recommended experimental JEP from the previous year now have to implement it in Draft form; this is no different than your 'wait until its Draft' philosophy. But those who implemented it when it was recommended, rather than required, have XHTML already in their clients, and (presumably) have followed the JEP and accounted for any changes, so voila, they already /have/ that feature which is now a requirement. Does that help clarify? Or has this become more an issue about experimental JEPs in general rather than specifically experimental JEPs within certifications? --Rachel PGP.sig Description: This is a digitally signed message part ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
Hello, It all makes sense to me ... I think it is a great idea. Michael On Thu, 17 Jun 2004 20:04:27 -0400 Rachel Blackman <[EMAIL PROTECTED]> wrote: > >>> And Tkabber _still_ does DTCP based File Transfer instead of > >>> Bytestreams. Yay > >>> for standards. > >> > >> Then Tkabber fails its compliance and certification test. Which is > >> fine if they don't care, but they lose the little badge and get > >> bumped from the list of certified clients; the clients on the list > >> implement file transfer as per spec, and thus if you download one you > >> know it'll file transfer with any other one on the list. > >> > >> This seems more like an argument FOR certification than against. ;) > > > > Because the reward Tkabber gets for being one of the first to > > implement experimental JEPs (this is what you were aiming for right?) > > is that it doesn't get certification? > > I don't get it :) > > What good does it do them to have DTCP now? Does a user who grabs > tkabber care why it uses DTCP instead of bytestreams? All they care > about, as an end-user, is that Tkabber doesn't do file transfer with > other modern clients. It doesn't interact with them in the required > featureset, it doesn't get certification. Period. Tkabber doesn't get > punished for implementing an experimental JEP. Tkabber loses > certification because it didn't keep up-to-date with current stuff. > > Assume DTCP is something /not/ on the certification list at all, and > Tkabber chooses to implement it. That's their choice. Later, > bytestreams and /si/profile/file-transfer come out, and that /does/ > become 'recommended' under the certification. Tkabber chooses not to > implement the recommendation, and gets their certification that year > anyway because it's not a requirement. But then, the next year, file > transfer is a requirement. Tkabber still chooses not to implement it, > staying with DTCP. Now this year they don't get their certification, > because they no longer support current features of Jabber. > > I shouldn't really define certification as something you 'lose'; it'd > be something you have to strive to /gain/ each year. If you don't want > to make changes to your client, that's fine. You don't suffer > anything, you just don't get a new little badge with a new year on it, > and you don't get in the next year's list of certified clients. > Meanwhile, someone who wants to use Jabber and goes to the list of > certified clients knows that the features on one client that are part > of the certification (such as, say, file transfer) /will/ work with the > other certified clients on the list. So if I'm on Windows, and I have > a friend on MacOS X, I can point them at a MacOS X Jabber client on the > certified list, pick a Windows client myself, and know that the file > transfer between them will work because both are certified. > > I dunno, maybe I'm off on a completely wrong tangent, but it just seems > like it doesn't /harm/ the existing clients, but gives a way to > encourage the adoption of various JEPs through the 'recommended' role > -- it's not a requirement, but it gets activity on them, and a > 'recommended' feature might end up being a 'required' feature the next > year, so it'd be good to have the structure in there and be working on > it. > > Just my $0.02 again. > > --Rachel > > ___ > jdev mailing list > [EMAIL PROTECTED] > https://jabberstudio.org/mailman/listinfo/jdev > > > > -- Michael Gale Network Administrator Utilitran Corporation ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
On Thursday 17 June 2004 5:44 pm, Thomas Muldowney wrote: > The DTCP argument is old and dead. It was a matter of multiple > standards doing the same job coming out at the same time and then > people pushing and shoving to make something move to the head of the > class. That issue is over and dead, let's move past it, we're big kids > now. I may have had a cynical tone in my post, but I wasn't rehashing an argument. Standards, procedures, and policies are important. Maybe I wasn't happy with what happened back then, but if you re-read my text above you'll see that I'm actually "on your side" now. - Don't implement Experimental JEPs. - Do implement Draft JEPs. - Too bad if you implemented something that got superceded. Those were the words of the council, and these are my words now. Rachel was suggesting that the certification program might want to recommend experimental JEPs, and I'm just trying to explain that this is a bad idea. I can't imagine the JSF have a certification program involving experimental JEPs, when you consider the nice red warning text that is currently at the top of all of them. Left hand, meet right hand? > As to the council opinion, implementations are fine, but if you're > using a "real" JEP and it's experimental, than it's expected that > you'll use the current version and then whatever becomes draft. We > can't have ideas that are just written down, they need to be tested. > This is also, related to the recent council discussion about not as > quickly accepting or pushing JEPs through the process, and using the > wiki more. Maybe times have changed, because back then you (read: council) made a big deal about not implementing Experimental JEPs. I mean it was a really big deal, like a "don't even touch it" kind of thing. But it has been awhile, so who knows anymore... but I think this led to the adding of the red warning text in the JEPs. But heck, by all means, change this policy if you want. To me, it doesn't matter, as long as we are all on the same page. However, if the new position is that implementations of Experimental JEPs are to be encouraged, then the red text probably shouldn't contain "not recommended" (which, to put things in perspective, is also in the Deferred and Retracted text). > JEP-Secure has political issues and you know that. Don't make > statements that are loosely blaming other people for that hold up. My bad, this really wasn't a council issue. I was just trying to point out that sometimes it can take a long time for JEPs to advance, and during that time you just have to wait. -Justin ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
On Jun 17, 2004, at 6:04 PM, Justin Karneges wrote: On Thursday 17 June 2004 3:25 pm, Julian Missig wrote: Protocols do not move forward by sheer will of the council. The /reason/ those JEPs are /still/ experimental is because of lack of implementation attempts. Do we really want to relive the DTCP disaster again? Ever since that backlash, I'm afraid to implement anything that doesn't say Draft. JEPs do not move forward by sheer will of Council or JEP authors. Client-based JEPs need client implementations to test them and work out bugs... and then the Council can start moving things forward based on real experience. Has the Council opinion changed? If so, I wasn't aware of it. Real experience is apparently overrated. Time for everyone to go read some mail about File Transfer in late 2002. And Tkabber _still_ does DTCP based File Transfer instead of Bytestreams. Yay for standards. How many test implementations of jep-secure are there? jep-secure doesn't even have a JEP number yet, hence the name. It's still stuck in the council/jep-editor void (for 3 months now). Surely an implementation is not expected. -Justin The DTCP argument is old and dead. It was a matter of multiple standards doing the same job coming out at the same time and then people pushing and shoving to make something move to the head of the class. That issue is over and dead, let's move past it, we're big kids now. As to the council opinion, implementations are fine, but if you're using a "real" JEP and it's experimental, than it's expected that you'll use the current version and then whatever becomes draft. We can't have ideas that are just written down, they need to be tested. This is also, related to the recent council discussion about not as quickly accepting or pushing JEPs through the process, and using the wiki more. JEP-Secure has political issues and you know that. Don't make statements that are loosely blaming other people for that hold up. There's no reason not to be implementing it and figuring out what the problems are. For the JEP-84 mods there's no way I would be ready to update it if I had not started implementing it in Gabber2. I immediately found many practical problems with the described methods, and how I initially thought I could fix them. --temas ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
And Tkabber _still_ does DTCP based File Transfer instead of Bytestreams. Yay for standards. Then Tkabber fails its compliance and certification test. Which is fine if they don't care, but they lose the little badge and get bumped from the list of certified clients; the clients on the list implement file transfer as per spec, and thus if you download one you know it'll file transfer with any other one on the list. This seems more like an argument FOR certification than against. ;) Because the reward Tkabber gets for being one of the first to implement experimental JEPs (this is what you were aiming for right?) is that it doesn't get certification? I don't get it :) What good does it do them to have DTCP now? Does a user who grabs tkabber care why it uses DTCP instead of bytestreams? All they care about, as an end-user, is that Tkabber doesn't do file transfer with other modern clients. It doesn't interact with them in the required featureset, it doesn't get certification. Period. Tkabber doesn't get punished for implementing an experimental JEP. Tkabber loses certification because it didn't keep up-to-date with current stuff. Assume DTCP is something /not/ on the certification list at all, and Tkabber chooses to implement it. That's their choice. Later, bytestreams and /si/profile/file-transfer come out, and that /does/ become 'recommended' under the certification. Tkabber chooses not to implement the recommendation, and gets their certification that year anyway because it's not a requirement. But then, the next year, file transfer is a requirement. Tkabber still chooses not to implement it, staying with DTCP. Now this year they don't get their certification, because they no longer support current features of Jabber. I shouldn't really define certification as something you 'lose'; it'd be something you have to strive to /gain/ each year. If you don't want to make changes to your client, that's fine. You don't suffer anything, you just don't get a new little badge with a new year on it, and you don't get in the next year's list of certified clients. Meanwhile, someone who wants to use Jabber and goes to the list of certified clients knows that the features on one client that are part of the certification (such as, say, file transfer) /will/ work with the other certified clients on the list. So if I'm on Windows, and I have a friend on MacOS X, I can point them at a MacOS X Jabber client on the certified list, pick a Windows client myself, and know that the file transfer between them will work because both are certified. I dunno, maybe I'm off on a completely wrong tangent, but it just seems like it doesn't /harm/ the existing clients, but gives a way to encourage the adoption of various JEPs through the 'recommended' role -- it's not a requirement, but it gets activity on them, and a 'recommended' feature might end up being a 'required' feature the next year, so it'd be good to have the structure in there and be working on it. Just my $0.02 again. --Rachel ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
On Thu, 17 Jun 2004 19:16:07 -0400, Rachel Blackman <[EMAIL PROTECTED]> wrote: And Tkabber _still_ does DTCP based File Transfer instead of Bytestreams. Yay for standards. Then Tkabber fails its compliance and certification test. Which is fine if they don't care, but they lose the little badge and get bumped from the list of certified clients; the clients on the list implement file transfer as per spec, and thus if you download one you know it'll file transfer with any other one on the list. This seems more like an argument FOR certification than against. ;) Because the reward Tkabber gets for being one of the first to implement experimental JEPs (this is what you were aiming for right?) is that it doesn't get certification? I don't get it :) Sounds more to me like you should wait till JEPs go DRAFT before implementing, else you won't get certification. ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
JEPs do not move forward by sheer will of Council or JEP authors. Client-based JEPs need client implementations to test them and work out bugs... and then the Council can start moving things forward based on real experience. Has the Council opinion changed? If so, I wasn't aware of it. Real experience is apparently overrated. Time for everyone to go read some mail about File Transfer in late 2002. And Tkabber _still_ does DTCP based File Transfer instead of Bytestreams. Yay for standards. Then Tkabber fails its compliance and certification test. Which is fine if they don't care, but they lose the little badge and get bumped from the list of certified clients; the clients on the list implement file transfer as per spec, and thus if you download one you know it'll file transfer with any other one on the list. This seems more like an argument FOR certification than against. ;) ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
On Thursday 17 June 2004 3:25 pm, Julian Missig wrote: > Protocols do not move forward by sheer will of the council. The > /reason/ those JEPs are /still/ experimental is because of lack of > implementation attempts. Do we really want to relive the DTCP disaster again? Ever since that backlash, I'm afraid to implement anything that doesn't say Draft. > JEPs do not move forward by sheer will of Council or JEP authors. > Client-based JEPs need client implementations to test them and work out > bugs... and then the Council can start moving things forward based on > real experience. Has the Council opinion changed? If so, I wasn't aware of it. Real experience is apparently overrated. Time for everyone to go read some mail about File Transfer in late 2002. And Tkabber _still_ does DTCP based File Transfer instead of Bytestreams. Yay for standards. > How many test implementations of jep-secure are there? jep-secure doesn't even have a JEP number yet, hence the name. It's still stuck in the council/jep-editor void (for 3 months now). Surely an implementation is not expected. -Justin ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
Clients are "behind" because nearly all of them are hobby projects. I think I can speak for most of us in saying that we are working as fast as we can within our available time, and throwing a certification weight on our shoulders wouldn't speed anything up. If you write it as a hobby, though, do you necessarily need the banner on your page? To put it another way, not every webpage author is going to strive for absolute W3C HTML4 compliance, but if you achieve it and get it verified by one of those test programs, you can put the button up for bragging rights. As a result, there are web authors out there who feel driven to achieve that. Does it mean that a W3C compliance badge or similar associated programs have a negative impact on the rest of the world? In addition, many of the features you mention just plain aren't ready in specification form. Avatars? XHTML-IM? Voice chat? These are all Experimental. Maybe we should start certifying Jabber Council members, to motivate them to approve some JEPs? (and speaking of which, my "jep-secure" has beat the record of the longest time from submission to publication, and is still counting.) This is a frustration I can understand, completely. However, keep in mind that JEPs tend to move forward out of 'experimental' faster when people are actually working on using them. XHTML has languished, in part, because few clients have added it. Worse still, it seems as though there is a stigma of some kind involved in implementing experimental JEPs. Your own comment demonstrates this; you speak of the Experimental status as reason not to implement them yet. I think this hurts Jabber as a whole. Experimental JEPs /need/ to be implemented, so they can be tried out in the real world; real world user experience (benefits /and/ horror stories) do a lot to move a JEP forward. Yes, they might change, which is irritating... but we DO have xmlns as our markers, and if for some unavoidable reason a JEP changes enough during the experimental phase that it becomes incompatible with its previous implementation, we can theoretically change the xmlns to avoid breaking lingering experimental versions. And sure, you can't make an Experimental JEP a 'required' for the certification set for one year, but you can definitely make it a 'recommended,' and encourage implementation of it. The clients who want the nifty little certification badge -- and I think you'd find they are out there -- will work to implement these things, and thus help move the JEPs forward. If we had 'avatars' as a recommended for a certification list, I bet you there'd have been at least a Draft version avatar JEP by now. ;) There's my $0.02, for whatever it's worth. --Rachel ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
On Thu, 17 Jun 2004 18:25:34 -0400, Julian Missig <[EMAIL PROTECTED]> wrote: On 17 Jun 2004, at 17:48, Justin Karneges wrote: How many test implementations of jep-secure are there? Julian I think the problem referred to is the fact that it's not even published on the site yet. Or am I mistaken? (I do hope you don't need an implementation for *that*) ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
On 17 Jun 2004, at 17:48, Justin Karneges wrote: In addition, many of the features you mention just plain aren't ready in specification form. Avatars? XHTML-IM? Voice chat? These are all Experimental. Maybe we should start certifying Jabber Council members, to motivate them to approve some JEPs? (and speaking of which, my "jep-secure" has beat the record of the longest time from submission to publication, and is still counting.) Protocols do not move forward by sheer will of the council. The /reason/ those JEPs are /still/ experimental is because of lack of implementation attempts. If we had a compliance board, and the board said "ok, we're going to try to have Avatars as part of the 2005 compliance spec", then client authors would start working on implementing avatars, and the JEP would start changing and moving forward. Obviously if the JEP is not finalized in time for the 2005 compliance tests it can only be "recommended" at best and not an actual requirement, but it will have pushed the client authors to attempt to implement a JEP, and by extension, pushed the JEP forward. JEPs do not move forward by sheer will of Council or JEP authors. Client-based JEPs need client implementations to test them and work out bugs... and then the Council can start moving things forward based on real experience. How many test implementations of jep-secure are there? Julian ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
RE: [jdev] Jabber Certification Program
I can offer some insight into one certification process: I have been through the Microsoft Mobile certification for our Smartphone and PocketPC client, and I know this process required a large infrastructure behind it. In that case, there is a third party company doing the certification which consisted of testing that the interface features of the software met Microsoft's Mobile Software guidelines. If a new version of your software is released you had to get it recertified. The benefit of "winning" certification means that the software will get exposure on Microsoft's online mobile catalog of software (very valuable exposure). The other benefit is getting to advertise the product with a "Designed for Windows Mobile" logo. You can see the similarity here between that program and the one you are proposing. One reason the Microsoft process is successful is because they had a third party company willing to build the infrastructure to provide the testing service. Of course, the third party company didn't do this for free - the fee for compliance testing was $1,400 per product version (reasonable as cert programs go). I suspect Microsoft also subsidized the process as well. I know this is going to be unpopular, but it may be wise to consider such a fee-based compliance testing process. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rachel Blackman Sent: Thursday, June 17, 2004 4:48 PM To: [EMAIL PROTECTED] Subject: [jdev] Jabber Certification Program So, Jabber has been around for a while now. It's a great architecture, we've all drunk the Kool-Aid as it were... but I've recently found a lot of frustration in one area, and I know from discussion in the jdev chatroom that I am far from the only one. The thing is, there are all these very cool Jabber featuresets out there, but lots of them are not necessarily supported. Nor (other than peer pressure) is there much incentive for people to implement certain things. I can look at Jabber and go 'wow, pubsub is a cool backend system, Stream Initiation will let me do a lot of really cool things down the line' and be excited, but your average IM user (for instance, my mother or father) will look at Jabber and go 'why can't I set a nice little picture like under MSN? And why can't I use bold in my messages?' and so on. Jabber is, architecturally, probably the most advanced IM protocol out there, and it's a godsend to developers... but to end-users, it doesn't really replace the AIM featureset or whatever. XHTML-IM has been a JEP for a rather long time, and few clients implement it (and moreover, some of them implement it in a nonstandard and wacky way!), and it's a fairly basic feature many IM end users look for. And there's no real incentive (other than peer pressure, as I said) for a client author to implement XHTML, so it ends up getting pushed further and further down TODO lists and suchnot. So there was discussion in the chatroom today about a compliance and certification program, with varying levels of certification and differing requirements for the levels. Only certified clients would be on jabber.org's client list, certified clients would get the right to use a little 'certified' banner on their websites and in their documentation or whatever, and it would ensure featuresets /do/ get implemented for end-users. I am writing up a quick proposal about how to do this. If enough folks like it (and there's not too much ensuing flamethrower usage in my direction), I will write it up in JEP format and submit it. ** PROPOSED JABBER CERTIFICATION PROGRAM ** Each certification would have a year attached to it. For instance, 'Jabber Basic Certified 2004' for a banner on a site. A certification only lasts until the end of a calendar year, and then you have to re-apply for certification; having a certification for a given year is not a guarantee you will have it next year. Certifications can have required features, and recommended features (i.e. 'MUST' and 'SHOULD'). The certification requirements for a calendar year would be set by a Jabber Certification Board, presumably appointed by the Council. The requirements for a given year would be decided on in July of the previous year, giving individuals six months to implement the features (and apply for certification ahead of time). For instance, if this program were in effect, next month the Certification Board would have to issue the certification requirements for 2005, giving all the developers time to implement the features and apply for certification before the end of 2004 (and thus the expiration of their existing certification). To be certified, you would need to get a copy of the software in question to the Board to use, and they'd run it against some kind of validation suite. Presumably they'd have a process for testing, either certain automated things they could point to or a script for hand-testing it al
Re: [jdev] Jabber Certification Program
Yes, there is definitely a problem, but I don't I agree with your solution. Clients are "behind" because nearly all of them are hobby projects. I think I can speak for most of us in saying that we are working as fast as we can within our available time, and throwing a certification weight on our shoulders wouldn't speed anything up. In addition, many of the features you mention just plain aren't ready in specification form. Avatars? XHTML-IM? Voice chat? These are all Experimental. Maybe we should start certifying Jabber Council members, to motivate them to approve some JEPs? (and speaking of which, my "jep-secure" has beat the record of the longest time from submission to publication, and is still counting.) Regarding the jabber.org client list: Yes, it is a zoo, but I think we decided awhile ago that jabber.org should always contain a complete listing, and if we wanted a smaller list (ie, just the "user oriented" software) then that listing, along with reviews, etc, would take place on an end-user site, such as "jabbercentral" (whenever it gets back...) or the theoretical "jabber.net". That said, certification is a neat idea. I'm not necessarily against it. It would allow some of us to have "bragging rights". I just don't think it will have the impact that you're shooting for. -Justin On Thursday 17 June 2004 1:48 pm, Rachel Blackman wrote: > So, Jabber has been around for a while now. It's a great architecture, > we've all drunk the Kool-Aid as it were... but I've recently found a > lot of frustration in one area, and I know from discussion in the jdev > chatroom that I am far from the only one. > > The thing is, there are all these very cool Jabber featuresets out > there, but lots of them are not necessarily supported. Nor (other than > peer pressure) is there much incentive for people to implement certain > things. I can look at Jabber and go 'wow, pubsub is a cool backend > system, Stream Initiation will let me do a lot of really cool things > down the line' and be excited, but your average IM user (for instance, > my mother or father) will look at Jabber and go 'why can't I set a nice > little picture like under MSN? And why can't I use bold in my > messages?' and so on. Jabber is, architecturally, probably the most > advanced IM protocol out there, and it's a godsend to developers... but > to end-users, it doesn't really replace the AIM featureset or whatever. > > XHTML-IM has been a JEP for a rather long time, and few clients > implement it (and moreover, some of them implement it in a nonstandard > and wacky way!), and it's a fairly basic feature many IM end users look > for. And there's no real incentive (other than peer pressure, as I > said) for a client author to implement XHTML, so it ends up getting > pushed further and further down TODO lists and suchnot. > > So there was discussion in the chatroom today about a compliance and > certification program, with varying levels of certification and > differing requirements for the levels. Only certified clients would be > on jabber.org's client list, certified clients would get the right to > use a little 'certified' banner on their websites and in their > documentation or whatever, and it would ensure featuresets /do/ get > implemented for end-users. > > I am writing up a quick proposal about how to do this. If enough folks > like it (and there's not too much ensuing flamethrower usage in my > direction), I will write it up in JEP format and submit it. > > ** PROPOSED JABBER CERTIFICATION PROGRAM ** > > Each certification would have a year attached to it. For instance, > 'Jabber Basic Certified 2004' for a banner on a site. A certification > only lasts until the end of a calendar year, and then you have to > re-apply for certification; having a certification for a given year is > not a guarantee you will have it next year. Certifications can have > required features, and recommended features (i.e. 'MUST' and 'SHOULD'). > > The certification requirements for a calendar year would be set by a > Jabber Certification Board, presumably appointed by the Council. The > requirements for a given year would be decided on in July of the > previous year, giving individuals six months to implement the features > (and apply for certification ahead of time). For instance, if this > program were in effect, next month the Certification Board would have > to issue the certification requirements for 2005, giving all the > developers time to implement the features and apply for certification > before the end of 2004 (and thus the expiration of their existing > certification). > > To be certified, you would need to get a copy of the software in > question to the Board to use, and they'd run it against some kind of > validation suite. Presumably they'd have a process for testing, either > certain automated things they could point to or a script for > hand-testing it all. You could apply for more than one certification.
Re: [jdev] Jabber Certification Program
On 17 Jun 2004, at 17:28, Rachel Blackman wrote: I think it would be a very very good idea to have *one person* be responsible for the client requirements for a particular year. A "Client Compliance Master 2005" or something... and eventually we could have a "Server Compliance Master 2006". That person has final say on what the requirements are, and has final say on whether particular things are or are not compliant. Perhaps we could vote for who this person is or make it a requirement to vote on their decisions or something, but for something as subjective as this I think it just makes more sense to have a final say, rather than leaving it all up to some kind of ambiguous discussion. Also, I think initially we should try to get this running for clients, and then expand into servers, gateways, components... The other reason I thought there should be a Board overall is that expecting one person to verify every piece of software sent in for certification would be... er, scary. Even ignoring the sheer enormity of the potential workload, there are other practical problems; for instance, what if the Client Compliance Master for a year does not have a MacOS X box, and one of the pieces of software submitted requires MacOS X to run? Hence the Board. That said, I agree there has to be one 'master' in the end, to make the final call. Perhaps the Master is appointed by the Council, and they appoint the rest of the members? Or perhaps eventually the Board could be the 'Compliance Master' for each of the categories? They'd be able to discuss among themselves and provide resources to help test the things submitted for certification, but only one person would have the responsibility for making the final call on what the certification/compliance requirements for a given category were that year. Yeah, maybe each member of the Board could be a master of a different category or something like that.. that works for me. Write it up already ;) Julian ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
I think it would be a very very good idea to have *one person* be responsible for the client requirements for a particular year. A "Client Compliance Master 2005" or something... and eventually we could have a "Server Compliance Master 2006". That person has final say on what the requirements are, and has final say on whether particular things are or are not compliant. Perhaps we could vote for who this person is or make it a requirement to vote on their decisions or something, but for something as subjective as this I think it just makes more sense to have a final say, rather than leaving it all up to some kind of ambiguous discussion. Also, I think initially we should try to get this running for clients, and then expand into servers, gateways, components... The other reason I thought there should be a Board overall is that expecting one person to verify every piece of software sent in for certification would be... er, scary. Even ignoring the sheer enormity of the potential workload, there are other practical problems; for instance, what if the Client Compliance Master for a year does not have a MacOS X box, and one of the pieces of software submitted requires MacOS X to run? Hence the Board. That said, I agree there has to be one 'master' in the end, to make the final call. Perhaps the Master is appointed by the Council, and they appoint the rest of the members? Or perhaps eventually the Board could be the 'Compliance Master' for each of the categories? They'd be able to discuss among themselves and provide resources to help test the things submitted for certification, but only one person would have the responsibility for making the final call on what the certification/compliance requirements for a given category were that year. --Rachel ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
Re: [jdev] Jabber Certification Program
I wish I had more to say... but all I can think of is: sounds good. I think it would be a very very good idea to have *one person* be responsible for the client requirements for a particular year. A "Client Compliance Master 2005" or something... and eventually we could have a "Server Compliance Master 2006". That person has final say on what the requirements are, and has final say on whether particular things are or are not compliant. Perhaps we could vote for who this person is or make it a requirement to vote on their decisions or something, but for something as subjective as this I think it just makes more sense to have a final say, rather than leaving it all up to some kind of ambiguous discussion. Also, I think initially we should try to get this running for clients, and then expand into servers, gateways, components... Julian On 17 Jun 2004, at 16:48, Rachel Blackman wrote: So, Jabber has been around for a while now. It's a great architecture, we've all drunk the Kool-Aid as it were... but I've recently found a lot of frustration in one area, and I know from discussion in the jdev chatroom that I am far from the only one. The thing is, there are all these very cool Jabber featuresets out there, but lots of them are not necessarily supported. Nor (other than peer pressure) is there much incentive for people to implement certain things. I can look at Jabber and go 'wow, pubsub is a cool backend system, Stream Initiation will let me do a lot of really cool things down the line' and be excited, but your average IM user (for instance, my mother or father) will look at Jabber and go 'why can't I set a nice little picture like under MSN? And why can't I use bold in my messages?' and so on. Jabber is, architecturally, probably the most advanced IM protocol out there, and it's a godsend to developers... but to end-users, it doesn't really replace the AIM featureset or whatever. XHTML-IM has been a JEP for a rather long time, and few clients implement it (and moreover, some of them implement it in a nonstandard and wacky way!), and it's a fairly basic feature many IM end users look for. And there's no real incentive (other than peer pressure, as I said) for a client author to implement XHTML, so it ends up getting pushed further and further down TODO lists and suchnot. So there was discussion in the chatroom today about a compliance and certification program, with varying levels of certification and differing requirements for the levels. Only certified clients would be on jabber.org's client list, certified clients would get the right to use a little 'certified' banner on their websites and in their documentation or whatever, and it would ensure featuresets /do/ get implemented for end-users. I am writing up a quick proposal about how to do this. If enough folks like it (and there's not too much ensuing flamethrower usage in my direction), I will write it up in JEP format and submit it. ** PROPOSED JABBER CERTIFICATION PROGRAM ** Each certification would have a year attached to it. For instance, 'Jabber Basic Certified 2004' for a banner on a site. A certification only lasts until the end of a calendar year, and then you have to re-apply for certification; having a certification for a given year is not a guarantee you will have it next year. Certifications can have required features, and recommended features (i.e. 'MUST' and 'SHOULD'). The certification requirements for a calendar year would be set by a Jabber Certification Board, presumably appointed by the Council. The requirements for a given year would be decided on in July of the previous year, giving individuals six months to implement the features (and apply for certification ahead of time). For instance, if this program were in effect, next month the Certification Board would have to issue the certification requirements for 2005, giving all the developers time to implement the features and apply for certification before the end of 2004 (and thus the expiration of their existing certification). To be certified, you would need to get a copy of the software in question to the Board to use, and they'd run it against some kind of validation suite. Presumably they'd have a process for testing, either certain automated things they could point to or a script for hand-testing it all. You could apply for more than one certification. A couple examples of certification types are shown below. These are NOT actual proposals, just examples of what a certification list might be. You'd actually want much longer and more detailed certification criteria, of course. Jabber Client Minimal - suitable for mobile or embedded clients - required : roster management - required : jid-to-jid chatting - recommended: groupchat-1.0 Jabber Client Intermediate - Suitable as a 'generic' client - required : all of Jabber Client Minimal - required : file transfer - required :
Re: [jdev] Jabber Certification Program
XHTML-IM has been a JEP for a rather long time, and few clients implement it (and moreover, some of them implement it in a nonstandard and wacky way!), and it's a fairly basic feature many IM end users look for. And there's no real incentive (other than peer pressure, as I said) for a client author to implement XHTML, so it ends up getting pushed further and further down TODO lists and suchnot. I got ahead of myself in editing that post, and realized this showed up a little out of context. XHTML-IM makes a great example of why a certification program could give benefits to us; if it were a requirement for one of the certification levels, then people would have to not only implement it (and thus increase the overall featureful-ness of Jabber clients), but would have to implement it in a way that was found to be standards compliant by the certification board. :) ___ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
