Module: IDNA

About this module

The IDNA module performs encoding and decoding of Punycoded servernames according to the IETF IDNA standards. This module contains the Unicode parts of the URL_Manager class.

Supported specifications:

An overview of the module's implementation

The module implements the GetServerName parts of URL_Manager and preprocesses each label in the servername by first validating the characters by testing against character conversion lists and blacklists, then converting it to punycode, if necessary, before finally recombining it with the rest of the name. The module also controls the revers process.

Interface overview and API documentation

API documentation generated by Doxygen contains all necessary information for the external APIs.

Footprint

The module is small.

Dynamic memory use and OOM handling

OOM policies

Most of internal module functions handles OOM by LEAVing, and the caller must TRAP errors and handle them.

Who handles OOM?

In the case of LEAVE functions the caller must TRAP the errors, and handle the OOM situations.

Flow

The module is client push based, the caller request an action and gets a result.

Heap memory usage

Most of the operations are performed in the fixed buffers stored in the module object, but the URL_Manager parts do allocate through the URL module's ServerName manager code

Stack memory usage

Usually large objects are allocated

In most cases stack consumption should be less than 300 bytes.

Static memory usage

The module uses 3 buffers of 256 unicode characters in the module object

There are also some const arrays used for processing characters. These may total a few thousand 32-bit unichars and associated integer flags. Most have been collected in a single array for processing efficiency and are coded for ranges to reduce footprint.

Additionally the module uses the temporary buffers of the URL_Manager (some functions are implemented in this moduele) and my increase these to more than 5 times the input servername, in order to handle large punycoded servernames.

Caching and freeing memory

No caching is performed. All long term storage is inside ServerName objects

Freeing memory on exit

Temp buffers are destroyed on exit.

Temp buffers

No shared tempbuffers are used.

Memory tuning

At present there are no opportunities to tune memory use.

Tests

Selftests, but they do not check memory usage.

Coverage

Selftests, ordinary surfing to sites using international characters in their hostnames or domains.

Design choices

The code processes one label at a time

Improvements

No improvements are planned related to memeory