I think this encapsulates what Dave is trying to get across: Yes, it is MUCH easier for a server developer to stuff in a little more JavaScript. Now, you have a 100% proprietary system, with no hope or desire for interoperability, that gets deployed much faster than someone taking their extension to the IETF for inclusion in, for example, IMAP. The only reason one would go for the standard solution is if they want to interoperate with other vendors. As you point out, there is absolutely no reason for anyone to participate in the standards process if they have no intention of interoperating with OTHER implementations. On Mar 28, 2011, at 1:53 PM, Hannes Tschofenig wrote: > I think the important aspect for IETF standards development is the following. IMAP and POP are protocols standardized a while ago already. They exist and that's fine. > Imagine that you are a protocol designer that wants to develop a new feature for an email client. As an example, you want to define a new extension that makes certain email functions more efficient or so. > > You now have various options: You can write a new specification (like we did in the past) or you could add a piece of HTML/JavaScript code to your deployment and make use of it. It will immediately be available to your customers that use email through a browser. > > Which approach is the right one to do? Well. It depends on a number of factors. > > The authors view is that the increased importance of the Web deployment will lead many developers to consider the second option rather than to go for the former.
<<attachment: smime.p7s>>
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf