Slashdot Mirror

Actually, you probably wouldn't assign them static IPv6 addresses. It's much more likely that they would use IPv6 stateless address autoconfiguration (btw, www.ietf.org is an Ipv6-accessible site), to obtain an address automatically.

IP addresses:
I can't remember my IPv4 addresses without looking them up, so I'd be no worse off than with IPv6. You'll get older too son, then you'll agree with me :)

As for web hosting providers, they won;t ever have to 'change your IP address', they'll just have to tell you it in the first place, then you're done.

In both cases, IPv6 supports auto-registration so you won't have to fiddle with it anyway. As the IETF says "Since IPv6 addresses are too long to remember and EUI64-based addresses are too complicated to remember, they are not suitable for such identifiers"

IIRC you don't need DHCP anymore with stateless autoconfiguration.

NAT:
think for a moment what NAT does. All you have is your router attached to the internet, and all your computers connected to the router. Unless you explicitly allow incoming connections to pass through, your PCs are "firewalled" at the router.

If you have IPv6, you'll still have the router. I hope that all router manufacturers will be shipping them with incoming connectivity disabled by default, just like it is at the moment. Then, you'll be no less secure with IPv6 than you are today.

You will have the benefit of being able to "DMZ" as many of your PCs as you like, not just one of them. This is best of both worlds.

I think IPv6 will be a good thing, if it ever happens. I can't see that happening anytime soon though, there's too much infrastructure out there.

It's not binary logic.

In the post you responded to, I pointed out that it is a continuum for cripe's sake. We are in agreement that this is a shades of gray issue.

However, in *some* people, it *is* like a switch. That first drink- and you are an alchoholic. That first hit of heroin and you are a junky. That first hit of child porn and you are an addict to it. In *most* people, that's not the case- I know lots of people who did cocaine multiple times without a problem in the 80's including my sister-in-law. I knew people who cocaine use destroyed. Some people die the first time they use it from heart attacks.

While I think these activities should be legal (on porn- anything with consenting adults), I also respect that some people who are vulnerable do not want their lives ruined by involuntary exposure.

As a society we have a right to say, "I might be at risk so I want the right to choose what I expose myself too."
Being able to force people to see various kinds of pornography without their consent is akin to sneaking heroin into their food or force-feeding them alcohol.

BTW, It was car fact, not a car analogy.

Some other references to attractive nuisances here..
http://www1.ietf.org/mail-archive/web/asrg/current/msg00701.html

A lot more random examples here: http://www.google.com/search?hl=en&q=car+%22attractive+nuisance%22&btnG=Search

It may not apply in your country if you are not in the united states.

Does anybody know whether it's going to be compatible with RFC 3251 Electricity over IP?

Anybody wanting to develop a smart electricity grid should take a look at that document, includes lots of information about hazardous voltage drops and other pitfalls that can be avoided.

Native American smoke signals date back to pre-Columbian times.

Torches and and other forms of optical telegraphy date back to ancient times.

Thanks to the seminal work of J. Hofmueller and his colleagues, modern flag semaphores can also be used to encapsulate IP datagrams. Presumably, this is more efficient than delivering the same traffic by animal transport but less efficient than by wire or radio.

Native American smoke signals date back to pre-Columbian times.

Torches and and other forms of optical telegraphy date back to ancient times.

Thanks to the seminal work of J. Hofmueller and his colleagues, modern flag semaphores can also be used to encapsulate IP datagrams. Presumably, this is more efficient than delivering the same traffic by animal transport but less efficient than by wire or radio.

For the last time, DNS is not a content classification system. But I've got this idea that'll work, it's called parental responsibility. I know, what a concept...

Comcast is adding support for IPv6 network wide. Each Comcast cable modem is managed and thus has a public IP address in addition to the one allocated to the customer, furthermore, the rise of triple play and digital set top boxes means that these also require IPs. They were using NET-10 (10.x.y.z) but they *exhausted this space*. So now they have an even larger public block. Their migration strategy is to use it for managing modems remotely now, and when the market demands it will be easy to offer IPv6 service to customers since their entire backbone is already routing v6. Clearly this is a slow, ongoing process, but "real" ISPs have already recognized the need for it.

They started this process in 2005. Check out these presentations for more info:

http://www3.ietf.org/proceedings/05aug/slides/lrw-5.pdf

http://www.ripe.net/ripe/meetings/ripe-54/presentations/IPv6_management.pdf

