On preserving unknown XML-tags and their content in the Kolab-Format specification

Florian v. Samson florian.samson at bsi.bund.de
Thu Jun 16 14:23:25 CEST 2011

Thoughts and suggestions on preserving unknown (i.e. future) XML-tags and 
their content in the Kolab-Format specification:

1. Kolab-clients SHOULD retain all unknown XML-tags and their embraced (i.e 
embedded within the opening and closing tag) content, regardless of their 
position in the XML-tag-tree and of their content, but all Kolab-clients 
MUST retain all top-level XML-tags along with their full content within an 
{Some argue, only the latter statement shall be put into the Kolab-Format 
specification.  I do see the hurdles for various clients to implement the 
preservation of all unknown XML-tags, but strongly believe that limiting 
tag-preservation to top-level XML-tags only vastly reduces extensibility of 
the Kolab-Format, as mixed environments with both old and new clients are 
extremely problematic to impossible then.  Hence the rather weak "SHOULD" 
instead of a "MUST", but I think the general direction must be clear.}

1b. If a XML-tag appears multiple times within one Kolab-XML-object, ALL 
occurrences of this XML-tag MUST be preserved.  
{Currently some clients only preserve their first occurrence, discarding all 
other occurrences.  Explicitly allowing this behaviour simplifies some 
things.  More detailed reasoning can be requested from Hendrik.)

2. {Bernhard pointing out semantic issues, when old clients hit newly 
defined XML sub-tags (unknown to them) embedded in existing, known 
XML-tags, and such a client alters the known fields.  Yes, this issue does 
exist, the content of the unknown (hence untouched) XML-tags my become out 
of sync relative to the known tags which may be altered by the old client, 
but I think ...
I. ... it is easily overcome by defining the XML-tags and their content 
properly, so they do not contain duplicate or dependent information,.  In 
case of orthogonal (i.e. completely unrelated/uncorrelated information, 
this is a non-issue.
II. ... furthermore, that is a minor issue even without such carefully 
specifies XML-tags, compared to limiting the extensibility of the 
Kolab-Format to top-level XML-tags only, when rule 1 (above) is mandatory.}

3. The maximal depth of nesting XML-tags MUST be limited to 7 levels. 
{A suggestion from Bernhard in order to limit the size of and parsing 
efforts for Kolab-objects, which otherwise may be used for 
Denial-of-Service attacks.}

a. Please discuss!

b. Do we need similar, but separated statements for XML-attributes?


More information about the format mailing list