Re: For Monday's technical plenary - Review of draft-tschofenig-post-sta

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.

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf