Index of /dev/null

Gnu Libidn EsZett Hotfix

2010-11-01T16:11:35Z

Dies ist kein Update der Libidn auf IDNA2008. Ziel ist es, mit einfachen Mitteln das IDNA2003-Mapping von Codepoints der Kategorie PVALID (RFC 5892), insbesondere also des "ß" (U+00DF; LATIN SMALL LETTER SHARP S), bei Bedarf unterdrücken zu können. Ausgangspunkt ist die Erfordernis, kurzfristig Domainnamen mit "ß" innerhalb der DE-Zone verabeiten zu können.

]]> Die Änderungen werden hier nur für die C#-Version in libidn-1.9 erwähnt und sind ggf. auf andere Sprachen oder Versionen zu übertragen.

Ziel ist es, die Funktionen ToAscii und ToUnicode um einen Parameter bool useIDNA2008 zu erweitern, der die Wirkung hat, dass PVALID Codepoints vom Mapping ausgenommen werden.

(1) Hinzufügen einer Klasse IDNA2008, die alle PVALID Codepoints enthält:

  // IDNA2008.cs
  namespace Gnu.Inet.Encoding {
    class IDNA2008
    {
      // rfc5892 PVALID codepoints
      public static char[] PVALID = new char[] {
        '\u00DF', // LATIN SMALL LETTER SHARP S
        '\u03C2', // GREEK SMALL LETTER FINAL SIGMA
        '\u06FD', // ARABIC SIGN SINDHI AMPERSAND
        '\u06FE', // ARABIC SIGN SINDHI POSTPOSITION ME
        '\u0F0B', // TIBETAN MARK INTERSYLLABIC TSHEG
        '\u3007'  // IDEOGRAPHIC NUMBER ZERO
      };
    }
  }

(2) Überladen der Funktion Map (Stringprep.cs) mit einem dritten Parameter, der zu ignorierende Codepoints bezeichnet:

  internal static void Map(StringBuilder s, char[] search, string[] replace, char[] ignore)
  {
    for (int i = 0; i < search.Length; i++)
    {
      char c = search[i];

      // check if c should be ignored
      bool ign = false;
      for (int t = 0; t < ignore.Length; t++)
      {
        if (ignore[t] == c)
        {
          ign = true;
          break;
        }
      }
      if (ign)
        continue;

      int j = 0;
      while (j < s.Length)
      {
        if (c == s[j])
        {
          //s.deleteCharAt(j);
          s.Remove(j, 1);
          if (null != replace[i])
          {
            s.Insert(j, replace[i]);
            j += replace[i].Length - 1;
          }
        }
        else
        {
          j++;
        }
      }
    }
  }

(3) Überladen der Funktion Nameprep (Strinprep.cs) mit einem dritten Parameter bool useIDNA2008:

  public static string NamePrep(string input, bool allowUnassigned, bool useIDNA2008)
  {
    if (input == null)
    {
      throw new System.NullReferenceException();
    }

    StringBuilder s = new StringBuilder(input);

    if (!allowUnassigned && Contains(s, RFC3454.A1))
    {
      throw new StringprepException(StringprepException.CONTAINS_UNASSIGNED);
    }

    Filter(s, RFC3454.B1);

    // EsZett Hotfix
    if (useIDNA2008)
      Map(s, RFC3454.B2search, RFC3454.B2replace, IDNA2008.PVALID);
    else
      Map(s, RFC3454.B2search, RFC3454.B2replace);


    s = new StringBuilder(NFKC.NormalizeNFKC(s.ToString()));
    // B.3 is only needed if NFKC is not used, right?
    // map(s, RFC3454.B3search, RFC3454.B3replace);

    if (Contains(s, RFC3454.C12) || Contains(s, RFC3454.C22) || Contains(s, RFC3454.C3) || Contains(s, RFC3454.C4) || Contains(s, RFC3454.C5) || Contains(s, RFC3454.C6) || Contains(s, RFC3454.C7) || Contains(s, RFC3454.C8))
    {
      // Table C.9 only contains code points > 0xFFFF which Java
      // doesn't handle
      throw new StringprepException(StringprepException.CONTAINS_PROHIBITED);
    }

    // Bidi handling
    bool r = Contains(s, RFC3454.D1);
    bool l = Contains(s, RFC3454.D2);

    // RFC 3454, section 6, requirement 1: already handled above (table C.8)

    // RFC 3454, section 6, requirement 2
    if (r && l)
    {
      throw new StringprepException(StringprepException.BIDI_BOTHRAL);
    }

    // RFC 3454, section 6, requirement 3
    if (r)
    {
      if (!Contains(s[0], RFC3454.D1) || !Contains(s[s.Length - 1], RFC3454.D1))
      {
        throw new StringprepException(StringprepException.BIDI_LTRAL);
      }
    }

    return s.ToString();
  }

(4) Überladen der Funktionen ToAscii und ToUnicode (IDNA.cs), um den Parameter bool useIDNA2008 an Nameprep durchzureichen:

  public static string ToASCII(string input, bool allowUnassigned, bool useSTD3ASCIIRules, bool useIDNA2008)
  {
    // Step 1: Check if the string contains code points outside
    //         the ASCII range 0..0x7c.

    bool nonASCII = false;

    for (int i = 0; i < input.Length; i++)
    {
      int c = input[i];
      if (c > 0x7f)
      {
        nonASCII = true;
        break;
      }
    }

    // Step 2: Perform the nameprep operation.

    if (nonASCII)
    {
      try
      {
        input = Stringprep.NamePrep(input, allowUnassigned, useIDNA2008);
      }
      catch (StringprepException e)
      {
        // TODO
        throw new IDNAException(e);
      }
    }

    // Step 3: - Verify the absence of non-LDH ASCII code points
    //    (char) 0..0x2c, 0x2e..0x2f, 0x3a..0x40, 0x5b..0x60,
    //    (char) 0x7b..0x7f
    //         - Verify the absence of leading and trailing
    //           hyphen-minus

    if (useSTD3ASCIIRules)
    {
      for (int i = 0; i < input.Length; i++)
      {
        int c = input[i];
        if ((c <= 0x2c) || (c >= 0x2e && c <= 0x2f) || (c >= 0x3a && c <= 0x40) || (c >= 0x5b && c <= 0x60) || (c >= 0x7b && c <= 0x7f))
        {
          throw new IDNAException(IDNAException.CONTAINS_NON_LDH);
        }
      }

      if (input.StartsWith("-") || input.EndsWith("-"))
      {
        throw new IDNAException(IDNAException.CONTAINS_HYPHEN);
      }
    }

    // Step 4: If all code points are inside 0..0x7f, skip to step 8

    nonASCII = false;

    for (int i = 0; i < input.Length; i++)
    {
      int c = input[i];
      if (c > 0x7f)
      {
        nonASCII = true;
        break;
      }
    }

    string output = input;

    if (nonASCII)
    {

      // Step 5: Verify that the sequence does not begin with the ACE prefix.

      if (input.StartsWith(ACE_PREFIX))
      {
        throw new IDNAException(IDNAException.CONTAINS_ACE_PREFIX);
      }

      // Step 6: Punycode

      try
      {
        output = Punycode.Encode(input);
      }
      catch (PunycodeException e)
      {
        // TODO
        throw new IDNAException(e);
      }

      // Step 7: Prepend the ACE prefix.

      output = ACE_PREFIX + output;
    }

    // Step 8: Check that the length is inside 1..63.

    if (output.Length < 1 || output.Length > 63)
    {
      throw new IDNAException(IDNAException.TOO_LONG);
    }

    return output;
  }


  public static string ToUnicode(string input, bool allowUnassigned, bool useSTD3ASCIIRules, bool useIDNA2008)
  {
    string original = input;
    bool nonASCII = false;

    // Step 1: If all code points are inside 0..0x7f, skip to step 3.

    for (int i = 0; i < input.Length; i++)
    {
      int c = input[i];
      if (c > 0x7f)
      {
        nonASCII = true;
        break;
      }
    }

    // Step 2: Perform the Nameprep operation.

    if (nonASCII)
    {
      try
      {
        input = Stringprep.NamePrep(input, allowUnassigned, useIDNA2008);
      }
      catch (StringprepException e)
      {
        // ToUnicode never fails!
        return original;
      }
    }

    // Step 3: Verify the sequence starts with the ACE prefix.

    if (!input.StartsWith(ACE_PREFIX))
    {
      // ToUnicode never fails!
      return original;
    }

    string stored = input;

    // Step 4: Remove the ACE prefix.

    input = input.Substring(ACE_PREFIX.Length);

    // Step 5: Decode using punycode

    string output;

    try
    {
      output = Punycode.Decode(input);
    }
    catch (PunycodeException e)
    {
      // ToUnicode never fails!
      return original;
    }

    // Step 6: Apply toASCII

    string ascii;

    try
    {
      ascii = ToASCII(output, allowUnassigned, useSTD3ASCIIRules, useIDNA2008);
    }
    catch (IDNAException e)
    {
      // ToUnicode never fails!
      return original;
    }

    // Step 7: Compare case-insensitively.

    if (!ascii.ToUpper().Equals(stored.ToUpper()))
    {
      // ToUnicode never fails!
      return original;
    }

    // Step 8: Return the result.

    return output;
  }

