Hello SZ... Astute observation about "formats" vs. "protocols". However, I don't think that David has done away with TCP/IP, the transport protocol used for sending the email with. In a sense, all layer 7 solutions can really be considered a "format" in a TCP payload. So, the distinction really blurs there to some degree.
Regardless, the core issue is still relevant, namely that binary systems think in a binary context. If a driving constraint is efficiency and minimalist approaches, binary formats and protocols are mandated. Regardless of how you slice it, binary makes better sense FROM THE SYSTEMS perspective. As for the TCP hacking attacks you reference, they PALE in comparison to the security flaws that are revealed and exploited on a daily basis that stem from the inherent lack of security in the original web protocol designs. Additionally, those TCP hacks provide no security related exposure, in the sense of data compromise, but rather in systems resiliency. Syn-attacks will not get to your corporate data. XSS attacks, on the other hand, can provide a wonderful mechanism for compromising your systems in a number of ways. Additionally, SSL dependence is at the root of almost ALL BAD web thinking. However, everyone still thinks the Emperor looks great and somehow it's just going to work itself out. If the web protocols had envisioned ANY CONCEPT of user and state, instead of the stupid session-less paradigm it enforces, as well as in-transit security, there would be no need for the web stack paradigm to exist in its currently flawed state. Regarding testing new protocols, new "standards" emerge EVERY DAY. In the xml related world (given this is a format not a protocol), they emerge every minute. Considering that numerous security hacks attack FORMAT weaknesses in the OS and related software (image files, etc), this issue still applies. Scores of them pass through corporate enterprises without testing every day. Additionally, anything constructed as a layer 7 solution is going to pass through the internet architecture just fine, barring various packet inspector rules, etc. Again, I don't think David has invented a new TCP stack, but rather just different info being passed through TCP. Regards... Hoby -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fastream Technologies Sent: Thursday, February 07, 2008 10:35 AM To: ICS support mailing Subject: Re: [twsocket] AN: New e-mail protocol (spam free and more!) MP3 is not a protocol but a file format. You are right that TCP/UDP uses binary headers but we are talking about a high level protocol, which if popularized, will be coded by third party coders according to RFC and this I believe will not be so trivial for the binary case! ICS has codes for SMTP/POP/HTTP/FTP (all text) but not for TCP. Wasn't there a need for low level stacks? Think again--we have all lived through syn-attacks and ping-o-deaths. Keep in mind that Microsoft recoded the entire TCP/IP stack in Windows 2008 Server just for this. But since it was something hard to do, through the past decade, Microsoft was being waited to step forward. ALso, for adoption, large enterprises want to test every protocol they use--when they are new. Testing a binary protocol for them would also be hard and this might hammer adoption globally. We have customers who study and stress test for 29 days to understand how our caching and then decide to buy at the end of the trial period! Regards, SZ On 2/7/08, Hoby Smith <[EMAIL PROTECTED]> wrote: > > Actually, IMNSHO (In My Not So Humble Opinion), binary protocols make much > smarter sense for binary machines. Even with the discrepancies of the > various flavors of binary formats (big vs little endian, etc), it is WAY > MORE EFFICIENT for binary machines to use binary protocols than to > interpret > human readable formats (text, xml, etc) into binary formats so that they > may > be processed appropriately by processor and related software. Only humans > think in the context of textual formats; computers do not. The overhead > associated with textual translation is a horrible side effect of the web > phenomenon. > > Actually, the statement "no popular/common protocol is designed that way" > is > horribly inaccurate. True, the W3C has an inherent conflict of interest > in > driving the pervasive use of textual formats. However, there are tens of > thousands of binary formats that predate the stupid web stack and continue > to emerge daily. For example, consider TCP, which is a binary protocol > and > the actual core technology upon which this mail list and ICS is > founded. I > would consider TCP to be "popular" and "common". It is only the layer 7 > centric, web focused protocols that are textual in nature. Unfortunately, > the web has set computing back about 20 years, the effects of which has > only > recently begun to be realized in all of its awful consequences (slow > cumbersome interfaces, security issues galore, etc). > > Quite some time back, before clients of various types were ubiquitous, it > was necessary for servers to understand human readable formats (ftp, etc). > That need has long been outlived and the perspective that drives it is > seriously antiquated. With very few exceptions, the data needs of server > systems are way too complex to be constrained by human readable formats. > > For example, are you going to type the binary values for a MIME image that > you want to embed in an email? Try doing that via a textual SMTP > interface. > The whole need of MIME was to overcome the stupid limitations of a textual > email standard. Let's see, how do I represent binary data in a textual > format. Yeah, that makes perfect sense. In a web world, I guess it does. > How about a word document? Do you want a format that you have to type the > font details manually, like HTML? NO, you use a word processor that does > all that for you and then stores it in format that the system understands. > How about audio? Do you want a media stream protocol that is human > readable? Such a media protocol would be too slow be feasible. MP3 is a > BINARY solution that attempts to answer the audio data issues. Everyone > uses a piece of software that understands MP3. I would consider MP3 to be > "common" and "popular", even though it is BINARY. > > For computing needs, the future reality is surely a return to strong > binary > representations that can be interpreted into forms that humans can > understand as needed, or can be handled by clients as necessary. > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Fastream Technologies > Sent: Thursday, February 07, 2008 5:43 AM > To: ICS support mailing > Subject: Re: [twsocket] AN: New e-mail protocol (spam free and more!) > > I wonder why he chose a binary format instead of text as no popular/common > protocol is designed that way (i.e. HTTP, FTP, IMAP--all telnet based)! > > Regards, > > SZ > > > On 2/7/08, DZ-Jay <[EMAIL PROTECTED]> wrote: > > > > So, rather than a new "protocol", you have created a new e-mail server > > and client system which communicates in its own proprietary binary > > format? > > > > dZ. > > > > On Feb 6, 2008, at 18:50, David A. G. wrote: > > > > > Dear friends, > > > > > > I have developed a complete and very improved e-mail protocol, highly > > > immune > > > to the SPAM, with data encryption and compression, with sender ID > > > validation, etc. BUT not compatible with the standard email (SMTP). > > > > -- > > DZ-Jay [TeamICS] > > http://www.overbyte.be/eng/overbyte/teamics.html > > > > -- > > To unsubscribe or change your settings for TWSocket mailing list > > please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket > > Visit our website at http://www.overbyte.be > > > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be > > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be > -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