Shouldn't this have been an obvious or apparent extension of RFC 1149 (or RFC 2549, for that matter) when considered in the context of natural behavior and as a proper logic exercise, instead of just a joke? A very senior security engineer and I managed to find all kinds of other interesting implications when laying out a real-world network design by using IP over Avian carriers as an analogy for the data carrying portion of a cellular telecom network, and then expanding into the rest of the forest for descriptions of other portions and functions of a network of that size and complexity. We gleaned some very interesting insights from the exercise... I'm unsurprised that someone found a corollary in the behavior of a beehive - any natural system you study is liable to have similar applications in computing, whether it's circuit design or layer 3, esp. when the system in question involves a social species.

I prefer pigeons myself.

It's more than "pretty close". Read RFC 2119.

For the relevant definition of "should", see http://www.ietf.org/rfc/rfc2119.txt

The word has a strict meaning in this context, there is an RFC about it.
So this "Should" vs. "Shall" is a mute point, they meant what they said.

The reason why ISPs can get away with copying resources into their caches is because they are "incidental copies", where permission for copying is implied for the purpose of normal operation. Web developers can apply Cache-Control: no-transform to indicate that changes of this nature should not take place. It seems to me that any ISP that alters such pages would be creating unauthorised derivative works and permission would not be implied to copy, thus making them guilty of copyright infringement.

... but I am as confident as I am that the Sun will rise tomorrow that it will be safe from terrorists. After all, we have the children to think about.

July 12, 2005

Copyright © 2005 Michael David Crawford.

This work is licensed under a Creative Commons Attribution-NoDerivs 2.5 License.

It seems that David Clark, who led the development of the Internet way back in the '70's - did you know there even was a '70's? - wants to create a whole new Internet that will fix many of the problems the current Internet is plagued with. The New Internet's engineers will be much more careful this time around to make sure it works better than the first one did.

I'm afraid, though, that the engineers are not the only ones who will be deciding how our New Internet will work.

If one is able to find any privacy or anonymity in this New Internet, it will be because of some undiscovered security hole, which will be quickly repaired, rather than any kind of conscious design decision. Probably one reason they are accepting proposals before rolling it out is to avoid the sort of accidental security holes that enable pr0n, peer-to-peer filesharing and left-wing political activism.

Microsoft, a leading contributor both to this nation's technology base and to the campaign coffers of its leaders, will embrace this new technology and extend it in such a way that the development and dissemination of Open Source software will be, if not mathematically and physically impossible, at least as intractible as factoring a 2048-bit public key.

Imagine, if you will, Trusted Computing implemented at the router level, in such a way that any packets that go farther than one hop are certified not only to support protocols whose patent licenses are fully paid-up and on file with the legal department in Redmond, but whose content is compliant with the Windows standard. The faintest whisp of a Public License, GNU or otherwise, will result in the dropping not only of the individual packet, not only in the cancellation of the entire file transmission, but, within microseconds, the reporting of the physical location of the offending server to responsible law enforcement personnel. The identities of its rogue administrators will be fetched instantly from the database maintained by the Department of Homeland Security. (You will have to submit fingerprints and DNA samples to obtain a Windows server license, as after all, Internet servers can be used to disseminate explosives r

.org was not created for non-profit organizations, it was originally created as a catch-all for organizations that didn't meet the requirements for the other gTLDs. PIR's History Page, RFC 920, RFC 1591

.org was not created for non-profit organizations, it was originally created as a catch-all for organizations that didn't meet the requirements for the other gTLDs. PIR's History Page, RFC 920, RFC 1591

1. Encryption adds overhead.
   
2. A certain popular protocol's encrypted version's clients pop up all sorts of warnings if the server certificate is not signed by a known entity.
   
   Of the three most popular browsers these days, a site with a self-signed certificate shows the following:
   
   1. IE6
      
   2. Firefox 2
      
   3. IE7
      
   
   While the average person may know that this is not necessarily bad, mom and pop are probably going to avoid sites that bring up these errors, particularly if they're using IE7.
   

"One Click" shopping is an e-commerce technique, which allows a customer to purchase products via the Internet without repeatedly entering personal information such as name and address. At the time it was introduced it eased the frustration of on-line shopping.

The problem is, the whole reason cookies were created was precisely to enable on-line shopping:
http://www.ietf.org/rfc/rfc2109.txt

So soon after the RFC was *announced* Amazon requested a patent for doing what the RFC was specifically designed for. If you ignore the sleeziness of the action, it would be virtually impossible to find prior art since no implementation was possible before the standard was approved. And even if an early implementations of cookies existed, since Amazon was one of the few e-commerce site out there at the time, there would be virtually no chance of finding another prior art implementation.

Now you could go to the real-world analogy of going to a friendly store and pointing at a bunch of things and saying "Charge it", but since it's done by "a computer" it magically turns into a completely different thing.

Oh yeah, Bonjour is totally undocumented:

- Zeroconf, the internationally standardized RFC 3927 upon which Bonjour is based, isn't documented at all

- Nor are Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD), the open standards which make up Apple's Bonjour implementation

