{"id":50,"date":"2002-08-01T00:00:03","date_gmt":"2002-08-01T10:00:03","guid":{"rendered":"http:\/\/u20.freesoft.org\/blogs\/soapbox\/?p=50"},"modified":"2017-11-22T18:25:04","modified_gmt":"2017-11-23T04:25:04","slug":"data-oriented-networking","status":"publish","type":"post","link":"https:\/\/www.freesoft.org\/blogs\/soapbox\/data-oriented-networking\/","title":{"rendered":"Data-oriented Networking"},"content":{"rendered":"
\r\n\r\n\r\nInternet Engineering Task Force\r\nINTERNET-DRAFT\r\nExpires March 2003\r\n\r\n\r\n\r\n\r\n\t\t       Data-oriented networking\r\n\r\n\t\t\t   by Brent Baccala\r\n\t\t\t baccala@freesoft.org\r\n\t\t\t     August, 2002\r\n\r\n\r\n\r\n\r\n\r\nThis document is an Internet-Draft and is subject to all provisions of\r\nSection 10 of RFC2026.\r\n\r\nInternet-Drafts are working documents of the Internet Engineering Task\r\nForce (IETF), its areas, and its working groups.  Note that other\r\ngroups may also distribute working documents as Internet-Drafts.\r\n\r\nInternet-Drafts are draft documents valid for a maximum of six months\r\nand may be updated, replaced, or obsoleted by other documents at any\r\ntime.  It is inappropriate to use Internet-Drafts as reference\r\nmaterial or to cite them other than as \"work in progress.\"\r\n\r\nThe list of current Internet-Drafts can be accessed at\r\nhttp:\/\/www.ietf.org\/1id-abstracts.html\r\n\r\nThe list of Internet-Draft Shadow Directories can be accessed at\r\nhttp:\/\/www.ietf.org\/shadow.html\r\n\r\n\r\n\r\n\r\n\t\t\t       ABSTRACT\r\n\r\n   Differentiates between connection-oriented and data-oriented\r\n   networking, identifies the advantages of data-oriented networks,\r\n   argues that Internet web architecture is becoming more\r\n   data-oriented, and suggests ways of encouraging and accelerating\r\n   this trend.\r\n\r\n\r\n\r\nContemporary Internet architecture is heavily connection-oriented.  IP\r\nunderlies almost all Internet operations, and its fundamental\r\noperation is to deliver a data packet to an endpoint.  TCP uses IP to\r\nsequence streams of data packets to those endpoints; higher-level\r\nservices, such as HTTP, are built using TCP.  All of these operations\r\nare based upon the underlying IP addresses, which identify specific\r\nmachines and devices.  Even UDP operations are connection-oriented in\r\nthe sense that UDP addresses identify a specific machine on the\r\nInternet with which a connection (even just a single packet) must be\r\nestablished.  Note that I use the term connection-oriented in a\r\nsomewhat different sense than the traditional distinction between\r\nconnection-oriented and connection less protocols.\r\n\r\nMore recently, Uniform Resource Locators (URLs) have emerged as the\r\ndominant means for users to identify web resources.  The distinction\r\nis not merely one of introducing a new protocol with new terminology,\r\neither.  URLs are used to name blocks of data, not network devices.\r\nEspecially with the advent of caching, it's now clear that a web\r\nbrowser may not have to make any network connections at all in order\r\nto retrieve and display a web page.  \"Retrieving\" a URL differs\r\nsignificantly from opening an HTTP session, since an HTTP session\r\nimplies a network connection to a named device, while accessing a URL\r\nimplies only that its associated data (stored, perhaps, on a local\r\ndisk) is made available.  HTTP, SMTP, ssh, and other TCP-based\r\nprotocols are inherently connection-oriented, while the URL is\r\ninherently data-oriented.\r\n\r\nThe Internet is moving away from a connection-oriented model and\r\nbecoming more data-oriented.  Since the original Internet design was\r\nmodeled, at least loosely, after a telephone system, all of its\r\noriginal protocols were connection-oriented.  Increasingly, we're\r\nbecoming aware that often a user is not interested in connecting to\r\nsuch-and-such a computer, but rather in retrieving a specific piece of\r\ndata.  Since such operations are so common, Internet architects need\r\nto recognize the distinction between connection-oriented and\r\ndata-oriented operations and design networks to support both well.\r\nData-oriented models will not replace connection-oriented models;\r\nsometimes, you'll still want to make the telephone call.  Rather, the\r\npros and cons of each need to be understand, so both can be\r\nincorporated into the Internet of the 21st century.\r\n\r\nTo understand the emergence of data-oriented networking, it is useful\r\nto consider the historical development of the Internet.  Initially,\r\nthe driving application for what became the Internet was email,\r\nallowing virtually instantaneous communications over large distances,\r\nFTP and TELNET were second and third.  FTP provided file transfer and\r\na rudimentary publication system; TELNET extended the 1970s command\r\nline interface over the network, letting people \"log in\" over the net,\r\nthus allowing remote use and management of computer systems.\r\n\r\nEven in these early years of the Internet, the network was becoming\r\nmore data-oriented than a cursory examination of its protocols would\r\nsuggest.  FTP archive sites, such as uunet and wuarchive, began\r\nassembling collections of useful data, including programs, protocol\r\ndocuments, and mailing list archives in central locations.  Other\r\nsites began mirroring the archives, so that retrieving a particular\r\nprogram, for example, did not require a connection to a centralized\r\nserver for the program, but only a connection to a convenient mirror\r\nsite.  The practice continues to this day.  Of course, accessing the\r\nmirror sites required using the connection-oriented protocols, and the\r\nprocess of finding a mirror site or archive that contained the\r\nparticular program you wanted remained largely a manual process.  It\r\nstill does.\r\n\r\nA significant change occurred during the 1980s - the appearance of\r\ngraphical user interfaces (GUIs) in personal computers by the end of\r\nthe decade.  In the early to mid 90s, the world wide web extended the\r\nGUI over the network, much as TELNET had extended the command line\r\ninterface over the net.  More than anything else, the web represents a\r\nglobal GUI, a means of providing the commonly accepted point-and-click\r\ninterface to users around the world.\r\n\r\nIt is impossible to understate the impact of the web.  The GUI was a\r\ncritical technology that made computers more accessible to the average\r\nperson.  No longer did you need to type cryptic instructions at a\r\ncommand prompt.  To open a file, represented by a colorful icon, just\r\nmove a pointer to it and click.  Yet until the web, you still needed\r\nto use the old command-line interface to use the network.  Your\r\ndesktop PC might use a GUI, but connecting to another computer\r\ngenerally meant a venture into TELNET or FTP.  The web extended the\r\nGUI metaphor over the network.  Instead of learning FTP commands to\r\nretrieve a file, you could just browse to a web site and click on an\r\nicon.\r\n\r\nOther technologies could have provided a network GUI, but not as well\r\nas HTML and HTTP.  X Windows certainly was designed specifically with\r\nnetwork GUI applications in mind, but provided so little security that\r\nusing it to \"browse\" potentially untrusted sites was never realistic.\r\nAT&T's Virtual Network Computing (VNC) is similar to X Windows, and is\r\ndesigned so that its effects can be confined to a single window.  With\r\nsome extensions, it could be used as the basis for a network GUI.\r\nHowever, both X Windows and VNC share a single common major flaw -\r\nthey are connection-oriented protocols that presuppose a real-time\r\nlink between client and server.  The user types on the keyboard or\r\nclicks on a link, then the client transmits this input to the server,\r\nwhich processes the input and sends new information to the client,\r\nwhich redraws the screen.  X Windows has never been widely used over\r\nthe global Internet, because the bandwidth and delay requirements for\r\ninteractive operation are more stringent than the network can\r\ntypically provide.  VNC is very useful for using GUI systems remotely,\r\nbut still doesn't provide the performance of local software.\r\n\r\nThe present HTML\/HTTP-based design of the web does have one\r\noverwhelming advantage over X Windows \/ VNC, however.  The web is\r\ndata-oriented, not connection-oriented, or is at least more so than\r\nconventional protocols.  A web page is completely defined by a block\r\nof HTML, which is downloaded in a single operation.  Highlighting of\r\nlinks, typing into fill-in forms, scrolling - all are handled locally\r\nby the client.  Rather than requiring a connection to remain open to\r\ncommunicate mouse and keyboard events back to the server, the entire\r\nbehavior of the page is described in the HTML.\r\n\r\nThe advent of web caches changes this paradigm subtly, but\r\nsignificantly.  In a cache environment, the primitive operation in\r\ndisplaying a web page is no longer an end-to-end connection to the web\r\nserver, but the delivery of a named block of data, specifically the\r\nHTML source code of a web page, identified by its URL.  The presence\r\nof a particular DNS name in the URL does not imply that a connection\r\nwill be made to that host to complete the request.  If a local cache\r\nhas a copy of the URL, it will simply be delivered, without any wide\r\narea operations.  Only if the required data is missing from the local\r\ncaches will network connections be opened to retrieve the data.\r\n\r\nExperience with web caches demonstrates that data-oriented networks\r\nprovide several benefits.  First, the bandwidth requirements of a\r\nheavily cached, data-oriented network is much less than a\r\nconnection-oriented network.  Connection-oriented protocols such as X\r\nwindows, VNC, and TELNET presuppose a real-time connection between\r\nclient and server, and in fact could not operate without such a\r\nconnection, since the protocols do not specify how various user\r\nevents, such as keyclicks, should be handled.  All the protocols do is\r\nto relay the events across the network, where the server decides how\r\nto handle them, then sends new information back to the client in\r\nresponse.  A data-oriented network, which specifies the entire\r\nbehavior of the web page in a block of HTML, does not require a\r\nreal-time connection to the server.  Having retrieved the data to\r\ndescribe a web page, the connection can be severed and the user can\r\nbrowse through the page, scrolling, filling out forms, watching\r\nanimations, all without any active network connection.  Only when the\r\nuser moves to another web page is a connection required to retrieve\r\nthe data describing the new page.  Furthermore, since the data\r\ndescribing the pages is completely self-contained, no connection to\r\nthe original server is required at all if a copy of the web page can\r\nbe found.  A copy, stored anywhere on the network, works as well as\r\nthe original.  As the network becomes more data-oriented, fewer and\r\nbriefer connections are required to carry out various operations,\r\nreducing overall network load.\r\n\r\nA data-oriented network is also more resilient to failures and\r\npartitions than a connection-oriented network.  Consider the\r\npossibility of a major network failure, such as the hypothetical\r\nnuclear strike that originally motivated the Defense Department to\r\nbuild the packet-based network that evolved into the Internet.  Modern\r\nrouting protocols would probably do a fairly good job of rerouting\r\nconnections around failed switching nodes, probably in a matter of\r\nminutes, but what if the destination server itself were destroyed?\r\nThe connection would be lost, and no clear fallback path presents\r\nitself.  The obvious solution is to have backup copies of the server's\r\ndata stored in other locations, but creating and then finding these\r\nbackups is currently done by hand.  Existing routing protocols can\r\nreroute connections, but are woefully inadequate for rerouting data.\r\n\r\nA more mundane, but far more common scenario is the partitioned\r\nnetwork.  Simply operating in a remote area may dictate long periods\r\nof operation without network connectivity.  In such an environment,\r\nit'd be convenient to drop any information that might be needed on a\r\nset of CD-ROMs.  That works fine until the first search page comes up\r\nthat connects to a specialized program on the web server, or a CGI\r\nscript that presents dynamic content, or an image map.  Solutions have\r\nbeen developed to put web sites on CD-ROMs - none of them standard,\r\nmost of them incomplete.  A more data-oriented design, that didn't\r\ndepend on connections to a server, would be far better suited to such\r\nsituations.\r\n\r\nHTML, the workhorse protocol of the web, was never designed with use\r\nas a network GUI in mind, even though this is the role it has evolved\r\ninto.  It's the HyperText Markup Language (HTML), and hypertext is not\r\na GUI.  Hypertext is text that includes hyperlinks.  Perhaps we can\r\nexpand the definition somewhat into a \"hyperdocument\" that can include\r\ncolors, diagrams, pictures, and even animation.  A GUI is much more\r\nthan a hyperdocument, however.  A GUI is a complete user interface\r\nthat provides the human front end to a program.  Not only can it\r\ninclude dialog boxes, pull down menus and complex mouse interactions,\r\nbut more than anything else it provides the interface to a program,\r\nwhich could perform any arbitrary task, and is thus not just a\r\ndocument.  The program could be a document browser, a document editor,\r\na remote login client, a language translator, a simulation package,\r\nanything.  What was pioneered by Xerox PARC, deployed by Apple Lisa,\r\nmarketed by Macintosh and brought with such stunning success to the\r\nmasses by Microsoft was not hypertext, but the GUI.  The GUI is what\r\nwe are trying to extend across the network, not hypertext, and thus\r\nHTML just isn't very well suited for the task.\r\n\r\nSince it wasn't designed to provide a network GUI, HTML doesn't\r\nprovide the right primitives for the task it has been asked to\r\nperform, and thus we've seen a long series of alterations and\r\nenhancements.  First there was HTML 2, then HTML 3, then HTML 4, now\r\nHTML with Cascading Style Sheets, soon XHTML, plus Java applets,\r\nJavascript, CGI scripts, servlets, etc, etc...  The fact that HTML has\r\nhad to change so much, and that the changes require network-wide\r\nsoftware updates, is a warning sign that the protocol is poorly\r\ndesigned.  The problem is that HTML has been conscripted as a network\r\nGUI, though, to this day, it has never been clearly designed with this\r\ngoal in mind.  Part of what is needed is a replacement for HTML\r\nspecifically designed to act as a network GUI.\r\n\r\nIn addition, one of the great challenges to a data-oriented model is\r\ndynamic pages.  Presently, web caching protocols provide means for\r\nincluding meta information, in either HTTP or HTML, that inhibits\r\ncaching on dynamic pages, and thus forces a connection back to the\r\norigin server.  While this works, it breaks the data-oriented metaphor\r\nwe'd like to transition towards.  To maintain the flexibility of\r\ndynamic content in a data-oriented network, we need to lose the\r\nend-to-end connection requirement and this seems to imply caching the\r\nprograms that generate the dynamic web pages.  While cryptographic\r\ntechniques for verifying the integrity of data have been developed and\r\nare increasingly widely deployed, no techniques are known for\r\nverifying the integrity of program execution on an untrusted host,\r\nsuch as a web cache.  Baring a technological breakthrough, it seems\r\nimpossible for a cache to reliably run the programs required to\r\ngenerate dynamic content.  The only remaining solution is to cache the\r\nprograms themselves (in the form of data), and let the clients run the\r\nprograms and generate the dynamic content themselves.  Thus, another\r\npart of what's needed is a standard for transporting and storing\r\nprograms in the form of data.\r\n\r\nAn important change in moving to a more data-oriented network would be\r\nto replace HTML with a standard specifically designed to provide a\r\ndata-oriented network GUI.  The features of this new protocol:\r\n\r\n  1) It must be data-oriented, not connection-oriented.  Thus, the\r\n     protocol must define a data format that can describe GUI behavior\r\n     on a remote system.  HTML already basically does this.\r\n\r\n  2) It must programmatic.  The whole point is to eliminate the server\r\n     and replace it with a standard, network-deliverable specification\r\n     of the GUI behavior.  The exact behaviors of GUI interfaces\r\n     vary dramatically, and simply providing an escape mechanism\r\n     to connect back to the server violates the data-oriented\r\n     design goal.  Thus, the protocol must implement powerful enough\r\n     primitives to describe arbitrary GUI behaviors without escape\r\n     mechanisms, i.e. it must support arbitrary programming constructs.\r\n\r\n  3) It must be secure.  Since the program may be untrusted to\r\n     the client, it must be limited from performing arbitrary\r\n     operations on the client system.\r\n\r\n  4) It must provide GUI primitives, and cleanly interact with other\r\n     GUI applications, such as window managers, and provide features\r\n     such as drag-and-drop functionality between windows.\r\n\r\n  5) It must provide backwards compatibility with the existing web.\r\n\r\nThe programmatic requirement fairly well dictates some kind of\r\nvirtual machine architecture, and the obvious candidate is therefore\r\nJava, but Java may or may not be the best choice.  Netscape began\r\nwork on a 100% Java web browser, but abandoned this effort in 1998.\r\nCommenting on the demise of \"Javagator\", Marc Andreesen quipped - \"it's\r\nslower, it will crash more and have fewer features... it will simplify\r\nyour life\".\r\n\r\nThis misses the point.  We're not trying to build an Java-based HTML\r\nweb browser that would simply achieve cross-platform operability.  The\r\ngoal is to build a web browser that, as its primary metaphor, presents\r\narbitrary Java-based GUIs to the user.  HTML could be displayed using\r\na Java HTML browser.  The difference is that the web site designer\r\ncontrols the GUI by providing the Java engine for the client to use\r\nfor displaying any particular page.  Switching to a different web site\r\n(or web page) might load a different GUI for interacting with that\r\nsite's HTML, or XML, or whatever.  Unlike Andreesen's \"Javagator\", the\r\nchoose of GUI is under control of the web server, not tied into a\r\nJava\/HTML web browser.\r\n\r\nFor example, consider if a web site wants to allow users to edit its\r\nHTML pages in a controlled way.  Currently, you have a few choices,\r\nnone completely satisfactory.  First, you could put your HTML in an\r\nHTML textbox, and allow the user to edit it directly, clicking a\r\nsubmit button to commit it and see what the page will actually look\r\nlike.  Alternately, you could allow the HTML to be edited with\r\nNetscape Composer or some third party HTML editor on the client,\r\naccepting the HTML back from the client in a POST operation.  This\r\nprovides the server very little control over exactly what the user can\r\nand can't do to the page.  Since parts of the page might be\r\nautomatically generated, this isn't satisfactory, nor do we really\r\nknow much about this unspecified \"third party editor\".  On the other\r\nhand, with a Java browser, the web site could simply provide a\r\nmodified HTML engine that would allow the user to edit the page, in a\r\nmanner completely specified by the web designer, prohibiting\r\nmodifications to parts of the page automatically generated, and\r\nallowing special cases, such as spreadsheet tables with the page, to\r\nbe handled specially.\r\n\r\nAnother advantage to this proposal is that it provides a solution to a\r\nproblem plaguing XML - how do you actually display to the user the\r\ninformation you've encoded in XML?  This is left glaringly unaddressed\r\nby the XML standards, the solution seeming to be that you either use a\r\ncustom application capable of manipulating the particular XML data\r\nstructures, or present the data in two different formats - XHTML for\r\nhumans and XML for machines.  A Java-based web browser addresses this\r\nproblem.  You ship only one format - XML - along with a Java\r\napplication that parses and presents it to the user.\r\n\r\nOn the other hand, let's keep Andressen's criticism in mind. Java may\r\nnot be suitable for such a protocol, for either technical or political\r\nreasons.  The speed issues seem to be largely addressed by the current\r\ngeneration of Just-In-Time (JIT) Java runtimes, but whatever the\r\nstandard is, it should be an RFC-published, IETF standard-track\r\nprotocol, and if the intellectual property issues around Java preclude\r\nthis, then something else needs to replace it.  Alternatives include\r\nParrot, the yet unfinished Perl 6 runtime, and Microsoft's .NET\r\narchitecture, based around a virtual machine architecture recently\r\nadopted as ECMA standard ECMA-335.\r\n\r\nPDF also deserves consideration.  Though it lacks the generality to\r\nprovide a network GUI, its presentation handling is vastly superior to\r\nHTML's, giving the document author complete control over page layout,\r\nand allowing the user to zoom the document to any size for easy\r\nviewing.  It is also easier to render than HTML, since its page layout\r\nis more straightforward for the browser to understand.\r\n\r\nA definite metaphor shift is required.  Rather than viewing HTML as\r\nthe primary standard defining the web, the primary standard must\r\nbecome Java or something like it, that provides full programmability.\r\nBrowsing a web page becomes downloading and running the code that\r\ndefines that page's behavior, rather than downloading and displaying\r\nHTML, that might contain an embedded applet.\r\n\r\nBackwards compatability can be provided along the lines of HotJava,\r\nSun's proprietary Java-based web browser, which implements HTML in\r\nJava.  To display an HTML page, Java classes are loaded which parse\r\nthe HTML and display it within a Java application.  The browser\r\nprovides little more than a Java runtime that can download arbitrary\r\nJava and run it in a controlled environment.  Initially, 99% of the\r\npages would be HTML, viewed using a standard (and cached) HTML engine\r\ncoded in Java.\r\n\r\nNotwithstanding the creeping featurism present in Java, adopting this\r\napproach would avoid the creeping featurism so grossly apparent in web\r\nbrowsers.  Even the casual observer will note that mail, news, and\r\nteleconferencing are simply bloat that results in multi-megabyte\r\n\"kitchen sink\" browsers.  Will the next release of Netscape, one might\r\nask, contain an Emacs mail editor with its embedded LISP dialect?  And\r\nif not, why not?  Only because the majority of users wouldn't use\r\nEmacs to edit their mail?  Why should we all be forced to use one type\r\nof email browser?  Why should we have Netscape's email browser\r\npackaged into our web browser if we don't use it?  Like the constant\r\nversioning of HTML, the shear size of modern browsers is a warning\r\nsign that the web architecture is fundamentally flawed.  A careful\r\nattempt to standardize \"network Java\" would hopefully result in\r\nsmaller, more powerful browsers that don't have to be upgraded every\r\ntime W3C revs HTML; you simply update the Java GUI on those particular\r\nsites that are taking advantage of the newer features.\r\n\r\nAnother tremendous advantage is the increased flexibility provided to\r\nweb designers.  HTML took a big step in this direction with Cascading\r\nStyle Sheets, but CSS doesn't provide the power of a full GUI.  For\r\nexample, if a web page designer wanted to, he could publish an HTML\r\npage with a custom Java handler that allowed certain parts of the HTML\r\ntext to be selectively edited by the user.  This simply can't be done\r\nusing CSS.\r\n\r\nNetwork-deliverable, data-oriented GUIs aren't a panacea, or course.\r\nFor starters, one of the advantages of the present model is that all\r\nweb pages have more or less the same behavior (since they are all\r\nviewed with the same GUI).  The \"Back\" and \"Forward\" buttons are\r\nalways in the same place, the history function always works the same\r\nway, you click on a link and basically the same thing happens as\r\nhappens on any other page.  Providing the web designer with the\r\nability to load a custom GUI changes all that.  Standards need to be\r\ndeveloped for finding and respecting user preferences concerning the\r\nappearance of toolbars, the sizing of fonts, the operation of links.\r\nThe maturing Java standards have already come a long way towards\r\naddressing issues such as drag-and-drop that would have to be\r\neffectively implemented in any network GUI.\r\n\r\nHurdles need be crossed before we can reach a point where web\r\ndesigners can depend on Java-specific features.  One possibility would\r\nbe to migrate by presenting newer web pages to older browsers using a\r\nJava applet embedded in the web page.  Performance might suffer, but\r\nclever design would hopefully make it tolerable.  For starters,\r\nconsider that the web page data presented to the applet need not be\r\nthe source HTML, but could be a processed version with page layout\r\nalready done.  Newer, Java-only browsers should be leaner and faster.\r\n\r\nIn summary, I recommend the following steps:\r\n\r\n1. Recognize the importance of data-oriented design, as opposed to\r\n   connection-oriented design.  Break the dependence on special server\r\n   configurations and realize that the client has to do almost all the\r\n   work in a scalable, cached, redundant web architecture.\r\n\r\n2. Migrate the web towards being based on a model of a network GUI,\r\n   rather than a massively enhanced hypertext system.\r\n\r\n3. Select a standard for the network delivery of executable content,\r\n   Java being the most likely candidate\r\n\r\n4. Develop a Java-based HTML browser along the lines of HotJava, but\r\n   completely open, allowing existing HTML-based websites to be\r\n   browsed via Java.  Provide an applet version that allows web\r\n   designers to specify a custom Java applet to browse their HTML\r\n   sites using conventional web browsers.\r\n\r\n5. Develop a lean, fully Java-based web browser, with Multivalent\r\n   being the most obvious candidate.\r\n\r\n6. Recognize the transient nature of HTML\/HTTP and specify their\r\n   operation in terms of a generic API, based on the network\r\n   executable content standard (probably Java), for finding and\r\n   delivering the GUI presented by a specified URL.\r\n\r\nWith all the inertia built up behind the present web design, one needs\r\nto question the wisdom of abandoning HTML and completely re-vamping\r\nthe structure of the web, even if a migration path is in place.  The\r\npromise of data-oriented networking is a leaner, more reliable, more\r\nefficient network.  Ultimately, if this analysis is correct, then the\r\ncost of migrating away from a flawed design will ultimately be less\r\nthan the cost of constantly shoehorning it.  However, in his essay,\r\n\"The Rise of 'Worse is Better'\", Richard Gabriel suggests \"that it is\r\noften undesirable to go for the right thing first.  It is better to\r\nget half of the right thing available so that it spreads like a\r\nvirus.\"  Bearing this in mind, I've proposed an alternate set of\r\nrecommendations, aimed at something more immediately practical, in a\r\ncompanion essay, \"Standardized caching of dynamic web content\".  At\r\nthe same time, I think it's time to take another look at the\r\nJava-based web browser, and to seriously ask if Java isn't a better\r\nchoice than HTML for a network standard GUI.\r\n\r\n\r\n\r\n\r\nREFERENCES\r\n\r\nHypertext Markup Language (HTML) \/ Extensible Markup Language (XML)\r\n\r\n   HTML has a long and sordid history.  HTML version 2, specified in\r\n   RFC 1866, was one of the earliest (1995) documented HTML versions.\r\n   Later revisions added tables (RFC 1942), applets (HTML 3.2),\r\n   JavaScript and Cascading Style Sheets (HTML 4.01).\r\n\r\n   http:\/\/www.w3c.org\/MarkUp\/\r\n\r\nUniversal Resource Locators\r\n\r\n   RFC 1630 - Universal Resource Identifiers in WWW\r\n\r\n   RFC 1737 - Functional Requirements for Uniform Resource Names, a\r\n      short document notable for its high-level overview of URN\r\n      requirements\r\n\r\n   RFC 1738 - Uniform Resource Locators, a technical document of more\r\n      importance to programmers than architects\r\n\r\nAuthentication\r\n\r\n   International standard X.509 (not available on-line)\r\n\r\n   http:\/\/www.openssl.org\/\r\n\r\n   http:\/\/www.openssh.org\/\r\n\r\nDNS Security\r\n\r\n   RFC 2535 - Domain Name System Security Extensions\r\n\r\n   RFC 2536 - DSA KEYs and SIGs in the Domain Name System\r\n\r\n   RFC 2538 - Storing Certificates in the Domain Name System\r\n\r\n   RFC 3110 - RSA\/SHA-1 SIGs and RSA KEYs in the Domain Name System\r\n\r\nPostscript\/PDF\r\n\r\n   Postscript specification\r\n      http:\/\/www.adobe.com\/products\/postscript\/pdfs\/PLRM.pdf\r\n\r\n   PDF Reference: Adobe portable document format version 1.4\r\n   (ISBN 0-201-75839-3)\r\n   http:\/\/partners.adobe.com\/asn\/developer\/acrosdk\/docs\/filefmtspecs\/PDFReference.pdf\r\n\r\n   Ghostscript - freely available Postscript interpreter that also\r\n      reads and writes PDF and thus can be used to convert PS to PDF\r\n\r\n   Multivalent (see below) includes a Java PDF viewer\r\n\r\n   html2ps - a largely illegible Perl script written by Jan Karrman\r\n      to convert HTML to Postscript.  Yes, it can be done.\r\n\r\nX Windows\r\n\r\n   Developed by an MIT-lead consortium, X Windows is one of the most\r\n   successful network GUIs\r\n   http:\/\/www.x.org\/\r\n\r\nVNC (Virtual Network Computing)\r\n\r\n   Similar in concept to X Windows, but radically different in\r\n   design - an absurdly simple protocol combined with various\r\n   compression techniques to achieve decent WAN performance\r\n   http:\/\/www.uk.research.att.com\/\r\n\r\nJava\r\n\r\n   Java Virtual Machine (JVM) specification\r\n\r\n   Bill Venner's excellent Under the Hood series for JavaWorld\r\n   is a better starting point than the spec for understanding JVM.\r\n   He also has written a book - Inside the Java Virtual Machine\r\n   (McGraw-Hill; ISBN 0-07-913248-0)\r\n      http:\/\/www.javaworld.com\/columns\/jw-hood-index.shtml\r\n\r\n   Java 2 language reference\r\n\r\n   Java languages page\r\n      http:\/\/grunge.cs.tu-berlin.de\/~tolk\/vmlanguages.html\r\n\r\n   Criticism of Java\r\n      http:\/\/www.jwz.org\/doc\/java.html\r\n\r\nOther virtual machines\r\n\r\n   Perl 5 runtime\r\n\r\n   Parrot - Perl 6 runtime\r\n      http:\/\/www.parrotcode.com\/\r\n\r\n   Microsoft's .NET architecture includes the Common Language\r\n   Infrastucture, based around a virtual machine, now adopted as\r\n   ECMA-335\r\n      http:\/\/msdn.microsoft.com\/net\/ecma\/\r\n      http:\/\/www.ecma.ch\/ecma1\/STAND\/ecma-335.htm\r\n\r\nVarious Java-based web browsers\r\n\r\n   HotJava, Sun's Java browser, but with binary-only licensing\r\n      http:\/\/java.sun.com\/products\/hotjava\/\r\n\r\n   Multivalent, an open-source web browser written totally in Java,\r\n   with an extension API to add \"behaviors\" similar to applets\r\n      http:\/\/www.cs.berkeley.edu\/~phelps\/Multivalent\/\r\n\r\n   NetBeans, an attempt to develop a \"fully functional Java browser\"\r\n      http:\/\/netbrowser.netbeans.net\/\r\n\r\n   Jazilla, a now defunct attempt to carry the \"Javagator\" project\r\n   forward under an open source banner\r\n      http:\/\/jazilla.sourceforge.net\/\r\n\r\nJava Servlets\/WARs\r\n\r\n   \"Tomcat is the servlet container that is used in the official\r\n    Reference Implementation for the Java Servlet and JavaServer Pages\r\n    technologies.\"\r\n      http:\/\/jakarta.apache.org\/tomcat\/\r\n\r\n   Java Servlets - server-side Java API (CGI-inspired; heavily\r\n   HTTP-based) The Java servlet specification includes a chapter\r\n   specifying the WAR (Web Application Archive) file format, an\r\n   extension of ZIP\/JAR\r\n      http:\/\/java.sun.com\/products\/servlet\/\r\n\r\nCaching\r\n\r\n   RFC 3040 - Internet Web Replication and Caching Taxonomy\r\n      broad overview of caching technology\r\n\r\n   RFC 2186 - Internet Cache Protocol (ICP), version 2\r\n\r\n   RFC 2187 - Application of ICP\r\n\r\n   Squid software\r\n   http:\/\/www.squid-cache.org\/\r\n\r\n   NLANR web caching project\r\n   http:\/\/www.ircache.net\/\r\n\r\n   Various collections of resources for web caching\r\n      http:\/\/www.web-cache.com\/\r\n      http:\/\/www.web-caching.com\/\r\n      http:\/\/www.caching.com\/\r\n\r\n   IETF Web Intermediaries working group (webi)\r\n      http:\/\/www.ietf.org\/html.charters\/OLD\/web-charter.html\r\n\r\n   IETF Web Replication and Caching working group (wrec)\r\n      http:\/\/www.wrec.org\/\r\n\r\n   RFC 3143 - Known HTTP Proxy\/Caching problems\r\n\r\n   Cache Array Routing Protocol (CARP) - used by Squid\r\n      http:\/\/www.microsoft.com\/Proxy\/Guide\/carpspec.asp\r\n      http:\/\/www.microsoft.com\/proxy\/documents\/CarpWP.exe\r\n\r\n   RFC 2756 - Hypertext Caching Protocol (HTCP) - use by Squid\r\n\r\nNapster and its variants\r\n\r\n   Napster, the original peer-to-peer file sharing service, has been\r\n   fraught with legal difficulties, having recently entered bankruptcy\r\n      http:\/\/www.napster.com\/\r\n\r\n   Napster's protocol lives on, even if the service is dead.  It's\r\n   basically a centralized directory with distributed data\r\n      http:\/\/opennap.sourceforge.net\/\r\n      http:\/\/opennap.sourceforge.net\/napster.txt\r\n\r\n   Gnutella has emerged as the leading post-Napster protocol,\r\n   employing both a distributed directory and distributed data\r\n      http:\/\/www.gnutella.com\/\r\n      http:\/\/www.gnutelladev.com\/\r\n      http:\/\/www.darkridge.com\/~jpr5\/doc\/gnutella.html\r\n\r\n   Several popular clients use the Gnutella network and protocol\r\n      http:\/\/www.morpheus-os.com\/\r\n      http:\/\/www.limewire.org\/\r\n      http:\/\/www.winmx.com\/\r\n\r\n   Other proprietary peer-to-peer systems\r\n      http:\/\/www.kazaa.com\/\r\n\r\n   Other free peer-to-peer systems\r\n      http:\/\/www.freenetproject.org\/\r\n\r\nRichard Gabriel, \"The Rise of 'Worse is Better'\"\r\n   http:\/\/www.jwz.org\/doc\/worse-is-better.html\r\n\r\nBrent Baccala, \"Standardized caching of dynamic web content\"\r\n   http:\/\/www.freesoft.org\/Essays\/dynamic-content-caching\/\r\n\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
Internet Engineering Task Force INTERNET-DRAFT Expires March 2003 Data-oriented networking by Brent Baccala baccala@freesoft.org August, 2002 This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also … <\/p>\n
Continue reading “Data-oriented Networking”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"episode_type":"","audio_file":"","podmotor_file_id":"","podmotor_episode_id":"","cover_image":"","cover_image_id":"","duration":"","filesize":"","filesize_raw":"","date_recorded":"","explicit":"","block":"","footnotes":""},"categories":[3],"tags":[],"series":[],"class_list":["post-50","post","type-post","status-publish","format-standard","hentry","category-networking"],"episode_featured_image":false,"episode_player_image":"https:\/\/www.freesoft.org\/blogs\/soapbox\/wp-content\/uploads\/2021\/03\/brent-300x300-1.jpeg","download_link":"","player_link":"","audio_player":false,"episode_data":{"playerMode":"dark","subscribeUrls":{"apple_podcasts":{"key":"apple_podcasts","url":"","label":"Apple Podcasts","class":"apple_podcasts","icon":"apple-podcasts.png"},"google_podcasts":{"key":"google_podcasts","url":"","label":"Google Podcasts","class":"google_podcasts","icon":"google-podcasts.png"},"spotify":{"key":"spotify","url":"","label":"Spotify","class":"spotify","icon":"spotify.png"},"stitcher":{"key":"stitcher","url":"","label":"Stitcher","class":"stitcher","icon":"stitcher.png"}},"rssFeedUrl":"https:\/\/www.freesoft.org\/blogs\/soapbox\/feed\/podcast\/the-soapbox","embedCode":"
Data-oriented Networking<\/a><\/blockquote>