Summary

  • RIPE Database release 1.123 applies Unicode NFC to decomposed text in the UTF-8 path for descr: and remarks: before control-character sanitation and IDNA conversion.
  • The change is a sensible interoperability control, but the submitted sequence, the canonical database value and the bytes emitted by a selected interface remain different evidence objects.
  • A privacy-aware normalisation receipt can bind those stages without exposing free text, credentials or personal data.

One caron, two inputs, one result

Look closely at the name Ondřej Caletka. The caron over the r can be represented as the single character ř, code point U+0159. It can also arrive as an ordinary r, U+0072, followed by the combining caron U+030C. Correct rendering should make the two sequences look and behave alike. A byte-for-byte comparison does not.

RIPE NCC did not leave that distinction abstract. The source patch behind Whois release 1.123 adds an automated test using exactly this name. The first assertion sends U+0072 U+030C through a descr attribute and requires the resulting Java string to have length one. The second requires the decomposed spelling to emerge with the precomposed U+0159 character.

The implementation is equally specific. Utf8Conversion.createUtf8Attribute removes Java escapes from the attribute value, applies the NFC instance supplied by ICU, iterates the resulting code points, sanitises control characters and then performs the existing IDNA conversion. Normalisation is therefore not a visual flourish added by a browser. It is part of the value-conversion path documented by an immutable source change.

Release notes put the production deployment of 1.123 on 8 July 2026. Their description is narrow: decomposed Unicode is normalised in descr: or remarks: attributes. The current Character Encoding page says the same two free-text attributes accept Unicode code points in UTF-8 and that their UTF-8 normalisation form is NFC.

The strongest defence comes first

NFC is not an arbitrary house style. Unicode defines it as canonical decomposition followed by canonical composition. Canonically equivalent strings then receive the same NFC result. That property makes comparison and interchange less fragile: an accent entered with a combining mark need not remain a permanently different binary string from the precomposed form that another editor or client produced.

This is the strongest case for the change, and it should not be weakened by describing normalisation as tampering. The abstract text is preserved under canonical equivalence. NFC is also different from compatibility normalisation: it does not simply erase every typographic or semantic distinction that happens to look convenient.

RIPE NCC had another reason to move carefully. Release 1.122, deployed to production on 30 April, introduced UTF-8 only in descr: and remarks:. The working-group proposal called that a minimum viable change: enough to let operators add localised notices and learn from real use, but limited enough to avoid internationalising names, addresses or personal-data fields. The proposal explicitly says that personal data should not be placed in these free-text attributes. Normalisation does not alter that boundary.

The right question is therefore not whether RIPE NCC should have left equivalent strings different. It is whether a later reader can identify what changed between submission, canonical record and delivery.

The database value is not the only representation

RIPE's own interface table makes the custody problem visible. Whois on port 43, NRTMv3 and the ordinary daily dump files use Latin-1 by default. When an interface cannot represent a character, the documentation says it is replaced with ?. The database web application, Whois REST API, RDAP, NRTMv4, Syncupdates and the .utf8.gz dumps use UTF-8 by default. Port 43 can also be asked for another character set with its charset flag.

None of these choices is necessarily wrong. A legacy interface may need continuity for clients that cannot safely consume UTF-8. A UTF-8 interface should preserve the canonical character. But a file captured from a Latin-1 feed is not byte-identical evidence of the canonical UTF-8 object merely because both came from RIPE Database. A question mark introduced at an interface is not the same thing as a question mark supplied by an updater. A rendered name is not a receipt for either sequence.

This distinction matters wherever registry data is archived, compared or cited. A mirror may hash the stream it received. An operator may save an update acknowledgement. An investigator may compare a historical dump with an API response. If the record carries only one digest and no representation label, a mismatch can look like a content change when it is an encoding or normalisation change. A match at the display layer can hide the fact that the submitted sequences differed.

The public sources do not show that any particular mirror makes this mistake. They do not establish that RIPE NCC bulk-normalised older objects, or whether every pre-normalisation submission is retained internally. The point is structural: once a system deliberately transforms representation, evidence should name the side of that boundary it binds.

A thin receipt for a thick transformation chain

The remedy need not publish descr: or remarks:. Indeed, the working-group record warns against placing personal data there, and a public digest of very short or predictable text can itself be a poor privacy control. The useful object is a compact, access-aware receipt.

At update time it can identify the object version, operation acknowledgement, attribute class, input character set and update interface. It can record NFC, the software release or commit, whether the code-point sequence changed and whether sanitation or invalid-code-point substitution occurred. A protected bundle digest or keyed commitment can bind the submitted material where a naked public hash would disclose too much.

At delivery time the receipt can add the query or replication interface, requested character set, serialization version and a digest of the emitted object. A supersession link can join the result to later corrections. That creates three named layers—submitted, canonical and emitted—without turning the registry into a publisher of private update material.

The receipt is not a claim that the text is true. descr: and remarks: remain statements inside an RPSL object. Normalisation does not prove who operates a network, who owns a resource or whether routing follows the description. It proves something smaller and more useful: which transformation rule connects the representations under comparison.

What this evidence does not say

The public material does not show an NFC-related outage, attack, authorisation failure or identity error. It does not show that every RPSL attribute now accepts UTF-8; the implemented scope discussed here is descr: and remarks:. It does not show that person:, role:, org-name: or address fields were internationalised. Nor does the source patch alone establish how every historic object was handled.

This article also does not reopen the August NRTM incident. That event concerned extra newlines, an invalid RPSL object, a stopped stream and later 1.124 changes. Stream continuity and omission are different controls from NFC representation. Keeping that boundary intact is part of keeping the evidence honest.

Sources

  1. RIPE Database release notes
  2. RIPE Database character encoding
  3. RIPE Database archived quarterly plans
  4. RIPE 90 Database Working Group operational update
  5. Database Working Group proposal for UTF-8 in descr: and remarks:
  6. Database Working Group Whois 1.122 release message
  7. RIPE Labs impact analysis for UTF-8
  8. RIPE-NCC source commit: normalise decomposed Unicode
  9. RIPE-NCC Whois releases
  10. Unicode Standard Annex #15: Unicode Normalization Forms