[Freeassociation-devel] patch for more controlled treatment of unknown parameters

[Gren Elliot]

Hi Libical maintainers,

I would be grateful if you would review the attached patch.  If it (or 
parts of it) looks good then please could someone do the necessary 
commit(s).

The main purpose of the patch is to allow control of how unknown 
parameters in properties are handled.
At the moment, if an unknown parameter is encountered and that parameter 
does not begin with "X-" then parsing is abandoned.  (There is code in 
icalparser.c claiming to be for Mozilla which appears to drop unknown 
parameters if  ICAL_ERRORS_ARE_FATAL is not defined.  To me, that seems 
to be overloading the meaning of that define).  RFC 5545 (and earlier 
iCalendar standards) talk about being able to extend ICAL using IANA 
parameters.  By definition, any iteration of the libical library is not 
going to be able to know all future IANA parameters - so it seems 
sensible to at least have the ability to assume that an unknown 
parameter is a valid IANA parameter.

An enum controls the handling - there are 3 values.
    ICAL_ASSUME_IANA_TOKEN, ICAL_DISCARD_TOKEN, ICAL_TREAT_AS_ERROR

The getter/setter functions are :
    ical_unknown_token_handling 
ical_get_unknown_token_handling_setting(void);
    ical_set_unknown_token_handling_setting(ical_unknown_token_handling 
newSetting);

The default value is ICAL_TREAT_AS_ERROR - which mostly closely matches 
current behaviour - I would prefer it to be ICAL_ASSUME_IANA_TOKEN - as 
calendaring clients like iCal.app and Lightning are already using 
parameters not recognised by libical.  If this value is set, then 
unknown parameters which don't start with "X-" are assigned the kind 
ICAL_IANA_PARAMETER and there are new routines available for 
manipulating such parameters (closely modeled on those for 
ICAL_X_PARAMETER).

I can envisage a use for ICAL_DISCARD_TOKEN to allow inter-working with 
old systems.  For instance, when sending iMip messages, the contained 
ICAL could be assembled with ICAL_DISCARD_TOKEN set to avoid causing 
foreign systems to choke.

I noticed that due to sorting of the lines in 
design-data/parameters.csv, adding new known parameters would result in 
changing enum values in "icalparameter_kind".  This essentially forces a 
breakage for products linked agains an earlier version of the libical 
API - so part of the proposed change is to allocate enum values.  The 
numbers I have chosen are consistent with the state before this change.

mkderivedparameters.pl has changed so that comments about machine 
generated code surround the code rather than coming after it [ and 
claiming that  said code  follows ;-) ]

The example code and makefile work demonstrate the effect of these changes.
The makefile allows linking with a previous version (installed in the 
usual system location) and the new version (installed where 
scalix-libical installs...)

One obvious thing about this is that components, and properties suffer 
from similar issues.  If this patch is well received, I plan to make 
similar changes for those.

Also, there are clearly some known IANA parameters which this patch does 
not add direct support for.  It would be nice to add support for at 
least some of those so that specific routines exist to handle them 
rather than having to treat them as generic IANA parameters.

Regards and thanks,
Gren.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: scalix-libical-unknown-params.patch
Type: text/x-patch
Size: 19318 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libical-devel/attachments/20091118/8a61cb13/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libicalParam.c
Type: text/x-csrc
Size: 1555 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libical-devel/attachments/20091118/8a61cb13/attachment-0001.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libicalParam.mf
URL: <http://lists.infradead.org/pipermail/libical-devel/attachments/20091118/8a61cb13/attachment.ksh>