Update: On "Preserving unknown XML-tags and their content" in the Kolab-Format specification

Georg C. F. Greve greve at kolabsys.com
Mon Jun 20 10:28:12 CEST 2011


Hi Florian,

Thanks a lot on picking this up and driving the discussion forward!

On Monday 20 June 2011 10.01:19 Florian v. Samson wrote:
> 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 (e.g. sub-tags); But all
> Kolab-clients MUST retain all top-level XML-tags along with their full
> content within an Kolab-object.

This would be okay for me. What was your argument for choosing the slightly 
less forceful "should" instead of "must"? Where would you agree that not 
preserving tags is reasonable?


> 1b. If a XML-tag appears multiple times within one Kolab-XML-object, ALL
> occurrences of this XML-tag MUST be preserved.

Ack.


> 2. IMHO a non-issue: Eventual semantic issues.  But in order to avoid them,
> clear guidance for future extensions (i.e. XML-tags) to the Kolab-format
> are needed.
> {Bernhard pointed out semantic issues, when old clients hit newly defined
> XML sub-tags (i.e. unknown to them), embedded in existing, known XML-tags,
> and such a client alters other known fields.  Yes, the content of the
> unknown (hence untouched) XML-tags may become out of sync in relation to
> 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
> specified XML-tags, compared to limiting the extensibility of the
> Kolab-Format to top-level XML-tags only, when rule 1 (above) is mandatory.

Also, a question one may ask is in which way the alternative - so losing 
information - is preferrable. It may be possible to "fix" an object that was 
modified by an older, unaware client. It is usually not possible to re-generate 
information.


> 3. The depth of nesting XML-tags MUST be limited to 7 levels at most.
> {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.  I picked the "7" as an educated guess (i.e.
> some considerations done, but not at all exhaustive).}

I would be interested in the threat scenario.

The storage format is accessed only by authorized clients, so clients that 
have been authorized by the user to access the information. 

If the client is malicious - which seems to be assumed here - I don't see how 
an XML nesting bomb is the most likely scenario when the client might as well 
delete/falsify/make inconsistent the entire object/database.


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

Yes, imho. But I am not sure it would need to be separate, the two seem 
closely enough related.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110620/16bc2915/attachment.sig>


More information about the format mailing list