Hello Hoby, I think if he wants his protocol to prevail, he will need to document it very well then. Coding binary protocols are inherently more difficult for people beginner to it. That's why I gave the TCP example.
Also, with today's fast CPUs, it would not matter if there were a few more bytes transferred. Plus he could still have 4 steps--just a text version. Because if you compare FTP to HTTP, FTP is slower because of the lots of steps and he has a point in keeping it at 4... Regards, SZ On 2/7/08, Hoby Smith <[EMAIL PROTECTED]> wrote: > > 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 > -- 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