Apple also has nearly no Bonjour end user, developer, or technical overview documentation, and certainly doesn't make the source code, or even a binary Windows version, available.

And yeah, products like iTunes, Apple TV, local host discovery, all HP and many other network printers, and similar totally don't use Bonjour, so it's ok to block it.

The lack of documentation alone might make one want to block it!

• The first internet worm was unix based.
• DHCP not developed by microsoft.
• POP not developed by microsoft.
• PPP not developed by microsoft.

• The first internet worm was unix based.
• DHCP not developed by microsoft.
• POP not developed by microsoft.
• PPP not developed by microsoft.

• The first internet worm was unix based.
• DHCP not developed by microsoft.
• POP not developed by microsoft.
• PPP not developed by microsoft.

US threathened closing GPS whenever they felt like,

That would be because our military built it for military purposes, and our taxpayers paid for it. You've now built your own that you control. Great! Enjoy it! Use it in good health! You can stop bitching about it now.

Same thing goes for the Internet. We built it. You don't like it? Build your own. Here, let me help you out: It's all right here. Get busy and shut the fuck up.

US has what we call a "dick problem"

It wasn't the US that went on a 500 year long murder, rape, looting, and enslavement spree on every continent of the globe, chuckles. That would be Europe.

It wasn't the US that started two global wars in which millions died. That would be Europe.

It wasn't the US that invented the death camp, the fascist regime and the communist slave state. That would be Europe.

It wasn't even the US that "killed all the Indians". Most of that happened before the US even existed, and was done by... you guessed it, Europeans. Of course, there are still plenty of Indians here (there are a lot more Indians in the US than there are Jews in Germany, for sure).

We don't trust Europeans any farther than we can throw them. For good reason.

Ever notice that even though fascism is always "descending on the United States", it always lands on Europe?

for example in the eastern part of germany, after reunification, there were lines in cities that could not be used for DSL. the german "freifunk" (literally "free wireless", both as in beer and as in speech) project managed to build some sizeable city mesh nets using a routing protocol known as OLSR [1,2].

just look in awe at the leipzig cloud [3]. also, try to imagine wireless cell phone / pda mesh nets (probably doable right now with openmoko).

[1] http://olsr.org/
[2] http://www.ietf.org/rfc/rfc3626.txt
[3] http://db.leipzig.freifunk.net/uptime/png/ -- careful, images is 3165x4206

The sole purpose of a webserver is to publish content (such content can have restricted access, but examples of that are very much the exception to the rule). The sole purpose of a WAP is *not* to share an internet connection with anyone who happens to be driving by...

