TODO

Fix main.c provisioning_handle_message:
-move xml parsing call from provisioning-decoder Provisioning_decodeWBXML to
 provisioning_handle_message. (Current way might actually be the right way)

Re-think main.c and provisioning-receiver:
-perhaps main should only handle creation and destruction.
-provisioning-receiver receiving of the message and further processing i.e.
 sending wbxml to decoder etc.
-have separate dbus handler i.e. the one that creates dbus interface etc when
 told by main and forwards received dbus messages to receiver.

provisioning-ofono:
-clean up might not be done properly

fix provisioning-xml-parser:
-to parse according to elements/nodes.

Idea would be to parse according to main branches i.e. APPLICATION, PXLOGICAL,
NAPDEF first and possibly(most likely) have a list of each item then link
correct branches to each other and then create w2/w4 structures.
NOTE: current solution doesn't handle having several w2 APPLICATIONS and would
actually use the one found last.

open item:
-Not sure but PORT might be also under PXLOGICAL

Some rudimentary structure explained somewhere e.g.
-decoder decodes wbxml to prov1.0 xml format.
-receiver and main create dbus interface + handle received dbus message by
passing it to a: decoder b: xml parser c: ofono sender.
-xml parses prov1.0 xml(to structures?)
-provisioning-ofono opens dbus connection to ofono checks that gprs interface
exists and creates ofono calls using context structures created by xml parser.

Write limitations e.g.
-provisioning parsing only for ofono purposes e.g. preferred internet start
page is not parsed.

Change parser to use libwbxml to parse the provisioning data and remove libxml
dependency.
-Q: how does libwbxml actually work? Does it create a tree from which it parses
or does it parse each query separately i.e. would it actually be more efficient
than the current way?

-reactivate deactivated context.

-Are all the policies really needed in provisioning.conf?