Internationalized Resource Identifiers (IRIs)
Extracted elements (29)
A new protocol element (IRI) was defined instead of extending or changing the URI definition in order to allow a clear distinction and to avoid incompatibilities with existing software that processes URIs; IRIs serve as 'presentation elements' for URI 'protocol elements'.
Bidi restrictions on IRI components (SHOULD NOT mix rtl and ltr characters; rtl components SHOULD start and end with rtl characters) are given as SHOULDs rather than MUSTs because for IRIs never presented visually they are irrelevant, but for general IRIs they are critical for consistent visual-to-logical round-tripping.
IRI equivalence relies on pre-normalized (NFC) storage rather than normalizing at comparison time because it is unknown how a particular sequence of characters is being treated, and third-party normalization could silently alter identifiers in ways that change their meaning.
UTF-8 is required as the sole encoding for IRI-to-URI conversion (and URI-to-IRI conversion) because using any other encoding would make round-trip identity impossible: decoding iso-8859-1 percent-encoded sequences produces a different URI when the result is later re-encoded as UTF-8.
For schemes that use domain names in ireg-name and do not allow percent-encoding there, systems MAY apply the ToASCII operation (RFC 3490) to ireg-name before step 2 of IRI-to-URI mapping; this SHOULD be done when maximizing interoperability with legacy URI resolvers.
IRIs may be used in place of URIs only when: (a) the protocol or format element is explicitly designated to carry IRIs, (b) the carrying protocol/format has a mechanism to represent the wide range of IRI characters, and (c) the corresponding URI encodes original characters into octets using UTF-8.
Validated IDN components of IRIs SHOULD be character-normalized using the Nameprep process (RFC 3491) for scheme-based normalization, but SHOULD NOT be converted into ACE (punycode) form for legibility. Scheme-based normalization may treat an IDN and its punycode equivalent as equivalent.
Any kind of IRI comparison REQUIRES that all escapings or encodings in the protocol or format carrying the IRI (e.g., XML numeric character references, HTTP Transfer Codings) be resolved before comparison.
Applications MUST map IRIs to URIs using a two-step procedure: (1) generate a NFC-normalized UCS character sequence from the input IRI (with variant handling for paper/non-Unicode/Unicode-encoded inputs), then (2) convert each ucschar or iprivate character to its UTF-8 octet sequence and percent-encode each octet as %HH.
Applications using IRIs as identity tokens with no relationship to a protocol MUST use Simple String Comparison (section 5.3.1); all other applications MUST select one of the comparison practices from the Comparison Ladder.
Bidi input methods MUST generate Bidi IRIs in logical order while rendering them per section 4.1; rendering SHOULD be updated after every new character is input to avoid end-user confusion.
Bidirectional IRIs MUST be rendered using the Unicode Bidirectional Algorithm [UNIV4][UNI9], specifically as if preceded by U+202A (LEFT-TO-RIGHT EMBEDDING) and followed by U+202C (POP DIRECTIONAL FORMATTING), unless the display is identical without the embedding.
Characters outside the US-ASCII repertoire are not reserved and therefore MUST NOT be used for syntactical purposes such as delimiting components in newly defined schemes, because they fall in the 'iunreserved' category.
Conversions from URIs to IRIs MUST NOT use any character encoding other than UTF-8 in steps 3 and 4, even if context suggests another encoding was originally used in the URI (e.g., iso-8859-1 percent-encoded sequences must not be decoded as non-UTF-8).
Equivalence of IRIs MUST rely on the assumption that IRIs are appropriately pre-character-normalized (NFC) rather than applying normalization at comparison time. In cases of non-digital or non-UCS-based input, NFC MUST be used; IRIs SHOULD be created using NFC.
Higher-level protocol changes to Unicode Bidirectional Algorithm rendering MUST NOT be used if they change the rendering of IRIs.
In documents with a native character encoding, IRIs MUST be encoded in that encoding; if it is not UTF-8, IRIs MUST NOT be placed into the document in UTF-8 encoding. IRI characters not expressible in the native encoding SHOULD be escaped using the document format's escaping conventions.
IRIs MUST NOT contain bidirectional formatting characters (LRM, RLM, LRE, RLE, LRO, RLO, and PDF); such characters affect visual rendering but cannot be correctly input as part of an IRI.
Software interfaces and protocols that handle IRIs MUST define which character encoding is used. Intermediate software between IRI-capable and URI-only components MUST map IRIs to URIs per section 3.1 when transferring data; this mapping SHOULD be applied as late as possible.
When comparing IRIs character by character, the comparison function MUST NOT map IRIs to URIs, as such a mapping would create spurious equivalences. An IRI SHOULD NOT be modified when transported if there is any chance it might be used as an identifier.
When percent-encoding octets during IRI-to-URI conversion, the hexadecimal notation SHOULD use uppercase letters for digits A–F to reduce variability.
When stored or transmitted digitally, bidirectional IRIs MUST be in full logical order and MUST conform to the IRI syntax rules, ensuring they can be processed the same way as other IRIs.
An IRI (Internationalized Resource Identifier) is a sequence of characters from the Universal Character Set (Unicode/ISO 10646) that extends URI syntax by adding UCS characters beyond U+007F to the unreserved character class, while keeping the same component structure and reserved character semantics as RFC 3986 URIs.
Because some percent-encodings cannot be unambiguously decoded (e.g., %FC could be iso-8859-1 or iso-8859-5), URI-to-IRI conversion that guesses encodings can create IRIs that re-encode to a different URI, breaking identity. This is why only UTF-8 is permitted for URI-to-IRI conversion.
Bidirectional IRIs allow display of an IRI in a way that differs from its logical storage, enabling spoofing: an attacker could present a visually harmless IRI whose logical (transmitted) form is a different, malicious identifier. Section 4 restrictions mitigate but do not eliminate this risk.
Software automatically detecting IRIs in plain text must not treat a non-ASCII character as the end of an IRI, and must correctly transcode the detected IRI from the document's character encoding to the system-wide invocation mechanism's encoding, otherwise the wrong resource may be retrieved.
The UCS contains many visually similar characters (e.g., Latin 'A', Greek Alpha, Cyrillic 'A') that can be used to construct IRIs that look identical to legitimate IRIs but resolve to different resources (homograph/spoofing attacks). IRIs should use characters from a single script within each component.
The top-level IRI ABNF is: IRI = scheme ":" ihier-part [ "?" iquery ] [ "#" ifragment ]. IRI-reference = IRI / irelative-ref. The grammar closely follows RFC 3986 with non-terminals renamed (URI→IRI or prefixed 'i') wherever the unreserved set is expanded.
The 'ucschar' production defines the Unicode code point ranges permitted in IRI unreserved characters: %xA0-D7FF, %xF900-FDCF, %xFDF0-FFEF, and the ranges %x10000-1FFFD through %xE1000-EFFFD (successive 0x10000-wide planes). The 'iprivate' production covers %xE000-F8FF, %xF0000-FFFFD, and %x100000-10FFFD (private-use areas), allowed only in iquery.