{"id":561,"date":"2004-10-29T13:58:00","date_gmt":"2004-10-29T17:58:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/2004\/10\/29\/protocol-independence\/"},"modified":"2004-10-29T13:58:00","modified_gmt":"2004-10-29T17:58:00","slug":"protocol-independence","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2004\/10\/protocol-independence\/","title":{"rendered":"Protocol independence"},"content":{"rendered":"<p>The real issue with protocol independence, I believe, is the\nword &#8220;protocol&#8221;; that the two camps in this debate &#8211; the Web\/Internet\nfolks, and the Web services folks &#8211; each have their own, quite\ndifferent, definition of the word.  For Web services proponents,\n&#8220;protocol&#8221; means one thing and one thing only; a spec whose job it is\nto move bits from point A to point B over a network.<\/p>\n\n<p>Meanwhile, for the Web\/Internet crowd, &#8220;protocol&#8221; has a much broader\ndefinition.  In common use, it encompasses the &#8220;bit moving&#8221; specs, but\nalso others which do a lot more than simply move bits (more below).\nSome even (properly, IMO) refer to the data formats, such as HTML, as\nprotocols, though you don&#8217;t see that too often any more.<\/p>\n\n<p>As if this disconnect wasn&#8217;t bad enough, another &#8211; interface\nconstraints &#8211; compounds the problem.  Specifically, Internet based efforts\n(including the Web, of course) always start with an interface constraint.\nThis is simply for the reason that they&#8217;re (usually) always focused on a\nsingle task &#8211; for example,\n<a href=\"http:\/\/www.ietf.org\/rfc\/rfc2821.txt\">email exchange<\/a>,\n<a href=\"http:\/\/www.ietf.org\/rfc\/rfc3501.txt\">mail folder access and synchronization<\/a>,\n<a href=\"http:\/\/www.ietf.org\/rfc\/rfc959.txt\">file transfer<\/a> &#8211;\nand pay little to no attention to what it means to define interoperability\nbetween those applications, since that&#8217;s tangential to their primary\nobjective.  A consequence of this approach is that there becomes little\nvalue in using a common sub-layer-7 protocol (like BEEP, IIOP, or how\nmost people use SOAP).  This has enormous benefit, with the big one being\nit permits the\n<a href=\"http:\/\/www.xml.com\/pub\/au\/215\">mechanics of mapping onto the network<\/a>\nto be optimized for the semantics; consider that without GET, HTTP wouldn&#8217;t have\nneeded a bunch of features, in particular caching.  When semantics are detached\nfrom the &#8220;wire format&#8221; (as with BEEP et al, as mentioned previously), it&#8217;s\noptimized for no particular application, thereby\n<a href=\"http:\/\/www.ietf.org\/rfc\/rfc817.txt\">resulting in poor performance<\/a>\nfor practically all applications.<\/p>\n\n<p>I&#8217;ve drawn a diagram that I hope helps explain these two different\nviews;<\/p>\n\n<img decoding=\"async\" src=\"http:\/\/www.markbaker.ca\/2004\/10\/Stacks\/\">\n\n<p>Hopefully you&#8217;ll at least see the fundamentally different visions\nof the stack in play here, and perhaps better appreciate my concern about\n&#8220;protocol independence&#8221;.  Protocols play a much more important role in the\nstack on the right than they do in the one on the left!<\/p>","protected":false},"excerpt":{"rendered":"The real issue with protocol independence, I believe, is the word &#8220;protocol&#8221;; that the two camps in this debate &#8211; the Web\/Internet folks, and the Web services folks &#8211; each have their own, quite different, definition of the word. For Web services proponents, &#8220;protocol&#8221; means one thing and one thing only; a spec whose job [&hellip;]","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[26,40],"class_list":["post-561","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-soap","tag-xml"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/561","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/comments?post=561"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/561\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=561"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=561"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=561"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}