Skip to main content

How the ITI Technical Infrastructure Works

We've blogged previously that the Information Transparency Initiative (ITI) is a foundational project that aims to establish content governance and rebuild our underlying technical infrastructure. These key foundational deliverables will improve how we manage all of our content. ICANN's new technical infrastructure will eventually power our internal and external content platforms, including and the Supporting Organization and Advisory Committee (SO/AC) websites. This infrastructure includes a new document management system (DMS) and a new content management system (CMS). The specific platforms we are using are Alfresco, the DMS, and dotCMS, the CMS.

There is a lot of behind-the-curtain engineering effort that goes into achieving these goals. To help you better understand the planning and implementation that goes into a project of this size, I'd like to provide you with a peek behind that technical curtain.

Allow me to illustrate this effort using the journey of one piece of content from creation to publication.

  1. Creating Content

    The first step in this process is the creation of content. This content can include text, images, video, or audio. Today, text content most often begins in Microsoft Word or Google Docs. In the future state, some content will be directly authored in the new DMS via templates and transformed into HTML pages. Other content will continue to be authored in Word or Google Docs and uploaded to the DMS.

  2. Tagging the Content

    This next step is an important one – adding tags from the ICANN taxonomy. Each piece of content needs to be categorized and tagged leveraging ICANN's taxonomy. This taxonomy was developed to ensure we maintain consistency in how the content is organized, which in turn makes the content easier for our users to find. To enable this tagging and improved search, ICANN will leverage a popular open-source enterprise search platform called SOLR.

    At this stage, the content is ready for reviews and approvals.

  3. Providing Reviews, Approvals, and Translation

    Some content intended for publication may need to be reviewed and approved by one or more ICANN functions. Authors will be able to route content to the appropriate reviewers and approvers before the content is publishable. Once reviewed and approved, the content can then be pushed to Language Services for translation.

    A key feature of the DMS is its ability to enforce and govern workflows to ensure the accuracy and quality of content.

    Once the content is released, it is ready for MOM. Who or what is MOM?

  4. Staging the Content with Message-oriented Middleware (MOM)

    No, it's not the MOM you are thinking of. Message-oriented middleware (MOM) is a content staging platform. A piece of content may need to be published to multiple platforms. To enable this, ICANN's Engineering & IT team has leveraged a commercially licensed platform called Kafka, which is a type of MOM. It stages content before the content is published to one or more public sites.

  5. Preparing the Content for Presentation

    In order for the site to publish the content, the CMS subscribes to content in the MOM to begin the presentation layer of the public site. The CMS organizes content according to content modelling performed in the DMS. The modelling ensures that the content is presented in a way that makes sense for how it will be surfaced and viewed by the user. This includes where the content fits in the site's navigation, ensures multilingual content is tied to the source, and enables indexing for search.

  6. Presenting the Content

    The final step in this process is publication. The ITI team has chosen an architectural approach called a single page application (or SPA). SPAs are web applications that load individual HTML pages and dynamically update page content. In this new architecture, we are leveraging a JavaScript language called AngularJS for development, and a popular styling framework to render content to our public sites. This additional layer of the architecture allows for more rapid development, mitigates against system limitations, and gives our users a truly responsive and accessible experience.

    Our foundation meets ICANN's stringent security requirements and fits within our continuous integration and deployment strategies, and our goal of ensuring our infrastructure is Reliable, Available, Scalable, and Performing (RASP).

    This foundational architecture was recently proven with the launch of the new Acronyms and Terms feature.

    ITI is just the beginning. These elements are the foundation for the future – a future where we will have a consolidated, multitenant environment housing all ICANN-controlled public properties.

    For more information about ITI, visit On this site, you'll find links to previous ITI blogs, background documentation, and more. If you're interested in learning more about ITI or have a suggestion or feedback, email us at


    Carol HarthSchapker  22:28 UTC on 21 June 2018

    Re: #3. Does this apply to the general public?

    Jana Juginovic  10:59 UTC on 02 July 2018

    Thank you for your question and interest in the Information Transparency Initiative. Currently, ICANN organization staff publish community, Board, and organization content to the ICANN website. The document management system (DMS) is an internal tool to assist in the content creation, governance, and publishing aspects of getting that content onto our public website. When the DMS is up and running and integrated with the ICANN website, ICANN organization staff will remain responsible for the internal process of publishing content to the website. This will ensure the integrity and security of the DMS, so we could not open the DMS to the general public. However, the general public will continue to have access to all the public content on the ICANN website, albeit with an improved search and user experience.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."