The sole purpose of an Access Point (what's in a name) is to provide access to a network. No more, no less. And the cases where webservers are either used internally, or provide limited access to the information they publish are numerous, or would you call every online music store, every webmail server, every closed forum or corperate intranet a exception? That would be millions of exceptions...

...nor is it reasonable to assume that someone wants you to piggyback off their WAP any more than it is reasonable to assume they want you to piggyback off their electricity, gas, water, satellite TV or telephone "just because you can".

There is no assumption, there is a (perfectly formilized even) request for access to a (publicly advertised) network. The answer can be either yes or no. But when the answer it turns out to be yes, why should I still assume it actually meant no? That exactly the same with a webserver, a doorbell and borrowing a car, you communicate a request, and may or may not receive an answer. But when you do recieve an answer and it happens to be yes you recieved permission.

No, it's not, any more than leaving you car unlocked with the keys in it is giving "permission" for someone to take it.

Ofcourse it isn't, but did I argue anybody should be allowed to take away an AP when it is unsecured? But when a door is open, it is, at least it is overhere, allowed to enter a house. Also it is generally needed to enter somebody elses property just to ring the doorbell. Unless there is a clear indication otherwise you are allowed to enter. That's why there are fences and 'No tresspassing' signs. APs provide perfect equivalents of these things, totally useless as protection someone with bad intentions, but very effective as a means to indicate intent and to keep passers-by of your network. Use them, or accept the incidental visitor.

Please quote the relevant part of the standard where having an unsecured WAP implied consent to use services accessible through it. I'll be happy to wait.

You first, the http specification (you know, the webserver stuff) is found in .

Let me put it this way. You will have a very easy time convincing a judge and/or jury that someone publishing a website is doing so with the knowledge that it will be open and accessible to others because a) that's what the common understanding of the pupose of a website is and b) it's pretty much impossible publish a website "accidentally". You will have a very difficult time convincing a judge and/or jury that an unsecured WAP is an advertisement and implied consent for free internet access based on the principle it gave you an IP address because a) that's not what most people want to do with their WAPs and b) because it's _very_ easy to ignorantly setup an unsecured WAP.

You personally will have a very hard time arguing just that when someone links you to this very slashdot discussion. Put pulling up the user manual for a AP will pretty much do the same in most cases. Failing to read it should not be and excuse.
But also, the amount of ignorance about these things declining, the amount of accesspoints with stupid default configurations is dropping even faster. So even it it is a valid argument, it is running away from you as we speak.

Further, no amount of arguing "but look how easy it is" (which is essentially all you're doing) is going to change their mind. Neither is arguing "it's just like putting up a website", when typically the intent behind doing that is completely different.

No, that is not what i'm arguing. What i'm arguing is tha

If you want your own Internet, the information is all there. For free.

If you want your own Slashdot, that's all there for free, too.

Stop whining and go build them. Until then, STFU.

Thanks!

This is by no means an argument against using Gmail for your setup, it is merely a note regarding your 'ISP's (properly) blocking SMTP to servers other than their own'. This is indeed a proper thing, as email clients should not be sending outbound mail directly to receipient SMTP servers - they should be submitting to an SMTP server that serves them (eg which the user has an account on), which then relays the message.

However, port 25 is not the proper port to be doing this on, and is, as you noted, usually blocked. Port 587 (configured properly to only allow authenticated connections to relay messages) is the right port, and is usually not blocked, as it isnt useful for sending spam (Few, if any, mailservers accept inbound messages on port 587, or indeed anything other than port 25).

See http://www.ietf.org/rfc/rfc2476.txt

Ignoring uucp (most people do), I think the more accurate characterization is:

email beta: SMTP released [1]
email 1.0: POP released (two years later) [2]
email 2.0: IMAP released (four years later) [3]

[1] August 1982, http://tools.ietf.org/html/rfc821
[2] October 1984, http://tools.ietf.org/html/rfc918
[3] July 1988, http://tools.ietf.org/html/rfc1064

(Yes, there's a history as to why that's IMAP2 and not IMAP1)

Ignoring uucp (most people do), I think the more accurate characterization is:

email beta: SMTP released [1]
email 1.0: POP released (two years later) [2]
email 2.0: IMAP released (four years later) [3]

[1] August 1982, http://tools.ietf.org/html/rfc821
[2] October 1984, http://tools.ietf.org/html/rfc918
[3] July 1988, http://tools.ietf.org/html/rfc1064

(Yes, there's a history as to why that's IMAP2 and not IMAP1)

Ignoring uucp (most people do), I think the more accurate characterization is:

email beta: SMTP released [1]
email 1.0: POP released (two years later) [2]
email 2.0: IMAP released (four years later) [3]

[1] August 1982, http://tools.ietf.org/html/rfc821
[2] October 1984, http://tools.ietf.org/html/rfc918
[3] July 1988, http://tools.ietf.org/html/rfc1064

(Yes, there's a history as to why that's IMAP2 and not IMAP1)

The POP3 RFC: http://www.ietf.org/rfc/rfc1939.txt is 23 pages. The IMAP RFC is 108 http://www.ietf.org/rfc/rfc3501.txt

Why do you think?

The POP3 RFC: http://www.ietf.org/rfc/rfc1939.txt is 23 pages. The IMAP RFC is 108 http://www.ietf.org/rfc/rfc3501.txt

Why do you think?

"URL of the form www.domain_name/search_string, where domain_name is a domain name of the web server system" Jassy, et al. needs to read the RFCs! There are nice, reserved domains for uses such as this: example.com, example.net, and example.org. This is very handy when writing documents of this type and everyone should use it. http://www.ietf.org/rfc/rfc2606.txt

Every day, I miss the concept of "rough consensus and running code" a bit more.

I think "domain name" might be a little more accurate.

ATM Machine. Here we go with the semantic arguments ;)

