Zusammenfassung

  • RFC 2422 machte die Byte-Anordnung zum Bestandteil des Vertrags von audio/32KADPCM: Das frühere Codewort kommt in das untere, sein Partner in das obere Nibble.
  • Bei einer ungeraden Zahl von Codewörtern empfiehlt der RFC, Stille anzuhängen; andernfalls wird das letzte Codewort verworfen. Die Regel klärt die Interpretation, nicht die Zustellung oder das Anhören einer Nachricht.

Der Codec hatte seine mathematische Arbeit bereits erledigt. Die ITU-T-Empfehlung G.726 beschrieb adaptive Differenz-Pulscodemodulation und die Umwandlung zwischen 64-kbit/s-A-law- oder μ-law-PCM mit 8.000 Abtastungen pro Sekunde und Kanälen mit niedrigeren Bitraten, darunter 32 kbit/s. Bei dieser Rate stehen vier Bits für jede Abtastung. Daraus geht hervor, wie ein Codewort entsteht. Es sagt einem Leser der Datei aber nicht automatisch, welche Hälfte eines Acht-Bit-Bytes das frühere Codewort enthält.

Diese Unterscheidung ist klein genug, um in einer Codec-Beschreibung unterzugehen, und groß genug, um den Austausch zu stören. Zwei Implementierungen können sich auf dieselbe Folge vierbitiger Werte einigen und jedes Paar dennoch in umgekehrter Bytehälfte speichern. Beide Konventionen liefern lokal gültige Oktette; ein Leser mit der jeweils anderen Konvention rekonstruiert eine andere Folge. Dafür muss weder die Datei beschädigt noch eine Mailübertragung fehlgeschlagen sein. Die Mehrdeutigkeit liegt eine Schicht tiefer: Aus dem MIME-Subtyp allein kann der Empfänger nicht erkennen, welche lokale Konvention der Absender meinte.

RFC 1911 hatte Audio/32KADPCM bereits unter die verpflichtenden gemeinsamen Audioformate seines experimentellen Voice Profile for Internet Mail aufgenommen. Damit erhielt die Kodierung eine Rolle in einem eingeschränkten Nachrichtenprofil, doch die Reihenfolge der vier Bits blieb offen. RFC 2422, im September 1998 als Standards Track veröffentlicht und ausdrücklich als Verfeinerung der früheren Registrierung bezeichnet, schloss diese Lücke. Er registrierte audio/32KADPCM für G.726-Daten und machte eine einzige Serialisierungskonvention zum Teil der Bedeutung des Subtyps.

Die Zuordnung ist exakt. In jedem Oktett belegt das erste Codewort A die Bits 0 bis 3: Sein niederwertigstes Bit A0 steht an der niederwertigsten Stelle des Oktetts. Das nächste Codewort B belegt die Bits 4 bis 7, wobei B3 am höchstwertigen Ende liegt. Jedes weitere Paar wiederholt diese Anordnung. Es handelt sich weder um eine Umkehrung des gesamten Audiostroms noch um eine Änderung des adaptiven Prädiktors von G.726. Festgelegt wird die Reihenfolge zweier Nibbles innerhalb eines Bytes.

Diese Genauigkeit weist zugleich Arbeit zu. RFC 2422 merkt an, dass vorhandene G.726-Codecs unterschiedliche Reihenfolgen für Codewörter verwenden können. Da dieser MIME-Typ nur die Little-Endian-Anordnung zulässt, muss ein Codec mit der umgekehrten Konvention die Codewörter vor dem Speichern in diesem Typ oder nach dem Auslesen umordnen. Ein gemeinsamer Name allein hätte die Codecs nicht interoperabel gemacht. Der Standard macht den Umwandlungspunkt an der Grenze sichtbar und prüfbar, statt jede Implementierungskombination privat aushandeln zu lassen.

Das unvollständige letzte Paar zeigt noch eine Grenze. Der RFC empfiehlt, eine Sprachprobe mit Stille zu verlängern, damit der codierte Wert eine gerade Zahl von Codewörtern enthält. Bleibt die Anzahl ungerade, wird das letzte Codewort verworfen. Das ist keine Geschmacksregel für ein stilles Ende; sie sagt dem Parser, was die freie Bytehälfte bedeutet. Ohne sie endet der Container auf einer Bytegrenze, die Codec-Folge aber zwischen zwei Nibbles. Leser müssten dann eine nicht genannte Regel erfinden, ob das letzte halbe Byte zählt.

Der Subtyp hat weder erforderliche noch optionale Parameter. Sein Inhalt enthält die binären G.726-Audiodaten ohne Audio-Header; die MIME-Transferkodierung kann sie binär oder üblicherweise als Base64 transportieren. Das sind getrennte Entscheidungen. Base64 verändert, wie Oktette durch ein Mailsystem gelangen; es ändert nicht, welches Nibble A oder B enthält, sobald der Inhalt decodiert ist. Wer die Transferkodierung mit der Codewortreihenfolge verwechselt, vermischt die Hülle um Bytes mit ihrer Bedeutung.

RFC 2422 erzählt damit eine knappe, aber folgenreiche Geschichte der Standardisierung. Eine Transformation zu definieren reicht nicht immer aus, um ein interoperables Objekt zu definieren. Sobald die Ausgabe eine Grenze überquert, gehören Reihenfolge, Auffüllung und Zuständigkeit ebenfalls zum Vertrag. Das Dokument zeigt nicht, wie weit die Regel implementiert wurde, welcher Codec falsch lag oder ob ein Empfänger eine Nachricht hörte. Es zeigt aber, wo eine Implementierung die Entscheidung ausdrücklich treffen muss und wo der MIME-Subtyp sie nicht länger lokal belässt.