(5) Testen von ToAscii und ToUnicode mit und ohne Anwendung von IDNA2008:

  [TestMethod()]
  public void Test030_EsZett_IDNA2003()
  {

    string u1 = "täßt";

    // Nameprep IDNA2203 should send "täßt" to "tässt"
    string u2 = Stringprep.NamePrep(u1, false, false);
    Assert.AreEqual("tässt", u2);

    // ToAscii IDNA2003 should send both "täßt" and "tässt" to "xn--tsst-loa"
    string a1 = IDNA.ToASCII(u1, false, true, false);
    Assert.AreEqual("xn--tsst-loa", a1);

    string a2 = IDNA.ToASCII(u2, false, true, false);
    Assert.AreEqual(a1, a2);

    // ToUnicode IDNA2003 should send "xn--tsst-loa" to "tässt"
    string u3 = IDNA.ToUnicode(a1, false, true, false);
    Assert.AreEqual(u2, u3);

  }

  [TestMethod()]
  public void Test040_EsZett_IDNA2008()
  {

    string u1 = "täßt";

    // Nameprep IDNA2208 should send "täßt" to "täßt"
    string u2 = Stringprep.NamePrep(u1, false, true);
    Assert.AreEqual(u1, u2);

    // ToAscii IDNA2008 should send "täßt" to "xn--tt-giat"
    string a1 = IDNA.ToASCII(u1, false, true, true);
    Assert.AreEqual("xn--tt-giat", a1);

    string a2 = IDNA.ToASCII(u2, false, true, true);
    Assert.AreEqual(a1, a2);

    // ToUnicode IDNA2003 should send "xn--tt-giat.de" to "täßt"
    string u3 = IDNA.ToUnicode(a1, false, true, true);
    Assert.AreEqual(u2, u3);

  }

Lokalisiert: Das kleine EsZett im World Wide Web

2010-10-31T14:36:51Z

Wie immer, wenn etwas immer größer und komplizierter wird, zeichnet sich ein Trend zur Lokalisierung ab. Das Internet ist ein topologischer Raum, der so hochdimensional geworden ist, dass man ihn nur noch als Überdeckung eines unfassbaren Etwas durch lokale Landkarten erklären kann. Das Kraftwerk der Globalisierung sehnt sich heute nach Semantik, sucht soziale Kontakte und organische Strukturen.Es möchte den Menschen nahe sein, ihre Gegend kennen und ihren Dialekt sprechen.

]]> Die alten globalen und normativen Lösungen werden verfeinert und den Bedürfnissen angepasst. Zum Beispiel der IDNA-Standard. Die Intention von IDNA ist es, Abbildungen zu definieren, die eine Kommunikation zwischen den unterschiedlichen und eigenartigen Informationsspektren beliebiger lokaler Entitäten auf der Basis uralter und schwer veränderbarer Protokolle wie dem DNS-System ermöglichen.

Im August 2010 veröffentlichte die IETF die IDNA2008-Spezifizierungen in RFC 5890 - 5894. Eine Übersicht über die Unterschiede zwischen IDNA2003 und IDNA2008 bietet der Unicode Technical Standard #46 (Unicode IDNA Compatibility Processing). Bis dahin war IDNA eine globale Funktion, im Wesentlichen bestehend aus dem Nameprep-Mapping und dem Punycode-Algorithmus, wobei Nameprep effektiv durch eine Reihe von Tabellen definiert ist, die z.B. Groß- auf Kleinbuchstaben und "ß" auf “ss” abbilden. Der alte Standard hatte damit die Verantwortlichkeit für die konsistente Behandlung unterschiedlicher Sprachen innhalb des IDNA-Protokolls angesiedelt. Diese Lösung war global, einfach und unflexibel.

Mit IDNA2008 wurde eine neue Terminolgie geschaffen, die den Anforderungen an die lokale Unterschiedlichkeit von Applikationen und Benutzern gerecht werden und die Offenheit gegenüber zukünftigen Unicode-Versionen garantieren soll. Das Eszett, namentlich der Codepoint U+00DF (LATIN SMALL LETTER SHARP S), wurde auf Betreiben von DENIC als Ausnahme in die Kategorie PVALID (Protocol Valid) aufgenommen. Während also die deutsche Ligatur ß in der DE-Zone nun mit xn--zca aufgelöst wird, kann es gleichzeitig in einer anderen Zone mit ss aufgelöst werden. Ein Beitrag zur Lokalisierung und zur Konjunktur bei ISPs und Anwälten.

Dieser Codepoint bildet nun eine Deviation, d.h. unterschiedliche Applikationen können ihn abweichend verarbeiten. Man stelle sich vor, Alice greift von zu Hause aus auf ihr Konto unter http://www.sparkasse-gießen.de zu. Ihr Browser unterstützt IDNA2003, bildet also auf http://www.sparkasse-giessen.de ab und löst auf die IP-Adresse des Sparkassenservers auf. Nun besucht sie ihren Freund Bob und prüft dort ihren Kontostand. Bobs Browser unterstützt IDNA2008, benutzt also bei gleicher Eingabe stattdessen http://www.xn—sparkasse-gieen-2ib.de, was auf eine ganz andere IP-Adresse aufgelöst werden kann. Unter dieser könnte der Phishing-Server von Eve antworten, die so die Zugangsdaten von Alice ausspionieren kann.

Und wenn schließlich der Browser am Encoding der Diskussionsbeiträge verzweifelt, so wirkt das irgendwie selbstreferenziell:

Ãh??? :-)

Für den ISP-Developer ist Lokalisierung allerdings stets eine Herausforderung. Er ist dafür zuständig, dass die lokalen Einheiten untereinander und miteinander kommunizieren können. Und wer will sich heute schon noch in ASCII unterhalten.

Das kleine "ß" landet also eines Tages auf dem Schreibtisch und erklärt sich für gültig. Natürlich weiß die an Hunderten von Stellen tief in alle Systeme eingegrabene IDNA-Software noch lange nichts von den neuen RFCs. Der .NET System.Globalization-Namespace, der bis dahin zuverlässige Dienste beim Normalisieren, Validieren und Konvertieren auch der absonderlichsten Zeichen leistete, ist unter keinen Umständen dazu zu bewegen, ein "ß" in Domain-Namen zu akzeptieren. Und was so eine DLL nicht kann, das kann sie eben nicht - tja, auf hoher See, vor Gericht und vor Microsoft …

Am 26. Oktober 2010 kündigte DENIC an, praktisch ab sofort IDNA2008 zu unterstützen und zunächst in einer Sunrise-Phase allen Inhabern von Domains, die ein “ss” enthalten, die Gelegenheit zu geben, das Pendant mit "ß" zu registrieren. Es musste innherhalb von wenigen Stunden eine Ad-hoc-Lösung her. Und das einzig Naheliegende war, eine automatische Abfrage des DENIC-Web-Tools zu programmieren, das in dem Moment den einzigen bekannten ß-fähigen Konvertierungsmechanismus bot. Unsere Auszubildende setzte das prompt um, während eilig RFCs studiert und nach einer tragfähigen Lösung gesucht wurde. Diese bietet die GNU IDN Library Libidn. Die kann zwar auch noch kein "ß", ist aber fix gepatcht. Der Code liegt in C, Java und C# vor, da ist also für jeden etwas dabei.

PostScript: the beauty of thinking backwards

2010-09-20T22:46:38Z

Lately, while snooping around within old coding stuff, I rediscovered an ancient treasure: the PostScript programming language. It's older than dirt and situated deep down under the bottom of Adobe's PDF technology. Intended to be an efficient and highly flexible printer instruction language, it's actually a Turing-complete programming language, based on a very clear and suprisingly simple stack-oriented concept, outputting geometric results to suitable devices.

]]> Everything is on a stack here. That is, operators reduce items on the operand stack, where operands are objects of various type. Thus, calculations are denoted in reverse polish notation:

3 1 sub 2 div                             % (3 - 1) / 2

or, equivalently, and even more polish ;)

2 3 1 sub exch div                        % (3 - 1) / 2

where exch exchanges the two topmost operands. PostScript procedures are executable arrays, i.e. objects consisting of a series of operators and operands, enclosed in braces:

{ 2 div } 3 1 sub exch exec               % (3 - 1) / 2

Executable objects may be executed at any time using the exec operator. Hence, functional concepts such as lambda expressions and lazy evaluation immediately suggest themselves. A complete script using certain font and graphic operators might look as follows:

%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: 0 0 170 50

% load standard font
24 /TimesBold findfont exch scalefont setfont
.25 setlinewidth
1 setgray                                 % white

gsave                                     % push graphic state
{                                         % push lambda expression
  gsave                                   % push graphic state
  (transformations) dup                   % duplicate string
  0 0 moveto show                         % print filled
  0 setgray                               % set black
  0 0 moveto true charpath stroke         % print outlined
  grestore                                % pop graphic state
} 
.6 .05 1.1 {                              % loop condition
  setgray                                 % using loop iterator
  .8 dup 13 dup translate scale           % matrix transformation
  -4 rotate
  dup exec                                % execute expression
} for                                     % loop operator
grestore                                  % pop graphic state
exec                                      % finally pop and execute

0 setgray                                 % black
[-1 0 0 1 150 30] concat                  % matrix transformation
(affine) 0 0 moveto show                  % print

showpage
%%EOF

Rendering is globally controlled by a transformation matrix, defining an affine transformation (i.e. a linear mapping plus translation) that can be modified either by the translate, scale, and rotate operators or by explicit left-sided matrix multiplication using the concat operator.

A named procedure in the usual manner is obtained as an executable literal that can be stored within the current dictionary. That is, the def operator is used to manage the symbol table:

/div2 { 2 div } def
3 1 sub div2                              % (3 - 1) / 2

