multipart/related, Content-Id-Fragen

[Der Martin]

Hallo,

wenn ich einen Request mit multipart/related content-type schicke

du meintest sicher einen Response. ;-)

------=_Part_9_8514003.1239263309918
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: binary
Content-Id: <9621AD2DA9D1FAAD65BF4269A5A438C2>

[...]
------=_Part_9_8514003.1239263309918
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-Id: <96D58B1711F52FB97CD55A296E0D82AC>

[...]
------=_Part_9_8514003.1239263309918--

So in etwa kann das aussehen, diese Struktur wird ja im Prinzip auch in HTML-Mails verwendet.

Content-Type: multipart/related; type="text/xml"; start="<9621AD2DA9D1FAAD65BF4269A5A438C2>"; boundary="----=_Part_9_8514003.1239263309918"

Der start-Parameter ist optional, wie ich eben gelesen habe; wird er weggelassen, gilt "the first part" als Start.

Bei der boundary bin ich mir ziemlich sicher, daß ich bei mehreren derartigen Requests immer wieder dieselbe boundary verwenden darf (hier scheint der letzte Teil nach dem . ein timestamp zu sein - m.W. muß es aber nur ein String sein, der innerhalb des eigentlichen Content nicht vorkommt).

Innerhalb derselben Hierarchieebene *müssen* die Boundaries sogar gleich sein, deswegen werden sie ja im Header bekanntgegeben. Die Frage ist nur bei mehrfach verschachtelten Nachrichten sinnvoll, etwa HTML-Mails: Hier habe ich zunächst multipart/alternative, normalerweise mit einem Teil in text/plain und einem in multipart/related, der wiederum das HTML-Dokument und die eingebundenen Ressourcen enthält.
Theoretisch kann man die Teile als in sich abgeschlossene Einheiten parsen, so dass man über alle Hierarchieebenen dieselbe Boundary verwenden könnte. Ich habe aber mal irgendwo gelesen, dass man das nicht tun sollte ("SHOULD NOT"), kann mich aber weder erinnern, wo das war, noch welchen Grund das haben sollte.

Wie sieht es aber bei der Content-Id aus? Klar, innerhalb eines Requests müssen die Werte sich unterscheiden.
Aber darf ich bei einem weiteren Request die Content-Id-Werte wiederverwenden?
[...]
Aus der RFC zu multipart/relative (2387) konnte ich das nicht rauslesen.

In den thematisch verwandten RFCs 2045 und 2046 kann ich auch keinen entsprechenden Hinweis finden. Ich bin daher auch völlig deiner Meinung, dass die CIDs innerhalb *einer* Message eindeutig sein müssen, damit aber ihre Schuldigkeit getan haben und in weiteren Messages/Requests beliebig wiederverwendet werden können.

So long,
 Martin