Slashdot Mirror

Procmail and sendmail (and mh's slocal, for that matter) probably had this capability well before the filing. However, to serve as prior art, you would need documented evidence that someone had conceived of using them to automatically respond to the content of a mail message prior to 1997. It's prior art, not prior capability.

Having said that, back in the late 80's/early 90's, when there were still people with dial-up UUCP connections still, there were a number of services which responded by email. Archie is the biggest one I remember off the top of my head, and if you go to http://www.yudit.org/gaspar/archie.txt you see:

        Archie Email Help (Version 3.0)

HELP for the archie email server, as of 10 April, 1993.

And it does exactly what the patent claims, and more. It sends canned responses for quite a few commands, plus it can send dynamic responses to requests for searches. The patent is obviously invalid, and now that they are picking on big companies with lots of lawyers, they are going to get buried.

For the geekier MS Windows user, how about emacs and yudit?

yudit is quite nice, as well as the new vim and emacs. An interesting exercise is to run ascii, utf-8, and utf-16 LE and utf-16 BE (little and big endian, respecitvely) representations of the same text (say a 2-line text message) through
% od
and see what's really being stored in them thar files.

There's also a whole bunch of useful tools in the ICU (no, not the Intensive Care Unit!) with links to the openl18n pages. In terms of being extremely informative, from the top-level overview of internationalisation of software down the the greatest technical detail you can actually use -- including a really useful set of software libraries with source code provided , I can't recommend the ICU pages highly enough. Context plus details in context. A revelation.

Basically, the consensus in the end was that it is impossible to avoid this sort of problem as long as you have a standard that encodes characters instead of glyphs (that means that Latin "o" and Cyrillic "o" are different characters, even though they look the same).

A character set that encoded glyphs instead of characters could avoid this. However, such charsets are extremely tedious to implement. It has been tried with the Adobe glyph registry and has been found insufficient.

In practice, glyph-based character sets are unusable. The reason is that they cannot be made fully round-trip compatible with existing character sets, such as ISO 8859 or the Windows codepages, because these legacy character sets encode characters instead of glyphs. If URLs were encoded in such a glyph-based character set, it would be impossible to embed URLs in any document in a legacy character set. No URLs in e-mails.

As a result, the only solution is to have application and operating system vendors implement checks for such situations and to have URL registries reject such obvious spoofing attempts (e.g. no mixed-alphabet URLs). Since the problem is not fundamentally different from registering slashdot.org, it is not even a problem that we weren't already aware of.

Basically, the consensus in the end was that it is impossible to avoid this sort of problem as long as you have a standard that encodes characters instead of glyphs (that means that Latin "o" and Cyrillic "o" are different characters, even though they look the same).

A character set that encoded glyphs instead of characters could avoid this. However, such charsets are extremely tedious to implement. It has been tried with the Adobe glyph registry and has been found insufficient.

In practice, glyph-based character sets are unusable. The reason is that they cannot be made fully round-trip compatible with existing character sets, such as ISO 8859 or the Windows codepages, because these legacy character sets encode characters instead of glyphs. If URLs were encoded in such a glyph-based character set, it would be impossible to embed URLs in any document in a legacy character set. No URLs in e-mails.

As a result, the only solution is to have application and operating system vendors implement checks for such situations and to have URL registries reject such obvious spoofing attempts (e.g. no mixed-alphabet URLs). Since the problem is not fundamentally different from registering slashdot.org, it is not even a problem that we weren't already aware of.

I think first the binary imcompatibility should be solved between different libraries. The linux loader can take care of different major versions but why should I have to keep 4 c-libraries for every distribution floating around to make a decent binary distribution?
Keeping track of new c-libraries that cripple my app kept me stay away from additionaly providing Yudit in a binary format, but some commercial vendors can not give you the source they are commercial !

Why dont you use Unicode? Set the context type to utf8. There is a unicode editor on http://www.yudit.org/ . There are some sample pages at the same site (Resources: Hungarian Grammar in Japanese) created quite a while back, but they still look ok.