Now, as an apprentice piece of recursive geometry, let's see how Koch's famous Snowflake works:

% t s koch => -
/koch {
  dup depth le {     % s < depth
    1 add exch % s => s+1
    3 div exch % t => t/3

    % prepare stack:
    % t/3 s+1 60 t/3 s+1 240 t/3 s+1 60 t/3 s+1
    60 3 copy 180 add 3 copy 180 sub 3 copy pop
    koch rotate koch rotate koch rotate koch
  } 
  { pop 0 rlineto }         % draw
  ifelse
} def

The koch function reduces a step and a length parameter from the stack, while depth is defined in the global dictionary. The decision of whether dive into recursion incrementing the step value or stop and draw a line segment is made by help of the ifelse operator. So,

/depth 5 def
newpath 0 0 moveto 100 1 koch stroke

displays the curve of length 100 with a recursion depth of 5.

For reference, see the PostScript Language Reference Manual, the Blue Book, and also Thinking In PostScript by Glenn Reid.

Perl module of the day

2010-08-12T23:34:49Z

Control where you go when you die() ...

]]>

#!/usr/bin/perl
use Religion;

$Die::Handler = new DieHandler  sub {
  die q/Goodbye, cruel world/;
};

__END__

Well, the Religion module will celebrate it's 15th birthday this year! *dance*

xn--bullshit is a valid IDN application

2010-07-06T16:54:36Z

Indeed, it is! Accidentally, while testing some random stuff against my IDN validation function, I found out that the word

bullshit

is the result of the Punycode Algorithm applied to the Unicode sequence

U+37F0 U+37E6 U+37F3 U+37EE U+37EC U+37E0.

These are 6 chinese characters from the CJK Unified Ideographs Extension A block. I've never seen before that Punycode results in any meaningful word and I think this is an extremely rare case. So I couldn't help myself to register both xn--bullshit.com and xn--bullshit.net immediately.

I've no idea what to do with it yet - we'll see :)

The discovery was announced on blog.http.net first.

Is LINQ functional?

2010-03-31T20:11:19Z

With it's 3.5 extensions, the .NET framework started to turn into a really cool looking programming concept, last but not least due to the syntactic sugar of LINQ. A reason for that is surely it's functional look. Well, as LINQ is integrated into an imperative context, it won't be ever able to guarantee state-free evaluation as a genuine functional language does. Nevertheless it's worth to discuss and play around with a few aspects of it in terms of a multiple programming paradigm concept.

]]> Delegating definitions in C# 3.0

Firstly, the concept of first-class functions, i.e. the invention of the function type, leads to the notion of closures. So for instance, a constant function such as

Func<int> i = () => 1;

defines something like a readonly variable. You may get it's value now, later or never, but you can always be sure that it's value won't be ever changed anywhere in your code. Hence, you have won a quantum of control over your program by this weird piece of code. That's a basic idea of functional programming.

The concept of function types leads to higher order functions, i.e. functions mapping functions to other functions. Thus, the curry functor, a key concept in the theory of functional programming, is regarded:

curry: (X x Y → Z) → (X → Y → Z)

That is, for any function f(x,y), there is a curryied function curry(f)(x) taking x to a function g(y) = f(x,y). This is now implemented easily in C# using generic types:

static Func<X, Func<Y, Z>> Curry<X, Y, Z>(Func<X, Y, Z> f)
{
  return x => y => f(x, y);
}

(inspired by this C# abuse of the day). Well, that's more or less of academic interest, since one would hardly ever replace x++ by

x = Curry<int, int, int>((a, b) => a + b)(1)(x); // x++ ;)

A slightly more interesting example is the following:

// using System.Text.RegularExpressions;
var grep = Curry<Regex, IEnumerable<string>, IEnumerable<string>>(
  (regex, list) => from s in list
                   where regex.Match(s).Success
                   select s);
var grepFoo = grep(new Regex("foo"));

Thus, grepFoo will grep all words containing "foo" from a wordlist. Attention should be paid to the fact that with the statement

var fooList = grepFoo(new string[]{"foo", "bar", "foobar"});

then there is still no regex applied. Indeed, fooList is of type IEnumerable<string> and not yet enumerated at this point. So the evaluation of the expression is deferred until it's result is needed by another computation - smells like lazy evaluation.

LINQ is not lazy!

One of the most important paradigms of functional programming is the concept of lazy evaluation. For instance, in a functional language, such as the good old Haskell, an expression such as

length [1, 2, 3/0]

evaluates to 3. That is, the control system is too lazy to fail on division by zero, neither at compile time nor on run time, since it doesn't need to know any element inside the array in order to calculate it's length. In C# (where you aren't even able to compile an expression such as 1/0), you may let

var q1 = from i in (IEnumerable<int>)new int[] { 1, 2, 3 }
         select 1/(i - 3);

without getting a run time error. But this has nothing to do with lazy evaluation, since the query expression isn't evaluated at all at this point (in contrast to the array definition inside the query), so the query expression is simply treated as a function definition. However, as soon as an aggregation expression such as

int three = q1.Count();

is reached, a DivideByZeroException will be thrown. Thus, LINQ evaluates eager here, not lazy. On the other hand,

int two = q1.Take(2).Count();

works fine, since the black hole stays unevaluated due to the Take operator. But, having

var q2 = from i in (IEnumerable<int>)new int[] { 1, 2, 3 }
         select 1/(i - 1);
int two2 = q2.Skip(1).Count();

instead, you will - guess what! - catch the exception again. Thus, in contrast to the Take operator, the Skip operator does iterate through skipped elements and hence evaluates them. Ok, that's no surprise, since these operators are using the IEnumerator provided by the corresponding IEnumerable. So, LINQ pretends to be lazy in the way that

var p = q2.Reverse();

won't be evaluated at this point and thus doesn't fail, wheras

int two3 = p.Take(2).Count();

then throws again the exception even though the evil one shuoldn't be taken here.

A functional approach to force lazyness would be to replace value expressions by constant functions, but the compiler won't accept something like this:

// The type of the expression in the select clause is incorrect.
// Type inference failed in the call to 'Select'.
var q1_ = from i in (IEnumerable<int>)new int[] { 1, 2, 3 }
          select () => 1 / (i - 3);

Hence, LINQ isn't lazy, but has a smart way to make function definitions looking like statement expressions.

Diving into recursion

Remember the famous

Fibonacci numbers:

fib₀ = 0, fib₁ = 1, fib_n = fib_n-1 + fib_n-2.

The sequence starts with

fibs = 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, ...

where fibs₁₀₀ is a number consisting of 21 digits then, so it grows quite fast. Although one may calculate Fibonacci numbers in constant time using Binet's formula, the definition leads to interesting comparisons of different recursion strategies.

Well, lets have a

delegate long Fibonacci(int n);

A direct translation of the definition into a lambda recursion looks like this:

Fibonacci fib1 = null; // pre-assigned for use within recursion
fib1 = n => n <= 1 ? n : fib1(n - 1) + fib1(n - 2);

The funny thing with this implementation is, that the Fibonacci function itself determines it's run time: It's O(fib_n), i.e. lower values will be recalculated many times again and again in order to get a higher one, due to the lack of an aggregating strategy.

Now, in Haskell you may get around this very elegantly by defining an infinitive list:

fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

The list is inititialized with two elements. Then, notional, the tail function shifts the first element from the fibs list, while zipWith (+) creates a new list by adding elements of both fibs and (tail fibs) with each other then. But in practice, Haskell is smart and lazy enough to avoid any needless recalculation of numbers already present in the fibs list. Thus, the algorithm applied here is the same one a human being would apply spontaneously using a pencil and a chit of paper. So, it's O(n).

To define an infinitive list in C#, one should implement the IEnumerable interface in the way that the corresponding IEnumerator expands the list on demand within it's MoveNext() method then. Here, it's enough to have a little inliner, taking a list and an expanding function to a Fibonacci type:

Func<
  IEnumerable<long>,
  Func<IEnumerable<long>, IEnumerable<long>>,
  Fibonacci> infList = null;
infList = (list, exp) => n => n < list.Count() ?
  list.Skip(n).First() : infList(exp(list), exp)(n);

Now, C# also provides a Zip function. So, a simple syntactic translation of the Haskell list would look like this:

Func<IEnumerable<long>, IEnumerable<long>> fibZip = fibs =>
  fibs.Take(2).Concat(fibs.Zip(fibs.Skip(1), (x, y) => x + y));

Hm, but this one is even worse than the naive recursion. Indeed, trying

Fibonacci fib2 = infList(new long[] { 0, 1 }, fibZip);

then, you will see that aggregation doesn't work at all this way, since the concept of enumeration is not functional. We may repair the fibZip as follows:

Func<IEnumerable<long>, IEnumerable<long>> fibZip2 = fibs =>
  fibs.Concat((IEnumerable<long>)(new long[] {
    fibs.Skip(fibs.Count() - 2).Sum() }));

This one looks a bit weird, since it's not that easy to extend an IEnumerable by one element. Anyway,

Fibonacci fib3 = infList(new long[] { 0, 1 }, fibZip2);

indeed does the job in O(n) then, even though the idea of an infinitive list has lost it's magic this way.

Conclusion

As expected, neither C# nor LINQ turns out to implement the paradigms of a functional language. None the less, it's really fancy. 8-)

getting rid of MT's permalink file extensions

2010-02-14T00:07:42Z

While designing scalable and portable web projects, it's always a good idea to design hyperlinks independently of the physical file path from where the respective request should be served then.

]]> For instance, I usually have permalinks looking like this one:

http://beta-blog.net/2010/02/getting-rid-of-mts-permalink-file-extensions

Thus I can decide later on whether I prefer to serve pages as html, shtml, php, or whatsoever - without losing the permanentness of my permalink Now, while I have choosen static publishing with HTML extension, MT creates a file such as

/var/www/beta-blog.net/2010/02/getting-rid-of-mts-permalink-file-extensions.html

so I can tell Apache how it should map my permalink to the physical file path using mod_rewrite:

# DocumentRoot /var/www/beta-blog.net
RewriteEngine on
RewriteBase /
RewriteRule ^([^\.]+[^\/])$ $1.html [L]

That is, any request path not containing a dot and not ending with a trailing slash will be rewritten to the according HTML file. (Yes, that way I won't be able to serve permalinks containing dots, but I can live with that ;)

Now that's nice, but unfortunately, within MT you are not able to configure the looks of permalinks inedpendently from the file path. Nobody wants to remove the extension from the actual file, since the same directory might contain some .js, .jpg and other files mapped to their own content types as well. (And I have no idea how to set up an AddHandler directive exclusively respecting files without extension.) Therefore, the solution is to let MT add the configured extension to the actual file, but remove the extension from the permalink.

A blessing in disguise, one has to hack MT's source code itself, but it's a quite simple change to the archive_url method within MT's Entry module. Thus, applying the following patch to lib/MT/Entry.pm will remove .php/.html extensions from archive links:

--- MTOS-5.01-en.orig/lib/MT/Entry.pm   2010-02-14 01:17:24.000000000 +0100
+++ MTOS-5.01-en/lib/MT/Entry.pm        2010-02-14 01:58:58.000000000 +0100
@@ -541,7 +541,11 @@
     my $blog = $entry->blog() || return;
     my $url = $blog->archive_url || "";
     $url .= '/' unless $url =~ m!/$!;
-    $url . $entry->archive_file(@_);
+    #$url . $entry->archive_file(@_);
+    ## --> HACK: remove .php/.html extensions <-- ##
+    my $f = $entry->archive_file(@_);
+    $f =~ s/\.(php|html)$//;
+    $url . $f;
 }

 sub permalink {

Well, thats really a dirty hack and things will get more complicated with dynamic publishing. So, hopefully one day MT's developers will implement a cleaner solution and make it configurable through the webinterface. *hack*

¡La Gomera!

2010-01-09T16:35:09Z

uno de esos lugares en donde se entiende: este planeta es el muy más hermoso del universo. 8-)

]]>

AutoSmileys:-) Plugin for Movable Type

2009-12-06T16:13:41Z

AutoSmileys is an easy to use and highly customizable macro environment for Movable Type. It will replace self-defined text abbreviations by image tags when your site is published or dynamically rendered, respectively. It may be applied either within entries, comments, pages, or any other part of your site.

]]> AutoSmileys works with both static and dynamic publishing and has been tested with MT 4.2, MT 4.3, and MT 5.0 beta (Perl 5.8.8 / PHP 5.2.9). (Dynamic publishing with AutoSmileys requires PHP5 in either case.)

Download

http://source.beta-blog.net/autosmileys/0.9/AutoSmileys-0.9.zip

Installation

Download AutoSmileys-0.9.zip, unzip it and copy the AutoSmileys directory from the zip file into the plugins directory of your Movable Type installation.
Sign in to your Movable Type CMS.
For each blog you wish to use AutoSmileys in, select Design > Templates from the menu and open the desired template for editing.
Within each of these templates, enclose the desired parts with the ... block tag.
Republish your site.

So for instance, if you wish to have AutoSmileys replacement on your entry main body, edit the Entry template as follows:

Anyway you may also put the whole HTML body inside the AutoSmileys tag. This would also apply AutoSmileys to comments, since the Comments module template is included into the Entry template.

For general installation instructions concerning Movable Type, see http://www.movabletype.org/documentation/installation/.

Configuration

Once you have installed AutoSmileys, sign in to your Movable Type CMS and open the Tools > Plugins page. Whithin the AutoSmileys 0.9 panel, expand the Settings tab. By default, it will look as follows:

On the top of the form you may define HTML tag names whose content will be ignored in order to avoid inappropriate image tag placement. The list beneath consists of text abbreviations (tokens) and associated image source URLs.

Default smileys are taken from freesmileys.org. *thx*

You may change these entries as you like and you may also expand or shorten the list by clicking on the [+] and [-] links on the right hand side (JavaScript required).

The list may be expanded with up to 40 rows by default. You may increase the related parameter maxRows by editing AutoSmileys.pl. *hack*

Remarks

Remember that MT tags are applied after any text filter you may have set up for entries or comments. Hence, text filters such as Textile and Markdown would replace stuff like *lol* before AutoSmileys has a chance to see it.

Also, note that tokens are recognized only in the way you have defined them after standard HTML entity replacement has been applied. That is, :-) will be displayed as :-) but not replaced.

How it works

The heart of AutoSmileys is a regular expression, dynamically created from the mappings of tokens to URLs defined as above. Once having these mappings collected within a Perl hash called %mappings, it's built as follows:

my $re_pattern = join '|',
  q/<(!)--(?:.|\n)*?-->/,          # markup comments
  q/<([^\s>]+)[^>]*?(\/)?\s*>/,    # markup tags
  map(quotemeta, keys %mappings);  # smileys

On a reasonably valid markup code this will replace any tokens outside markup tags, especially ignoring the content of specified tags inapplicable for containing image tags. Then,

s/($re_pattern)/&re_callback($1,$2,$3,$4)/eg;

does the job, using the following callback function:

my $expect;
sub re_callback
{
  my ($match, $comment, $tagname, $selfclosed) = @_;
  return $match if $comment || $selfclosed;
  if ( defined $tagname ) # non-self-closing markup tag
  {
    $tagname = lc $tagname; # ignore case
    if ( defined $expect )  # within ignorance state
    {
      undef $expect if $tagname eq $expect; # end ignorance state
      return $match;
    }
    $expect = qq</$tagname>
      if exists $ignoretags{$tagname}; # begin ignorance state
    return $match;
  }
  return $match if defined $expect || !(exists $mappings{$match});
  &{$Defaults->{image_tag}}($mappings{$match}, $match);
}

Here, $Defaults->{image_tag} is the actual image tag function. That's it 8-).

a wordlist folding algorithm

2009-11-28T23:33:32Z

Assumed you wish to match a large wordlist against a huge chunk of text. As a small test case, let

for, far, bar, foo, boofaz, boofar, boof, faz, foobaz, foobars, boofar

be your wordlist.

]]> Now, you may apply the according regualar expression:

(1) /\b(for|far|bar|foo|boofaz|boofar|boof|faz|foobaz|foobars|boofar)\b/

But which way a regex engine would implement the assignment? There are different options. The very worst algorithm would be surely to look up every word separately in the whole text. That would be the same as doing

foreach (qw( for far bar foo boofaz boofar boof faz foobaz foobars boofar ))
{
  return "matching!" if $text =~ m/\b$_\b/;
}
return "not matching.";

Assumed you would match m words against a text consisting of n letters, this peace of coding horror would have a runtime estimation of O(m*n).

Now, a better approach would be to run only once through the text, using a matching stack. Thus, assume " foobar " would appear somewhere in the text, the stack trace might look as follows then (read from bottom to top):

[7] ' ' => nothing matches.
[6] 'r' => "foobars" might match.
[5] 'a' => "foobaz" or "foobars" might match.
[4] 'b' => "foobaz" or "foobars" might match.
[3] 'o' => "foo", "foobaz", or "foobars" might match.
[2] 'o' => "for", "foo", "foobaz", or "foobars" might match.
[1] 'f' => "for", "far", "foo", "faz", "foobaz", or "foobars" might match.
[0] ' ' => "\b" matches.

So, but what if the wordlist is getting large? It seems that we should run nearly through the whole list each time a character is pushed onto the stack in order to find out whether the current stack contents still may be matched or not.

It's clear that a considerable optimization would be to sort the word list in advance. Moreover, instead of looking up one item after another, a really smart approach would be to walk downwards a search tree instead. As a tree, the wordlist above would appear like this:

          _____________|_____________
          |                         |
          b                         f
    ______|______        ___________|___________
    |           |        |                     |
   oof          ar       a                     o
    |                 ___|___            ______|______
    a ?               |     |            |           |
 ___|___              r     z            o           r
 |     |                                 |
 r     z                                 ba ?
                                     ____|____
                                     |       |
                                     rs      z

Here, the "?" denotes an optional node. Remember the length of the way downwards such a tree is in logarithmic relation to the number of nodes. Thus, loosely speeking, we have improved the worst algorithm above up to O(n*log(m)) at least.

Actually I'm not sure whether regex engines would apply optimizations like that when compiling. I guess they do, so it might be needless to replace the regex (1) above by the optimized version, implementing the sorted tree of alternative and optional nodes:

(2) /\b(b(?:ar|oof(?:a(?:r|z))?)|f(?:a(?:r|z)|o(?:o(?:ba(?:rs|z))?|r)))\b/

Nevertheless I couldn't help to create a little Perl routine that folds a wordlist into an optimized regex. Now, here it is:

sub foldWordsToRegex {

  local *toString = sub {
    ## node: [ prefix, [ nodes ], opt ]

    my ($prefix, $nodes, $opt) = ${$_[0]};
    my $rv = quotemeta $prefix;
    if ( ref $nodes eq q|ARRAY| && @$nodes )
    {
      $rv .= '(?:'.(join '|', map { toString($_) } @$nodes).')';
      $rv .= '?' if $opt;
    }
    $rv;
  };

  local *fold = sub(@_) {

    sub reduce($);
    local *reduce = sub {
      my ($prefix, $nodes, $opt) = ${$_[0]};

      return $_[0] unless ref $nodes eq q|ARRAY| && @$nodes > 1;

      ## 1st char of the prefix of 1st node in list
      my ($c, $qc);

      ## check whether 2nd prefix starts with same letter as the 1st
      if ( length $nodes->[0][0] )
      {
        $c = substr $nodes->[0][0], 0, 1;
        $qc = quotemeta $c;
        $nodes->[1][0] =~ m/^$qc/ or undef $c;
      }

      unless ( defined $c )
      {
        return $_[0] unless @$nodes > 2;

        ## try to reduce next list part
        my $first = shift @$nodes;
        my $next = reduce ['', $nodes, 0];
        return [ $prefix, [ $first, $next ], $opt] if length $next->[0];

        ## couldn't be reduced
        return [ $prefix, [ $first, ${$next->[1]} ], $opt ];
      }

      ## reduce any ensuing node whose prefix starts with $c
      my @new;
      my $newopt = 0;
      while ( @$nodes )
      {
        $nodes->[0][0] =~ s/^$qc// or last;

        ## reduce node or detect new optional node
        my $n = shift @$nodes;
        if ( length $n->[0] )
        {
          push @new, $n;
          next;
        }
        $newopt = 1;
      }

      if ( @$nodes || $opt )
      {
        my $new = reduce [ $c, [ @new ], $newopt ];
        if ( @$nodes )
        {
          ## reduce remaining nodes
          my $next = reduce ['', $nodes, 0];
          return [ $prefix, [ $new, $next ], $opt] if length $next->[0];

          ## couldn't be reduced
          return [ $prefix, [ $new, ${$next->[1]} ], $opt ];
        }

        ## current node is optional
        return [ $prefix, [ $new, @$nodes ], $opt ];
      }

      ## nothing left to reduce
      reduce [ $prefix.$c, [ @new ], $newopt ];
    };

    reduce [ '', [( map { [$_] } sort @_ )], 0];
  };

  toString(fold(@_));
};

Well, not so easy, but it works :)

Here, the inner recursion fold will create the actually tree, where nodes having the form of arrays consisting of prefix, subnodes and a flag denoting optional nodes. The second inner function toString then creates the actual regular expression string from that tree. So, for instance, calling

&foldWordsToRegex(qw( for far bar foo boofaz boofar boof faz foobaz foobars boofar ))

would return the regex (2).

understanding unicode surrogates / or: how to deal with Linear B strings in .NET

2009-11-17T20:23:58Z

Remember a String object in .NET is a collection of Char objects, where a Char object in turn is announced as a unicode character, encoded by a 16bit unsigned integer.

]]> Thus, more precisely speaking, a single Char object is able to encode any codepoint within the basic multilingual plane (BMP), i.e. between U+0000 and U+FFFF. So, where goes the rest of the story? Unicode, as an universal character set, is designed to support much more than 65536 characters of course.

Now, the trick is to encode code points above 2¹⁶ by so-called surrogates, that is, by pairs of 16bit integers. To see how this works, remember the well-known division algorithm for integers. That is, if you have an upper bound M and fix an integer constant C (0 < C < M), for any integer N within the range of 0 ≤ N < 2^M, there exists a unique pair of integers H,L, such that

N = 2^C * H + L, where 0 ≤ L < 2^C and 0 ≤ H < 2^{M - C}.

That way you have simply encoded these 2^M numbers N by 2^C * 2^{M - C} pairs of numbers H,L. Hence 2^M large numbers are adressed using a set of 2^C + 2^M-C small numbers, that's the trick.

As we are interested in encoding integers above 2¹⁶ by pairs of 16bit integers, we should act on the assumption

2¹⁶ ≤ N' < 2¹⁶ + 2^M,

dealing with N = N' - 2¹⁶ then. In order to decide whether any 16bit number does belong to a surrogate pair, playing either the role of H or L, finally fix an adequate constant T and set

H' = H + T, L' = L + T + 2^C,

thus having tagged all 16bit integers I achieving T ≤ I < T + 2^C + 2^M-C as surrogate integers, where the high surrogates of type H' are less than T + 2^C and the ones above are the low surrogates of type L'.

Now, the setting of unicode is this: C = 10, M = 20, T = 0xD800. So, by reserving 2048 small integers as surrogates, more than a million of additional codepoints up to U+10FFFF are accessible. The resulting formulars may be found here: http://www.unicode.org/book/ch03.pdf.

Thankfully .NET unicoders don't need to deal with hex numbers at all, because it's ready made. For instance, consider the name of Amnissos: written in Linear B:

In C# it looks like this:

// alternatively the Char.ConvertFromUtf32() method may be used
string amnisos = "\U00010000" + "\U00010016" + "\U0001001B" + "\U00010030";

Note that indeed the Length property of the resulting string has a value of 8, while it contains only 4 unicode characters. So the appropriate way of accessing the actual codepoints of an arbitrary string should make use of System.Globalization.TextElementEnumerator rather than simply access Char objects greenly. It goes like this:

// using System.Globalization;
TextElementEnumerator en = StringInfo.GetTextElementEnumerator(amnisos);
while (en.MoveNext())
{
  string current = en.GetTextElement();
  if (Char.IsSurrogate(current, 0))
  {
    // a surrogate pair encoding one character, i.e. current.Length == 2
    int codepoint = Char.ConvertToUtf32(current[0], current[1]);
    Console.WriteLine("U+{0:X6}", codepoint);
  }
  else
  {
    // characters within BMP:
    // current.Length > 1 may be true in case of combining characters 
    // cf. StringInfo.ParseCombiningCharacters()
    foreach (char c in current)
    {
      int codepoint = (int)current[0]; // use AscW() in VB.NET
      Console.WriteLine("U+{0:X4}", codepoint);
    }
  }
}

Now, when we will be able to register Linear B domain names at last? ;)

Fun with European domain names

2009-11-12T23:44:36Z

Starting 10 December 2009, companies and private persons based in the European Union will be able to register .eu Internationalised Domain Names. The list of supported characters is divided into several parts, called IDN scripts, such as "Latin-1 supplement", "Greek extended", "Cyrillic" and the like. Indeed, I may consider to get

http://www.β-ιστός-κούτσουρο.eu

Unfortunately, one cannot mix several scripts, thus β-blog.eu won’t be a valid name, since ASCII-letters belong to the Latin script while β is Greek. (Well, so, I think I’ll give up that idea ;))

To get serious, as an EURID registrar, it’s time for us to check out several issues that may apply to IDN requests built up with all that strange letters Europeans may use.

For instance, note that

a1.eu

and

а1.eu

are completely different domain names. But this is just an optical trick, since the first one starts with an ordinary ASCII "a" while the second starts with U+0430, wich is the unicode notation of the cyrillic small letter "a". Indeed, when you hit the second one into your browser, it will calculate the according ACE-string xn—1-7sb.eu using the punycode algorithm first and will make up the DNS request with it.

Things are getting more complicated when you notice that

aŀt.eu

on the one hand, and

al·t.eu

on the other hand indeed are the same domain name. Applying the punycode algorithm to both of them, you will get

xn--at-rqa.eu

for the first one and

xn--alt-mga.eu

for the second one, because both byte streams differ. Now, something goes wrong here, since when you plan to ask a nameserver for the IP address to access the domain, you will have to decide for wich one you ask. Unlikely a nameserver will answer to both of them.

Well, according to the IDNA standard as defined in rfc3490, applications not only have to do a punycode for IDNs, but also have to apply the nameprep algorithm first, wich in turn consists of several normalization mappings such as lower case conversion and, more interesting, also the Unicode Normalization Form KC (see http://unicode.org/reports/tr15/). The latter is the decomposing of characters by unicode compatibility equivalence. Thus, the character U+0140, the Latin small letter "l" with middle dot, decomposes into two unicode characters:

U+0140 => U+006C + U+00B7

That is, the middle dot will be aparted from the letter "l". Therefore, xn—at-rqa.eu is an application of punycode, but not a conversion in the sense of IDNA standard. Indeed, you will get different results from different so-called IDN converter libraries with that domain, depending on whether they ara just doing punycode or applying a proper nameprep first. A reliable reference is the Verisign conversion tool (http://mct.verisign-grs.com/index.shtml) and the according SDK for example (although I wasn’t able to get the Win32 version working).

After all, the challenge for the registrar is to maintain the request database properly, accepting IDN requests in both the normalized and any equivalent form. And moreover, one has to check a requested name against the given character list wich contains non-normalized letters, even if the requested name is normalized already. Since normalization isn’t a reversible mapping this may be complicated in general, but should be solvable in this case.

no sleep till DENIC

2009-10-25T08:10:52Z

Chronologie eines außergewöhnlichen Programmierwettbewerbs

Donnerstag, 15.10.2009, 16:14 Uhr

Ein unspektakulärer Arbeitstag neigt sich dem Ende zu. Im Posteingang erscheint eine Verlautbarung der DENIC-Mitgliederliste. Von einem BGH-Urteil ist die Rede, von neuen Domainrichtlinien. Da per Gerichtsbeschluss die Registrierung der Domain vw.de angeordnet worden sei, sollen auch vergleichbare Domainnamen freigegeben werden, die bisher nicht zugelassen waren: ein- und zweistellige Domains, Zifferndomains, sowie existierende Toplevel-Domains und deutsche Autokennzeichen.

Das bedeutet: keine Beschränkungen mehr, abgesehen von der Maximallänge und dem zugelassenen Zeichensatz, sowie der international üblichen Regel, dass Domainnamen nicht mit einem Minus beginnen oder enden dürfen.

Es ist klar, dass unter diesen Namen nicht wenige sind, die man mit fünf- bis sechsstelligen Beträgen handeln werden wird.

Im dritten Absatz offenbart sich dann die eigentliche Brisanz dieser Nachricht. Man muss zweimal hinschauen: Die Registrierung der neuen Domains ist ab "25.10.2009 9:00 Uhr (MESZ)" freigegeben. First come – first served.

Prompte Nachfrage eines Mitgliedes: Der 25.10. sei ein Sonntag und außerdem der Tag, an dem um 3:00 Uhr von MESZ auf MEZ umgechaltet wird, ob das bekannt sei? Und ob wirklich MESZ gemein sei?

Donnerstag, 15.10.2009, 16:43 Uhr

Achja, es wird offiziell korrigiert: Starttermin ist Freitag, der 23.10.2009, 9:00 MESZ. Das ist in einer Woche.

Währenddessen: der Geschäftsführer erscheint zur spontanen Krisensitzung im Entwickler-Büro. Wir müssen sehr schnell zwei Dinge gleichzeitig tun:

Einen Landrush für unsere Kunden vorbereiten, damit sie ihre Bestellungen vormerken können.
Unsere Teilnahme an der Vergabe am 23.10. vorbereiten.

Schon während des Gesprächs wird ein Webformular für die Kunden aufgesetzt, zum Vormerken der gewünschten Domainnamen. Auch hier gilt: First come – first served. Wir einigen uns auf Freischaltung zum Dienstag, 20.10.2009, 12:00 Uhr MESZ. Ein Eil-Newsletter ist zu formulieren. Alle anderen Projekte sind zurückzustellen.

Freitag, 16.10.2009, 14:43 Uhr

Eine erste interne Testversion für das Vormerk-Formular und die zugehörige Datenbankstruktur ist fertig. Es soll ab Montag für die Kunden sichtbar sein.

Währenddessen erfolgen erste Entwicklungsschritte für die Teilnahme am DENIC-Landrush. Die Registrierung soll per SMTP via PGP-signierter E-Mails im MRIv2-Format erfolgen. Wir benutzen schon lange nicht mehr die SMTP-Schnittstelle der DENIC, sondern die Echtzeitschnittstelle RRI (XML per dediziertes TCP-Protokoll). Es gilt also zunächst, MRIv2 zu lernen. Die technische Dokumentation wird studiert: Wie müssen die Antrags-Mails genau aussehen?

Freitag, 16.10.2009, ca. 16:00 Uhr

Die ersten MRIv2-Mails werden erfolgreich abgesetzt und verarbeitet, zunächst einfach Updates für bestehende Test-Domains. Unser PGP-Key funktioniert, man muss aber bei IDN-Domains mit dem Encoding aufpassen.

Wir werden alle Vormerkungen mit festen Kontakt-Handles und einer festen Delegation auf DENIC-Nameserver absetzen um überflüssige Probleme zu vermeiden. Erfolgreiche Registrierungen können später auf die gewünschten Eintragungen geändert werden. Also ist wenigstens schon mal klar, wie die Anträge genau auszusehen haben.

Währenddessen ist eine heiße Diskussion auf der Mitgliederliste entbrannt. Wieso, das BGH-Urteil sei doch schon 29.09.2009 gefällt worden? Achso, es war dem BGH-Anwalt der DENIC am 15.10.2009 offiziell mitgeteilt worden.

Die technische Dokumentation zum geplanten Landrush wird nun beinahe beinahe stündlich geändert. Allseits herrscht Verwirrung. Wo soll man hinsenden? Was ist mit einer Test-Umgebung? Wie ist die zu erreichen und ab wann? Und wie genau ist die Policy für das Einliefern der Mails nun überhaupt zu verstehen? Eine dedizierte IP-Adresse pro Mitglied und dann maximal 4 Mails pro Minute. Aber was heißt das genau?

Montag, 19.10.2009, 10:00 Uhr

Unsere dedizierte IP-Adresse für die Teilnahme am Landrush wird angemeldet. Damit können wir am Testbetrieb teilnehmen.

Auf der Mailingliste toben mittlerweile erbitterte Auseinandersetzungen und verwirrte Nachfragen. Gleichzeitig werden allenthalben juristische Schritte angedroht, befürchtete Übervorteilungen angeprangert und Details des SMTP-Protokolls diskutiert.

Montag, 19.10.2009, ab 16:00 Uhr

In der Dokumentation wird verwirrenderweise explizit auf die Möglichkeit des SMTP-Pipelinings hingewiesen, obwohl das doch allenfalls dazu dienen kann, die selbe Mail an verschiedene Empfänger in einem Bulk abzusenden? Das ist hier sinnlos, denn man müsste stattdessen verschiedene Mails möglichst schnell an den selben Empfänger absenden. Tatsächlich ergeben erste Tests, dass man scheinbar nichteinmal mehrere Mails innerhalb der selben TCP-Connection absetzen kann:

"421 too many messages in this connection"

Insgesamt ist unklar, wie genau die ACL funktioniert. Teilweise kann man mehr als 4 Mails pro Minute absetzen, dann auch wieder weniger, möglicherweise je nachdem wie viele Versuche man unternimmt. Eine diesbezüglich Anfrage an den DENIC-Support wartet vergebens auf Antwort.

Dienstag, 20.10.2009, 10:00 Uhr

Unser Vormerk-Formular wird einem firmeninternen Landrush-Test unterzogen. Keine technischen Probleme.

Dienstag, 20.10.2009, 12:00 Uhr

Unser Vormerk-Formular wird für die Kunden freigeschaltet. Innerhalb weniger Sekunden gehen ca. 25.000 Anfragen ein, während wir ängstlich beobachten, wie die CPU des Webservers an der Decke klebt. Nach einigen Minuten beruhigt sich die Lage. Wir haben zunächst ungeprüft alles angenommen, um nur ja nicht berechtigte Anfragen fälschlicherweise abzulehnen. Das wäre im Nachhinein nicht mehr gut zu machen, da die Reihenfolge dann nicht mehr klar wäre.

Nach Bereinigung von Dopplern und ungültigen Domainnamen bleiben ca. 2500 Vormerkungen übrig.

Dienstag, 20.10.2009, 13:39 Uhr

Offenbar ist sich DENIC selbst noch nicht völlig im Klaren darüber, was genau mit 4 Mails pro Minute gemeint sein soll:

"[...] Derzeit arbeiten wir an der Optimierung der Mail-ACL. Bitte beachtet, dass es dadurch zu Anpassungen kommen kann, die Ihr zeitnah berücksichtigen müsst. [...]"

Unabhängig von der ACL ist jedenfalls klar, dass es im zu implementierenden Algorithmus für unser Landrush-Tool vor allem auf zwei Dinge ankommt:

Möglichst exakte Startzeit (welcher Zeitpunkt innerhalb des SMTP-Dialogs zählt?)
Während des Laufs möglichst wenig Domains zu beantragen, deren Nichtverfügbarkeit bereits ermittelt werden kann.

Wir lassen also zwei Threads parallel laufen, einen der versucht, die Mails aus der Queue (nach welcher Strategie auch immer) abzusenden, und einen, der parallel durch vorausschauendes Prüfen der Verfügbarkeit erfolglose Anträge markiert.

Dienstag, 20.10.2009, 19:42 Uhr

DENIC gibt erstmals exakte Informationen über die Realisierung der ACL bekannt. Insbesondere wurde der Algorithmus vom bisher verwedeten "Sliding-window Verfahren", das auf in undurchsichtiger Weise aufgrund extrapolierter Sendegeschwindigkeit berechneten Zeitfenstern beruhte, umgestellt auf das sog. "Rate-limiting Verfahren nach dem Token-bucket Algorithmus". Demnach sollen tatsächlich immer maximal 4 Mails pro echter Zeitminute angenommen werden, unabhängig von der Anzahl der Sendeversuche.

Mittwoch, 21.10.2009, 08:00 Uhr

Eigentlich wollten wir heute zum technischen Meeting der DENIC nach Frankfurt fliegen. Zwei Flüge waren lange gebucht und werden nun verfallen. Keine Zeit für Meetings.

Mittwoch, 21.10.2009, 08:55 Uhr

Wir nehmen erstmals an einem Massentest teil. Wie im geplanten Livebetrieb wird der Mailserver bereits um 08:55 gestartet, und Mails vor 09:00 Uhr werden zunächst angenommen und dann mit einer entsprechenden Fehlermeldung beantwortet.

Diese Vorgehensweise ist für den Landrush-Programmierer angenehmer als die sonst häufig angewandte Methode, erst ab Startzeit Connections zu akzeptieren, da man hierbei leicht in einen Timeout zur Startzeit schlittern kann und sich dieses Verhalten außerdem nur schwer simulieren lässt. Überhaupt hat dieser Landrush mehr etwas von einem raffinierten Strategie-Spiel als die sonst üblichen Massensprints, wo es gilt, parallel mit maximal vielen Connections auf den Server einzuprügeln.

Mittwoch, 21.10.2009, 09:00 Uhr

Überraschend am Massentest gegenüber dem üblichen Testbetrieb ist zunächst, dass der Mailserver offenbar vor dem Ansturm von weniger als 300 Mitgliedern mit je einer Connection ziemlich in die Knie geht. Die 4-Mails/Minute-Policy stellt sich als Farce heraus, da sich die SMTP-Dialoge dermaßen schleppend hinziehen, dass einzelne Mails schon 20-30 Sekunden brauchen. Auffallend ist außerdem, dass wiederholt Connections abgelehnt werden:

"421 Too many concurrent SMTP connections from this IP address",

Obwohl die vorherige Connection durchaus geschlossen und auch die Schließung durch den Server bestätigt worden war.

Mittwoch, 21.10.2009, 10:08 Uhr

Die ersten Antwortmails des Registrierungssystems treffen nach knapp einer Stunde ein. Mitglieder berichten von unerwarteten Antworten wie etwa

"ERROR: 56000000013 Technical error"

und anderen sonderbaren Phänomenen. Die Datenbank scheint auch vor dem Test nicht oder nur teilweise zurückgesetzt worden zu sein. Irgendwas scheint da gehörig gegen die Wand zu laufen.

Mittwoch, 21.10.2009, 10:08 Uhr

DENIC kündigt einen weitereren Massentest für 15:00 Uhr an.

Mittwoch, 21.10.2009, ab 11:00 Uhr

In diesem Test haben wir keine einzige interessante Domain abbekommen. Wir werden die Zeit bis zum Nachmittag nutzen, um den zweiten Thread zur Prüfung der Verfügbarkeit hinzuzufügen.

Die Verfügbarkeit von Domains ermitteln wir per RRI-Abfrage. Das scheint etwas effizienter und zuverlässiger als whois zu sein. Bei noch verfügbaren Domains, die nicht den bisherigen DENIC-Richtlinien entsprechen, antwortet DENIC mit einem Fehler bzgl. des Domainnamens:

Invalid format of value for keyword "Domain"

Somit interpretieren wir jede Antwort, die nicht besagt, dass die Domain vergeben ist, als "verfügbar".

Mit Hilfe einer speziellen Test-Tabelle, die zufällig verteilt einerseits die ein- und zweistelligen, und andererseits garantiert verfügbare Nummerndomains enthält, lässt sich der Parallelbetrieb von Abfragen und Senden auch außerhalb der Massentests testen, da somit eine gemischte Queue von vergebenen und freien Domains zur Verfügung steht. Unser Abfrage-Thread sucht vor jedem Sende-Intervall vier freie Domains aus der Liste, und zwar möglichst knapp vor dem Sendefenster, um eine möglichst hohe Zuverlässigkeit des Ergebnisses zu gewährleisten. Fraglich bleibt natürlich, wie aktuell die Antwort überhaupt ist.

Mittwoch, 21.10.2009, 15:00 Uhr

Startschuss Massentest, die Zweite. Wir sind jetzt gut aufgestellt. Da für den Eingangszeitstempel der Abschluß des DATA-Commands entscheidend ist, sollte der erste SMTP-Dialog vor der eigentlichen Startzeit begonnen werden. Unklar ist allerdings, welcher Zeitpunkt zwischen dem Senden des abschließenden "." am Ende des DATA-Commands und der Antwort des Servers am Ende zählt, zumal diese Zeitspanne ungewöhnlich groß ausfällt. Hier sind es ganze 6 Sekunden und wir bekommen das abschließende "250 OK" gut 5 Sekunden nach 15:00 Uhr, das ist vermutlich viel zu spät, um eine Chance auf die ersten Namen zu haben.

Mittwoch, 21.10.2009, 15:08 Uhr

Umso erstaunlicher, dass die ersten Mails mit "Too early" beantwortet werden, das heißt, sie sind beim Server vor 15:00 Uhr angekommen?

Dann kommt noch ein "Too early" und noch eins. Entsprechende Proteste auf der Mailingliste machen schnell klar: Der Test ist serverseitig fehlgeschlagen, alles wird mit "Too early" beantwortet.

Mittwoch, 21.10.2009, 15:41 Uhr

DENIC entschuldigt sich: Der Startschuss war versehentlich in den November verlegt worden. Ein erneuter Massentest wird für 16:00 Uhr angekündigt.

Mittwoch, 21.10.2009, 16:00 Uhr

Startschuss Massentest, die Dritte. Diesmal kommen zwar keine "Too early"-Antworten, dafür werden aber fortwährend Verbindung abgwiesen:

421 Too many concurrent SMTP connections from this IP address; please try again later.

Das ist merkwürdig, da wir definitiv für jede Mail eine eigene Connection öffnen und schließen. Es dauert dann jeweils bis zu einer Sekunde, bis eine neue Verbindung hergestellt werden kann. Es scheinen sich serverseitig verschiedene Dienste zeitweilig uneins über das Bestehen einer Connection zu sein.

Fazit: das Verhalten des Servers ist ausgesprochen indeterministisch und man hat den Eindruck, dass sich das Registrierungssystem durchaus in einer eher frühen Entwicklungsphase befindet und die Tests nicht nur der Entwicklung der Clients, sondern auch des Servers dienen.

Die wichtigste Beobachtung ist aber, dass wir immernoch zu viele Mails vergebens absenden, da die Verfügbarkeitsprüfung während der Massentests erheblich langsamer voran kommt als im Normalbetrieb. Unsere Prüfschleife sucht sich aus der Queue stets die 4 nächsten freien Domains heraus, wofür im Normalbetrieb etwa 4 Sekunden, unter Massentestbedingungen aber bis zu 20 Sekunden nötig sind.

Mittwoch, 21.10.2009, 19:06 Uhr

DENIC kündigt für den morgigen Tag nun doch noch zwei weitere Masentests an, um 9:00 Uhr und um 13:00 Uhr.

Dieser Abend wird genutzt, um die Strategie der Verfügbarkeitsabfrage zu verbessern. Wir werden nicht mehr, wie bisher, ab einem bestimmten Zeitpunkt vor Beginn des nächsten Sendefensters nach 4 freien Domains suchen, sondern den Thread praktisch pausenlos immer wieder von vorne nach freien Domains suchen lassen. Damit werden die als nächstes anstehenden Domains zwar immer wieder erneut geprüft, aber das Prüfintervall bleibt dabei unabhängig von dem praktisch unkalkulierbaren Sendefenster.

Die zweite Baustelle ist der exakte Startzeitpunkt. Eigentlich müsste man, um den extrem zeitkritischen Start optimal abzupassen, den SMTP-Dialog direkt programmieren, so dass man mit der ersten Mail hinreichend früh beginnt und das abschließende "." am Ende des DATA-Commands bis zur exakten Startzeit hinauszögern kann. Dafür ist aber die Zeit zu knapp, und die von uns benutzte SMTP-Library unterstützt natürlich nicht ein so spezielles Timing.

Der Arbeitstag dauert heute bis 23:00 Uhr und wird morgen um 8:00 Uhr beginnen.

Donnerstag, 22.10.2009, 08:00 Uhr

Vorbereitung auf den heutigen ersten Massentest. Auf der Mitgliederliste werden weiterhin Detailfragen des ACL diskutiert und von einigen eine Verschiebung des Registrierungstermins gefordert.

Donnerstag, 22.10.2009, ab 09:00 Uhr

Der Massentest startet. Der SMTP-Server scheint nun noch langsamer als gestern zu reagieren. Außerdem wird ungefähr jede 3. Mail mit "Too many concurrent SMTP connections" abgelehnt. Beim Beobachten des Logfiles ist man im Grunde froh, überhaupt einige Mails einliefern zu können.

Donnerstag, 22.10.2009, 09:56 Uhr

DENIC räumt ein, dass das Problem der abgwiesenen Connections reproduzierbar ist:

"[...] Unsere Tests haben ergeben, dass der entsprechende Prozess zum Beenden der Connection unter Last länger dauert als gewohnt. Nach Aussen wird die Connection zwar als geschlossen bestätigt - der Mailserver ist aber tatsächlich noch beim schliessen. [...]" [sic]

Man soll es eben dann immer wieder neu versuchen, bis man wieder eine Connection bekommt.

Donnerstag, 22.10.2009, 10:10 Uhr

DENIC gibt Messergebnisse zum Massentest bekannt. Es wurden von insgesamt 156 verschiedenen IP-Adressen aus pro Minute bis zu 3422 Versuche zur Mailannahme registriert. Wenn von jeder IP nur 4 Mails pro Minute eingeliefert würden, käme man nur auf 624.

Natürlich versucht wohl niemand mehr, nur noch 4 Mails pro Minute abzusetzen, nachdem man gemerkt hat, dass einerseits außerhalb der Masentests teilweise durchaus auch mal 5 oder 6 Mails in einer Minute angenommen werden und andererseits das Einliefern einer einzigen Mail während der Massentests bis zu 20 Sekunden dauern kann.

In Anbetracht dessen, dass der für 13:00 Uhr angekündigte Test voraussichtlich der letzte sein wird, lässt die Ankündigung, das Serversystem "weiter zu optimieren" auf nichts Gutes hoffen. Man wird sich womöglich erneut auf ein verändertes Verhalten des Servers einstellen müssen, ohne weitere Gelegenheit zum Testen zu haben. Um 15:00 Uhr soll das Testsystem dann ganz abgeschaltet werden. Aber niemand will Änderungen implementieren, die man nicht mehr testen kann.

Donnerstag, 22.10.2009, 12:51 Uhr

DENIC lässt ein neues Statement zum 4-Mails/Minute-ACL verlauten:

"[...] hochgezählt wird zu dem Zeitpunkt, wenn der Envelope der Mail geschrieben wurde."

Leider können ja offenbar mehrere Sekunden zwischen Abschluss des DATA-Commands und der folgenden Bestätigung "250 OK" vergehen. Wann innerhalb dieser Zeitspanne nun der Envelope geschrieben wird, ist für den Client nicht feststellbar. Ein exaktes Timing bzgl. des ACL ist somit schlichtweg unmöglich. Man muss hintereinander versuchen, Mails loszuwerden, egal ob zwischendurch Connections abgewiesen werden oder die Einlieferung per ACL abgelehnt wird, anders geht es nicht.

Donnerstag, 22.10.2009, 13:00 Uhr

Der letzte Massentest startet. Wir haben unsere Startzeit diesmal um 2 Sekunden zurückgesetzt, um den richtigen Startzeitpunkt wenigstens ungefähr auszuloten. Sollte der erste Antrag mit "Too early" beantwortet werden, so werden wir auf den vorherigen Wert zurückschwenken.

Es wird sofort klar: Diesmal kommt überhaupt keine Connection zustande. Der Server meldet kein Banner, offenbar werden alle Connections bereits firewallseitig abgelehnt.

Donnerstag, 22.10.2009, 13:06 Uhr

Der Abbruch des Massentests wegen Netzwerkproblemen wird bekanntgegeben. Ein neuer Test wird für 14:00 Uhr anberaumt.

Donnerstag, 22.10.2009, 13:48 Uhr

Der für 14:00 Uhr geplante Massentest wird wegen der noch bestehenden Netzwerkproblematik abgesagt.

Donnerstag, 22.10.2009, 14:42 Uhr

DENIC meldet, dass ein Versuch, das Problem der abgelehnten Connections zu umgehen, gescheitert ist. Es wird auf die bei den vorangegangen Tests benutzte Konfiguration zurückgegriffen. Nun sollen noch zwei Massentests um 15:30 Uhr und um 16:30 Uhr stattfinden.

Donnerstag, 22.10.2009, 15:26 Uhr

DENIC gibt bekannt, dass der Test um 15:30 Uhr nicht starten kann, weil zusätzlich Zeit für das Zurückgehen auf die frühere Lösung benötigt wird. Über den neuen Zeitplan soll zeitnah informiert werden.

Donnerstag, 22.10.2009, 15:55 Uhr

DENIC gibt den weiteren Zeitplan bekannt: Neue Massentests um 16:30 Uhr und um 17:00 Uhr. Abschaltung der Testumgebung um 17:30 Uhr.

Donnerstag, 22.10.2009, 16:33 Uhr

Der nächste Versuch ist gestartet. Das Einliefern der Mails funktioniert jetzt wieder, dauert aber teilweise über 30 Sekunden. Wir brechen nach kurzer Zeit ab, um unsere Testumgebung für den letzten Test um 17:00 Uhr rechtzeitig zurücksetzen zu können.

Donnerstag, 22.10.2009, 17:00 Uhr

Der letzte Test ist gestartet. Wir haben nun den Startzeitpunkt so weit zurückgesetzt, dass mehrere Anträge mit "Too early" beantwortet werden, woraus sich nun ungefähr der bestmögliche Startzeitpunkt erraten lassen sollte.

Freitag, 23.10.2009, 08:00 Uhr

Noch eine Stunde bis zum Start. Unser Tool wird auf Livebetrieb umgestellt. Es kommt jetzt nur noch darauf an, vor Aufregung ja keine Einstellung zu übersehen. Es muss die richtige Startzeit eingestellt sein, die richtige Datenbank geladen und der richtige Server angesprochen werden.

Mit Hilfe eines vorbereiteten Tools werden für die anstehenden Aufträge die PGP-signierten Auftragsmails generiert, die später abgesendet werden müssen.

Freitag, 23.10.2009, 08:30 Uhr

DENIC meldet, dass die Domains e.de, f.de, g.de, x.de, y.de, z.de, br.de, dw.de, hr.de und sr.de aufgrund kurzfristig zugestellter einstweiliger Verfügungen von der Registrierung ausgenommen sind. Gerade noch früh genug, um diese Aufträge in der Datenbank als gesperrt zu markieren.

Freitag, 23.10.2009, 08:38 Uhr

DENIC gibt bekannt, dass nicht nur vw.de, sondern auch o2.de aufgrund von Gerichtsentscheidungen bereits registriert wurden.

Freitag, 23.10.2009, 08:55 Uhr

Letzte Prüfung der Checkliste. Die Konfiguration ist auf den Livebetrieb umgestellt. Die automatische Synchronisierung mit fremden Zeitgebern ist angehalten, damit die Systemzeit ausschließlich durch den NTP-Server der DENIC synchronisiert wird. Der Domain-Robot, sowie alle Dienste, die gewöhnlich RRI-Connections mit DENIC aufbauen, sind angehalten, denn nur nur eine einzige RRI-Connection ist zugelassen.

Freitag, 23.10.2009, 08:57 Uhr

Unser Tool wird gestartet. Es lädt sich den Inhalt der Datenbanktabelle in den RAM, baut die TCP-Connection zum Mailserver auf und wartet von da an auf den Startzeitpunkt.

Das Rauchverbot im Entwicklerbüro wird vorübergehend aufgehoben.

Freitag, 23.10.2009, 08:59 Uhr

Gespannt wird der Beginn des ersten SMTP-Dialogs auf der Konsole mitgelesen. Die Einleitung des DATA-Blocks erfolgt eine halbe Sekunde vor 9:00 Uhr:

2009-10-23 08:59:59,449 >> RCPT TO:
2009-10-23 08:59:59,459 << 250 Accepted
2009-10-23 08:59:59,479 >> DATA
2009-10-23 08:59:59,520 << 354 Enter message, ending with "." on a line by itself

Freitag, 23.10.2009, 09:00 Uhr

Es dauert 6 Sekunden bis zur Bestätigung des ersten DATA-Blocks. Mit der ersten Domain werden wir somit wohl kaum durchkommen, aber wären wir früher gestartet, hätten wir genausogut leicht in das "Too early" laufen können. Ein Glücksspiel, wie so oft im Leben dann leider doch mal wieder ohne Hauptgewinn.

Alles Weitere ist ein Automatismus. Zäh wird Auftrag um Auftrag abgesetzt, während 30 Sekunden nach 9 Uhr planmäßig der zweite Thread startet, um parallel die nächsten Domains auf Verfügbarkeit hin zu prüfen.

Die Unwägbarkeiten bei diesem Rennen sind groß. Beispielsweise bleibt unser Antrag auf die Domain 1.de, den wir um 09:00:42 absetzen, erfolglos, obgleich um 09:00:38 noch die Verfügbarkeit dieser Domain bestätigt wurde. Wieviel Zeit zwischen dem Entgegennehmen eines Auftrags und der eigentlichen Registrierung einer Domain mitsamt Anzeige im RRI auf DENIC-Seite vergeht, weiß niemand.

Freitag, 23.10.2009, 09:02 Uhr

Wie man später erfahren wird, sind zu diesem Zeitpunkt bereits 85 Domains registriert, d.h. das eigentliche Rennen um die wichtigen Namen ist so gut wie gelaufen. Dennoch werden noch alle Domains als verfügbar angezeigt. Erstmals um 09:02:34 wird eine Domain mit Status "connect" angegeben.

Das Rennen um die hinteren Plätze wird noch den ganzen Tag über andauern. Unter dem Strich sind wir zu 8% mit unseren Aufträgen erfolgreich. Das ist keine so schlechte Quote. Andere Mitglieder waren dadurch erfolgreicher, dass sie sich zu Pools zusammengeschlossen und ihre Listen untereinander optimiert haben. Davon abgesehen waren die Bedingungen für alle Mitglieder im Wesentlichen gleich schwierig.

Die Gewinner der ganzen Veranstaltung sind ohnehin Sedo und vor allem die Rechtsanwälte, die nun in ihr eigenes Rennen einsteigen können. Noch im Laufe des Tages wird z.B. bekannt, dass in einem kleinen Haus mit vielen Briefkästen irgendwo in Florida plötzlich erstaunlich viele Firmen mit ein- und zweistelligen Initialen gegründet wurden. Und andere Geschichten.

Unser Rennen haben wir gewonnen, denn wir haben aus den Gegebenheiten das Bestmögliche gemacht. Alles Weitere wäre Glück gewesen.

Kalkulator kolorów DHTML

2009-10-17T13:44:37Z

wow, the one and only legendary good old DHTML Color Calculator has been translated into Polish :-)

]]>

Actually I’m not able to understand the Pomocnic webmastera site, but it’s a great honor anyway.

Well, indeed I’ve to set up a new and more contemporary online color calculator soon. This one was my first web try out then in 2001, compatible with Netscape 4 and IE5, lol.

shorten by regex

2009-10-15T20:35:50Z

While customizing my mt blog, I was wondering how to abbreviate long entry titles on particular places in a nice way. Well, mt provides template tag modifiers such as trim-to, but my aim was to do it more nicely, i.e. replacing anything behind the first three (or any other maximum) words by an ellipsis. For instance,

"more than three words"

should be shortened to

"more than three ..."

while a three-word-sentence should remain as it is.

The solution is a simple regex, of course. In Perl style,

s/ˆ(\S+(?:\s+\S+){2})(\s+\S+)+/$1 .../

does the job, because it doesn't match on three words or less. Equivalently, within mt template tags:

<$mt:EntryTitle regex_replace="/ˆ(\S+(?:\s+\S+){2})(\s+\S+)+/","$1 …"$>