If we can have a 'DNS name server', a DNS name space and a Reserved Top Level DNS Names, why can't we say 'DNS name'?

I say 'DNS name' out of habit, because I used to work with people who used the term 'domain' to refer to a different kind of computer system, and 'Domain name' just caused confusion.

I think "domain name" might be a little more accurate.

ATM Machine. Here we go with the semantic arguments ;)

If we can have a 'DNS name server', a DNS name space and a Reserved Top Level DNS Names, why can't we say 'DNS name'?

I say 'DNS name' out of habit, because I used to work with people who used the term 'domain' to refer to a different kind of computer system, and 'Domain name' just caused confusion.

RTF RFC, Gatesfucker.

A URL is an entire address, including the protocol, local path and fragment identifier. This is a URL:

http://slashdot.org/foo?bar=baz#qux

A domain name does not include the protocol, the local path or the fragment identifier. This is a domain name:

slashdot.org

This is talking about domain names, not URLs. If anybody would talk about multilingual URLs, it would be the IETF, not ICANN, and they already have, they are called IRIs.

I started reading the first chapter and I was surprised when I read the following paragraph:

Gzip is currently the most popular and effective compression method. It is a free for- mat (i.e., unencumbered by patents or other restrictions) developed by the GNU project and standardized by RFC 1952. The only other compression format you're likely to see is deflate, but it's slightly less effective and much less popular. In fact, I have seen only one site that uses deflate: msn.com. Browsers that support deflate also support gzip, but several browsers that support gzip do not support deflate, so gzip is the preferred method of compression.

Unfortunately, it looks like the author does not know what he is talking about, since gzip is based on the deflate algorithm. It is likely that the author did not even look at RFC 1952 because this is stated clearly in the abstract:

This specification defines a lossless compressed data format that is
compatible with the widely used GZIP utility. The format includes a
cyclic redundancy check value for detecting data corruption. The
format presently uses the DEFLATE method of compression but can be
easily extended to use other compression methods. The format can be
implemented readily in a manner not covered by patents.

If you look at the HTTP/1.1 definition, you will see that section 3.5 specifies the meanings of the compression types "gzip" and "deflate":

• gzip An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952.
• deflate The "zlib" format defined in RFC 1950 in combination with the "deflate" compression mechanism described in RFC 1951.

In fact, it is unfortunate that the HTTP/1.1 RFC used the name "deflate" for this content coding, because it would have been more appropriate to name it "zlib". And both "gzip" and "zlib" are based on the deflate algorithm, as you can easily see if you take a quick look at RFC 1952 (gzip) and RFC 1950 (zlib). Both of them have a flag CM for the compression method, and the only one that is defined is CM=8 for the deflate method (RFC 1951). So the HTTP/1.1 RFC is a bit confusing, but a quick look at the corresponding RFCs for gzip and zlib can clear up that confusion easily.

The difference between gzip and zlib (deflate) are minimal. The gzip file header can be a few bytes longer because it includes the file modification time, optional extra fields, the original file name and a file comment. Note that none of these fields are useful for HTTP transfers, because the same information is already included in the HTTP headers (except for the optional comment, which is ignored anyway).

So the statement in the sample chapter saying that deflate (zlib) "is slightly less effective" than gzip is just wrong. It is actually the opposite: the zlib header would be a few bytes shorter than the gzip header. No, the main difference between both formats is that gzip (the format) is more popular because gzip (the program) is popular. And you can easily use the gzip program to pre-compress the static contents on your server so that it does not have to do it on-the-fly all the time. It would be much better if the author would re-write that paragraph and not make it sound like the formats are significantly different when they are based on the same algorithm. Also, the reference to the effectiveness of one or the other is misleading.

I started reading the first chapter and I was surprised when I read the following paragraph:

Gzip is currently the most popular and effective compression method. It is a free for- mat (i.e., unencumbered by patents or other restrictions) developed by the GNU project and standardized by RFC 1952. The only other compression format you're likely to see is deflate, but it's slightly less effective and much less popular. In fact, I have seen only one site that uses deflate: msn.com. Browsers that support deflate also support gzip, but several browsers that support gzip do not support deflate, so gzip is the preferred method of compression.

Unfortunately, it looks like the author does not know what he is talking about, since gzip is based on the deflate algorithm. It is likely that the author did not even look at RFC 1952 because this is stated clearly in the abstract:

This specification defines a lossless compressed data format that is
compatible with the widely used GZIP utility. The format includes a
cyclic redundancy check value for detecting data corruption. The
format presently uses the DEFLATE method of compression but can be
easily extended to use other compression methods. The format can be
implemented readily in a manner not covered by patents.

If you look at the HTTP/1.1 definition, you will see that section 3.5 specifies the meanings of the compression types "gzip" and "deflate":

• gzip An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952.
• deflate The "zlib" format defined in RFC 1950 in combination with the "deflate" compression mechanism described in RFC 1951.

In fact, it is unfortunate that the HTTP/1.1 RFC used the name "deflate" for this content coding, because it would have been more appropriate to name it "zlib". And both "gzip" and "zlib" are based on the deflate algorithm, as you can easily see if you take a quick look at RFC 1952 (gzip) and RFC 1950 (zlib). Both of them have a flag CM for the compression method, and the only one that is defined is CM=8 for the deflate method (RFC 1951). So the HTTP/1.1 RFC is a bit confusing, but a quick look at the corresponding RFCs for gzip and zlib can clear up that confusion easily.

The difference between gzip and zlib (deflate) are minimal. The gzip file header can be a few bytes longer because it includes the file modification time, optional extra fields, the original file name and a file comment. Note that none of these fields are useful for HTTP transfers, because the same information is already included in the HTTP headers (except for the optional comment, which is ignored anyway).

So the statement in the sample chapter saying that deflate (zlib) "is slightly less effective" than gzip is just wrong. It is actually the opposite: the zlib header would be a few bytes shorter than the gzip header. No, the main difference between both formats is that gzip (the format) is more popular because gzip (the program) is popular. And you can easily use the gzip program to pre-compress the static contents on your server so that it does not have to do it on-the-fly all the time. It would be much better if the author would re-write that paragraph and not make it sound like the formats are significantly different when they are based on the same algorithm. Also, the reference to the effectiveness of one or the other is misleading.

I started reading the first chapter and I was surprised when I read the following paragraph:

Gzip is currently the most popular and effective compression method. It is a free for- mat (i.e., unencumbered by patents or other restrictions) developed by the GNU project and standardized by RFC 1952. The only other compression format you're likely to see is deflate, but it's slightly less effective and much less popular. In fact, I have seen only one site that uses deflate: msn.com. Browsers that support deflate also support gzip, but several browsers that support gzip do not support deflate, so gzip is the preferred method of compression.

Unfortunately, it looks like the author does not know what he is talking about, since gzip is based on the deflate algorithm. It is likely that the author did not even look at RFC 1952 because this is stated clearly in the abstract:

This specification defines a lossless compressed data format that is
compatible with the widely used GZIP utility. The format includes a
cyclic redundancy check value for detecting data corruption. The
format presently uses the DEFLATE method of compression but can be
easily extended to use other compression methods. The format can be
implemented readily in a manner not covered by patents.

If you look at the HTTP/1.1 definition, you will see that section 3.5 specifies the meanings of the compression types "gzip" and "deflate":

• gzip An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952.
• deflate The "zlib" format defined in RFC 1950 in combination with the "deflate" compression mechanism described in RFC 1951.

In fact, it is unfortunate that the HTTP/1.1 RFC used the name "deflate" for this content coding, because it would have been more appropriate to name it "zlib". And both "gzip" and "zlib" are based on the deflate algorithm, as you can easily see if you take a quick look at RFC 1952 (gzip) and RFC 1950 (zlib). Both of them have a flag CM for the compression method, and the only one that is defined is CM=8 for the deflate method (RFC 1951). So the HTTP/1.1 RFC is a bit confusing, but a quick look at the corresponding RFCs for gzip and zlib can clear up that confusion easily.

The difference between gzip and zlib (deflate) are minimal. The gzip file header can be a few bytes longer because it includes the file modification time, optional extra fields, the original file name and a file comment. Note that none of these fields are useful for HTTP transfers, because the same information is already included in the HTTP headers (except for the optional comment, which is ignored anyway).

