Hi Dave, thank you for the detailed review of the draft. For time reasons I only focus on a few minor items; a more detailed response will follow later. > > 2. Software > > The draft is predicated on a common point of confusion between software architecture and network protocol architecture. They are typically independent. > While we indeed try to keep software architecture and network protocol architecture separately my observation of the Web protocols we looked at is that this does not seem to be the case here. While theoretically one could have any form of mobile code in the current Web deployment we are not talking about a random language for mobile code but instead we are only talking about JavaScript here. So, this is not a confusion from our side but rather an observation of the widespread deployment and success of JavaScript. > > > 3. API > > There is another fundamental error in the draft: conflating an API with a protocol. (Unfortunately, discussion on the list has followed suit and suffered from this confusion.) > > They are different: An API is not a protocol, and does not dictate the details of a protocol. > > An API is merely a tailored interface at one end of the protocol and while it of course correlates with the details of the protocol, the correlation is never perfect and the protocol still needs specifying. So while an API is necessary, it is not sufficient. > > An instructive demonstration that they are quite different is the history of Netbios. (See RFC 1001/1002.) Simply put, an API can permit a variety of very different protocols with very different properties, while an API never specifies the exact details of bits over the wire. I fully agree that API in the way we use it in the IETF is not a protocol. However, it seems that other folks outside the IETF do not follow that definition and people talk, for example, about the Geolocation API: http://dev.w3.org/geo/api/spec-source.html When you look at these "APIs" you will notice that they are actually more than just a programming interface. They are actually protocols. So, there is a terminology mismatch here. > > > > 4. Mobile Agents > > Downloading JavaScript from a server to a client is a constrained example of a mobile software agent model, dating back to the 1970s, with interesting work in the 1990s being General Magic's Telescript, as well as SafeTCL. In the more general form, mobile agents travel around, interacting with each place they land, such as the calendaring programs of potential meeting attendees, to determine the best time for getting together. > By no means we claim that the idea of mobile code is a new idea. What is new is the widespread deployment. > The coarse-grained depiction of the activities discussed in this draft are: > > ........ ........ > :Client: TCP/HTTP session initiation -> :Server: > ........ ........ > [Application selection ->] > > <- Mobile agent upload > > <- Application activity -> > > Note that mobile agent upload requires its own protocol standard. > > In terms of protocol "stacks", that upload phase looks something like: > > Agent Exchange Protocol or Agent Exchange Protocol > ----------------------- ----------------------- > HTTP TCP > ----------------------- ... > TCP > ... > > > A mobile agent model creates an exciting software capability. But its use in the constrained context of downloading a client does not mandate changes to existing application protocols nor to standards processes. It also carries significant security and trust risks. Remember that there already is a common and problematic name for software that is automatically loaded and executed on a user's machine, without the user's control... > > The draft has extensive discussion about the current limitations of the JavaScript and Web client platform, as if those limitations are minor or easily remedied. They aren't. Limitations as extensive as those described in the draft, ensure a severely limited scope of use for the mobile agent model. > > There is a reason that browsers have an option to disable JavaScript. > > As you note above there are security risks with that approach as well. We are aware of these challenges (and some other limitations). We (the authors) believe that the IETF community should take a closer look at these security challenges (not only those that result from JavaScript but from the Web in general). To start the work on some of them the Websec working group was created last year in the IETF and the formation of a group in the W3C is pending. Clearly, this will not be enough. More work is needed (as I stated at the HASMAT BOF about 9 months ago) to identify the longer term story for dealing with some of the problems we expect to see in the future. We do not believe that the security challenges will be solved easily. In fact we say: " It is unavoidable to get the impression that the hard problems, particularly to security concerns regarding the distribution of new software in whatever form, have not been tackled. Instead, the browser becomes the new operating system, inherits the same weaknesses and is likely to share the same fate. " > > 5. Application Protocol > > The draft characterizes HTTP as "replacing" application protocols -- for example: > >> The need for Internet standards beyond HTTP to >> implement an email inbox application consequently diminishes... > > So the draft asserts that POP and IMAP are no longer be needed. This view is quite simply wrong. > > It misses the simple reality that an alternative environment based on HTTP still has an application protocol running at the top of the stack; for functional specificity between client and server, there must be additional conventions followed between them. > > A set of conventions between network participants is called a protocol. > > HTTP and HTML5 and Javascript do not combine to specify email conventions. If client and server are doing email interactions then there is an email protocol. > > A better "middleware" layer protocol platform might make it easier to specify the higher-level email protocol. It might even allow more streamlined email protocol details. But it does not eliminate the email protocol, since that is where the semantics reside. > > Once the mobile agent is exchanged, the client/server interactions that perform the application functions constitute the application protocol, whether over HTTP or not and the protocol stack for this phase is the same as for any other application protocol stack model: > > Mailbox Protocol or Mailbox Protocol > ---------------- ---------------- > HTTP TCP > --------------- ... > TCP > ... > > 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. > > 6. Proprietary > > The draft further confuses the use of proprietary protocols with the absence of protocols. In the above example with email, the self-contained environment that can be created by having the same team develop the server and the automatically-downloaded, Javascript, purpose-built client -- such as for doing email semantics across the wire -- is still a protocol. It is unfortunate if the draft gave the impression that these JavaScript mechanisms aren't protocols. Clearly they are, as you point out. We need to make this more clear. As you state below, in certain cases you may well implement a standardized protocol in JavaScript. This is, for example, done in case of XMPP. See, for example, http://professionalxmpp.com/ > The protocol might be a standardized protocol like IMAP or it might use a proprietary protocol, but it is still a protocol. > > Sometimes it is appropriate to consider whether to develop a new, proprietary application protocol or better to use an existing, standardized. This is a discrete, classic analysis to conduct, looking at tradeoffs. However it is independent of the software architecture used to get the client application software onto the client machine. I agree with you. This of course assumes that web developers are aware of the work we do in the IETF and how easy it is usable for the Web environment. For us in the IETF this means that our protocols have to be easy to implement with Web programming languages. To give you an example: In the OAuth work from a security point of view it would have been great to sign an entire HTTP message but many of the programming languages did not pass the raw HTTP message up to the developer. So, it wasn't really an option. > > Note that the new, proprietary protocol will suffer the same learning curve with bugs and functionality that all new protocols experience. > Definitely true. For this purpose many web developers use frameworks and libraries. We reference a couple of them in the draft, such as JQuery. > The draft also appears to erroneously believe that standardization requires starting with a standards effort at the beginning of a technical effort. Starting the standards process later into the lifecycle of a protocol often works quite well, as demonstrated by NFS, SSL/TLS, Jabber/XMPP, and DKIM. I am not sure we say that. We definitely do not believe that. > > Open systems interoperability can start with a proprietary effort, but it ultimately requires a standards effort, since open systems are predicated on sharing control and access, while proprietary systems are predicated on centralized control. > > The draft appears to see only the benefits in this reliance on proprietary protocols, without any sense of the attendant detriments. Proprietary work can indeed be performed more quickly than standardized work. It also can be tailored more. However it also is subject to less review and less interoperability. This means that it is likely to have more design flaws, more bugs and more data and usage isolation. Witness the remarkable lack of interoperability among the many proprietary instant messaging services and the continuing difficulties in collaborating with shared calendaring. We may need to describe the pros and cons more in the document. The document does not describe how we would like the world to look like but rather how it looks like and how we expect it to move forward. > > Application protocol and object standardization activities are required, if data are to be shared. > The need for server-to-server communication does not seem to go away, as we state in the draft. Also the work on data formats seems to be needed but it turns out to be quite difficult, as we notice for a long time on location, contact information, etc. > > > 7. Client Thickness > > If the client/server interaction is really only the user-interaction surface of the mail system, where all of the actual email semantics are on the server, then this is not an email application on the client. It is a generic user interface. > > Keyclicks and text rendering are important, but they are not application semantics. > > If there is limited email semantics on the client, then this is a specialized protocol, long called a "split UI". > > If the client fully implements mailbox semantics for interacting with the server, then its interactions use a protocol comparable to IMAP or POP. > > The draft fails to demonstrate or deal with these distinctions. We actually do not deal with purely "screen sharing" approaches. That's also an interesting area of work that people are looking into (even for games). > > > > 8. Extraneous > > The draft has an extended discussion about a number of important hardware and software limitations that appear to be independent of the language and platform, as well as having nothing to do with any protocol. These should be removed, or else they should be used as a basis for recommending specific work, in the IETF or elsewhere. > > The hardware and software limitations are important for judging where limitations when going for a Web based environment with protocol design. When we did our interviews we tried to identify where the current limitations are of this HTML/JavaScript model and the writeup considers what we had been told. For example, if you want to standardize a gaming protocol that aims at high-end ego-shooters then the Web model is not useful for you. Ciao Hannes _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf