On "max. tag nesting depth" in the Kolab-Format spec

[Bernhard Reiter]

Hi friends of the Kolab Format,
first thanks to Florian for bringing up the topic!
Thanks also to Gunnar, Jeroen and Georg for the interesting discussion 
and for progressing the Kolab Format overall. It is very cool to see it 
moving!

Today, I reread the whole thread from July and like to offer my perspective.
As I am not dealing with the technical details of format anymore on a daily 
basis, this is just commenting from the side lines to possible help you
find a thought that you haven't had. I am fine with anything that results
from the process and makes all people - especially the client developers - 
happy.

Okay, let me comment on the requirement of a "limit" 

Am Tuesday, 19. July 2011 17:14:18 schrieb Gunnar Wrobel:
> >> Furthermore, if the limit in nesting levels is to be implemented to
> >> prevent a potential client denial of service, 

This was an thought I had when talking to Florian about the topic,
which Florian was to kind to write down and publish.

Overall I have the feeling that an unlimited depth is not necessary
nor helpful with the domain specific data we are trying to cope with.
So my idea is to limit this in order to make client implementations
easier and still fully compliant. 
E.g. Gunnar's example error 
  DOMDocument::loadXML(): Excessive depth in document: 256 
would make its client be uncompliant to the spec, for an unknown tag,
or in other words "behabing badly". But the spec should make it possible
for an admin and support to decide who is to blame. In this case you would 
need to put forward arguments why the parser in php has this limits.
A good spec would put the burden on the client that created an unkown xml tag 
that is 300 levels deep.

I see this problem to be specific in this area of preserving unkown tags as I 
do not know what there will be. If someone would like to create such tags 
with 300 level, beyond what we have foreseen as a reasonable upper boundary,
than I would like to force them to a KEP process first.

> >> I would argue you also 
> >> require a limit for string lengths, number of sequential tags, content
> >> characters and maximum number of folders for a Kolab account.
> >
> > Oh yes, I fully agree, and suppose Bernhard will do so as well.

This would be limits on known tags where I believe the problem is not that 
large, but yes, the total length or structure or unknown tags should 
in my view be limited.

> It looks like we all agree that there exist dangers to the Kolab  
> clients by providing them with problematic input data (primarily via  
> IMAP). To me the recent discussion sounds as if this shouldn't be part  
> of a "preserve all XML tags" KEP - after all Florian already splitted  
> this topic off.

I believe Florian had splitted it off for the sake of structuring the 
discussion. To me it is a topic that is quite specific unknown tags
that need to be preserved so I would discuss it in this area.

> I'd rather see something like "ensure the client handles nesting level  
> 1000 gracefully - it MAY abort above level 10". Or "ensure the client  
> handles 10.000 groupware folders gracefully - it MAY abort when there  
> are more than 5.000".

Phrases like "unknown XML tags SHOULD be sane (reasonably parsable by the 
majority of wide-spread XML parsers)" and "clients MAY abort when not-sane"
can address my concerns up to a point here. See my other post why only up to a 
point.

Best Regards,
Bernhard
-- 
Managing Director + Owner: www.Intevation.net <- A Free Software Company
Kolabsys.com: Board Member          FSFE.org: Founding GA Member
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110928/d45fb12e/attachment.sig>