So the statement in the sample chapter saying that deflate (zlib) "is slightly less effective" than gzip is just wrong. It is actually the opposite: the zlib header would be a few bytes shorter than the gzip header. No, the main difference between both formats is that gzip (the format) is more popular because gzip (the program) is popular. And you can easily use the gzip program to pre-compress the static contents on your server so that it does not have to do it on-the-fly all the time. It would be much better if the author would re-write that paragraph and not make it sound like the formats are significantly different when they are based on the same algorithm. Also, the reference to the effectiveness of one or the other is misleading.

I started reading the first chapter and I was surprised when I read the following paragraph:

Gzip is currently the most popular and effective compression method. It is a free for- mat (i.e., unencumbered by patents or other restrictions) developed by the GNU project and standardized by RFC 1952. The only other compression format you're likely to see is deflate, but it's slightly less effective and much less popular. In fact, I have seen only one site that uses deflate: msn.com. Browsers that support deflate also support gzip, but several browsers that support gzip do not support deflate, so gzip is the preferred method of compression.

Unfortunately, it looks like the author does not know what he is talking about, since gzip is based on the deflate algorithm. It is likely that the author did not even look at RFC 1952 because this is stated clearly in the abstract:

This specification defines a lossless compressed data format that is
compatible with the widely used GZIP utility. The format includes a
cyclic redundancy check value for detecting data corruption. The
format presently uses the DEFLATE method of compression but can be
easily extended to use other compression methods. The format can be
implemented readily in a manner not covered by patents.

If you look at the HTTP/1.1 definition, you will see that section 3.5 specifies the meanings of the compression types "gzip" and "deflate":

• gzip An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952.
• deflate The "zlib" format defined in RFC 1950 in combination with the "deflate" compression mechanism described in RFC 1951.

In fact, it is unfortunate that the HTTP/1.1 RFC used the name "deflate" for this content coding, because it would have been more appropriate to name it "zlib". And both "gzip" and "zlib" are based on the deflate algorithm, as you can easily see if you take a quick look at RFC 1952 (gzip) and RFC 1950 (zlib). Both of them have a flag CM for the compression method, and the only one that is defined is CM=8 for the deflate method (RFC 1951). So the HTTP/1.1 RFC is a bit confusing, but a quick look at the corresponding RFCs for gzip and zlib can clear up that confusion easily.

The difference between gzip and zlib (deflate) are minimal. The gzip file header can be a few bytes longer because it includes the file modification time, optional extra fields, the original file name and a file comment. Note that none of these fields are useful for HTTP transfers, because the same information is already included in the HTTP headers (except for the optional comment, which is ignored anyway).

So the statement in the sample chapter saying that deflate (zlib) "is slightly less effective" than gzip is just wrong. It is actually the opposite: the zlib header would be a few bytes shorter than the gzip header. No, the main difference between both formats is that gzip (the format) is more popular because gzip (the program) is popular. And you can easily use the gzip program to pre-compress the static contents on your server so that it does not have to do it on-the-fly all the time. It would be much better if the author would re-write that paragraph and not make it sound like the formats are significantly different when they are based on the same algorithm. Also, the reference to the effectiveness of one or the other is misleading.

I'm sure the authors of the PGP/MIME would like to hear the details of the flaws you have uncovered in their RFC.

OpenPGP is an IETF standard. Just like S/MIME and ASN.1

http://www.ietf.org/rfc/rfc2440.txt
http://www.faqs.org/rfcs/rfc3156.html

I didn't read the entire paper, but after looking over the pretty pictures it looks like the sending party has to resend the message? That will only happen 50% of the time.

It could be greylisting, where the resend will be automatic. From the sender's point of view, there was just a delay. It's hard to say -- the article is not terribly well-written. The author's name is familiar, so googling on it turns up some other papers:

http://home.nyc.rr.com/spamsolution/UniversalAuthentication.htm

some discussion can be found here:

http://www1.ietf.org/mail-archive/web/asrg/current/msg12403.html

Its hard to tell from his summaries, but assuming the approaches are the same thing, it looks like he reinvented tagged addresses among other things. ALl in all, it looks grotesquely complex.

A Google search revealed this intelligent discussion of the scheme.
http://www1.ietf.org/mail-archive/web/asrg/current/msg12403.html