1. Introduction (Einführung)
1.1. Overview (Überblick)
Ein Uniform Resource Identifier (URI) [RFC3986] wird häufig verwendet, um eine bestimmte Ressource innerhalb eines gemeinsamen Raums ähnlicher Ressourcen (informell als "URI-Raum" bezeichnet) zu identifizieren. Beispielsweise werden persönliche Webbereiche oft unter Verwendung eines gemeinsamen Musters delegiert, wie:
http://example.com/~fred/
http://example.com/~mark/
oder eine Gruppe von Wörterbucheinträgen könnte nach dem ersten Buchstaben des Begriffs hierarchisch gruppiert werden, wie in:
http://example.com/dictionary/c/cat
http://example.com/dictionary/d/dog
oder eine Dienstschnittstelle könnte mit verschiedenen Benutzereingaben in einem gemeinsamen Muster aufgerufen werden, wie in:
http://example.com/search?q=cat&lang=en
http://example.com/search?q=chien&lang=fr
Eine URI-Vorlage (URI Template) ist eine kompakte Zeichenfolge zur Beschreibung eines Bereichs von Uniform Resource Identifiers durch Variablenexpansion (Variable Expansion).
URI-Vorlagen bieten einen Mechanismus zur Abstraktion eines Raums von Ressourcenidentifikatoren, sodass die variablen Teile leicht identifiziert und beschrieben werden können. URI-Vorlagen können viele Verwendungszwecke haben, einschließlich der Entdeckung verfügbarer Dienste, der Konfiguration von Ressourcen-Mappings, der Definition berechneter Links, der Spezifikation von Schnittstellen und anderer Formen der programmatischen Interaktion mit Ressourcen. Die obigen Ressourcen könnten beispielsweise durch die folgenden URI-Vorlagen beschrieben werden:
http://example.com/~{username}/
http://example.com/dictionary/{term:1}/{term}
http://example.com/search{?q,lang}
Wir definieren die folgenden Begriffe:
expression (Ausdruck): Der Text zwischen ' und ', einschließlich der umschließenden geschweiften Klammern, wie in Abschnitt 2 definiert.
expansion (Expansion): Das String-Ergebnis, das aus einem Vorlagenausdruck nach der Verarbeitung gemäß seinem Ausdruckstyp, der Liste der Variablennamen und den Wertmodifikatoren erhalten wird, wie in Abschnitt 3 definiert.
template processor (Vorlagenprozessor): Ein Programm oder eine Bibliothek, die bei gegebener URI-Vorlage und einem Satz von Variablen mit Werten die Vorlagenzeichenfolge in eine URI-Referenz (URI Reference) umwandelt, indem sie die Vorlage nach Ausdrücken analysiert und jeden durch seine entsprechende Expansion ersetzt.
Eine URI-Vorlage bietet sowohl eine strukturelle Beschreibung eines URI-Raums als auch, wenn Variablenwerte bereitgestellt werden, maschinenlesbare Anweisungen zum Konstruieren eines URI, der diesen Werten entspricht. Eine URI-Vorlage wird in eine URI-Referenz umgewandelt, indem jeder begrenzte Ausdruck durch seinen Wert ersetzt wird, wie durch den Ausdruckstyp und die Werte der im Ausdruck benannten Variablen definiert. Die Ausdruckstypen reichen von einfacher String-Expansion bis zu mehreren name=value-Listen. Die Expansionen basieren auf der allgemeinen URI-Syntax, sodass eine Implementierung jede URI-Vorlage verarbeiten kann, ohne die schemenspezifischen Anforderungen jedes möglichen resultierenden URI zu kennen.
Beispielsweise enthält die folgende URI-Vorlage einen Formularstil-Parameterausdruck (Form-Style Parameter Expression), wie durch den "?"-Operator angezeigt, der vor den Variablennamen erscheint:
http://www.example.com/foo{?query,number}
Der Expansionsprozess für Ausdrücke, die mit dem Fragezeichen-Operator ("?") beginnen, folgt demselben Muster wie Formularstil-Schnittstellen im World Wide Web:
http://www.example.com/foo{?query,number}
\_____________/
|
|
Für jede definierte Variable in [ 'query', 'number' ],
ersetzen Sie "?", wenn es die erste Substitution ist, oder "&"
danach, gefolgt vom Variablennamen, '=' und dem Wert der
Variable.
Wenn die Variablen folgende Werte haben:
query := "mycelium"
number := 100
dann ist die Expansion der obigen URI-Vorlage:
http://www.example.com/foo?query=mycelium&number=100
Alternativ, wenn 'query' nicht definiert ist, wäre die Expansion:
http://www.example.com/foo?number=100
oder wenn beide Variablen nicht definiert sind, wäre es:
http://www.example.com/foo
Eine URI-Vorlage kann in absoluter Form bereitgestellt werden, wie in den obigen Beispielen, oder in relativer Form. Eine Vorlage wird expandiert, bevor die resultierende Referenz von relativer zu absoluter Form aufgelöst wird.
Obwohl die URI-Syntax für das Ergebnis verwendet wird, darf die Vorlagenzeichenfolge den breiteren Satz von Zeichen enthalten, die in Internationalized Resource Identifier (IRI)-Referenzen [RFC3987] zu finden sind. Daher ist eine URI-Vorlage auch eine IRI-Vorlage, und das Ergebnis der Vorlagenverarbeitung kann in ein IRI umgewandelt werden, indem der in Abschnitt 3.2 von [RFC3987] definierte Prozess befolgt wird.
1.2. Levels and Expression Types (Ebenen und Ausdruckstypen)
URI-Vorlagen ähneln einer Makrosprache mit einer festen Menge von Makrodefinitionen: Der Ausdruckstyp (Expression Type) bestimmt den Expansionsprozess. Der Standard-Ausdruckstyp ist die einfache Zeichenkettenexpansion (Simple String Expansion), bei der eine einzelne benannte Variable durch ihren Wert als Zeichenkette ersetzt wird, nachdem alle Zeichen, die nicht zum Satz der nicht reservierten URI-Zeichen (Unreserved URI Characters) gehören, prozent-kodiert (Percent-Encoding) wurden (Abschnitt 1.5).
Da die meisten vor dieser Spezifikation implementierten Vorlagenprozessoren nur den Standard-Ausdruckstyp implementiert haben, bezeichnen wir diese als Level 1-Vorlagen.
.-----------------------------------------------------------------.
| Level 1 Beispiele, mit Variablenwerten: |
| |
| var := "value" |
| hello := "Hello World!" |
| |
|-----------------------------------------------------------------|
| Op Ausdruck Expansion |
|-----------------------------------------------------------------|
| | Einfache Zeichenkettenexpansion (Abs 3.2.2) |
| | |
| | {var} value |
| | {hello} Hello%20World%21 |
'-----------------------------------------------------------------'
Level 2-Vorlagen fügen den Plus-Operator ("+") für die Expansion von Werten hinzu, die reservierte URI-Zeichen (Reserved URI Characters) enthalten dürfen (Abschnitt 1.5), und den Raute-Operator ("#") für die Expansion von Fragment-Identifikatoren (Fragment Identifiers).
.-----------------------------------------------------------------.
| Level 2 Beispiele, mit Variablenwerten: |
| |
| var := "value" |
| hello := "Hello World!" |
| path := "/foo/bar" |
| |
|-----------------------------------------------------------------|
| Op Ausdruck Expansion |
|-----------------------------------------------------------------|
| + | Reservierte Zeichenkettenexpansion (Abs 3.2.3) |
| | |
| | {+var} value |
| | {+hello} Hello%20World! |
| | {+path}/here /foo/bar/here |
| | here?ref={+path} here?ref=/foo/bar |
|-----+-----------------------------------------------------------|
| # | Fragment-Expansion, Raute-Präfix (Abs 3.2.4) |
| | |
| | X{#var} X#value |
| | X{#hello} X#Hello%20World! |
'-----------------------------------------------------------------'
Level 3-Vorlagen erlauben mehrere Variablen pro Ausdruck, jeweils durch Komma getrennt, und fügen komplexere Operatoren für Punkt-präfixierte Labels (Dot-Prefixed Labels), Schrägstrich-präfixierte Pfadsegmente (Slash-Prefixed Path Segments), Semikolon-präfixierte Pfadparameter (Semicolon-Prefixed Path Parameters) und die formularstil-artige Konstruktion (Form-Style Construction) einer Abfragesyntax hinzu, die aus name=value-Paaren besteht, die durch ein Kaufmanns-Und-Zeichen getrennt sind.
.-----------------------------------------------------------------.
| Level 3 Beispiele, mit Variablenwerten: |
| |
| var := "value" |
| hello := "Hello World!" |
| empty := "" |
| path := "/foo/bar" |
| x := "1024" |
| y := "768" |
| |
|-----------------------------------------------------------------|
| Op Ausdruck Expansion |
|-----------------------------------------------------------------|
| | Zeichenkettenexpansion mit mehreren Variablen (Abs 3.2.2) |
| | |
| | map?{x,y} map?1024,768 |
| | {x,hello,y} 1024,Hello%20World%21,768 |
| | |
|-----+-----------------------------------------------------------|
| + | Reservierte Expansion mit mehreren Variablen (Abs 3.2.3) |
| | |
| | {+x,hello,y} 1024,Hello%20World!,768 |
| | {+path,x}/here /foo/bar,1024/here |
| | |
|-----+-----------------------------------------------------------|
| # | Fragment-Expansion mit mehreren Variablen (Abs 3.2.4) |
| | |
| | {#x,hello,y} #1024,Hello%20World!,768 |
| | {#path,x}/here #/foo/bar,1024/here |
| | |
|-----+-----------------------------------------------------------|
| . | Label-Expansion, Punkt-Präfix (Abs 3.2.5) |
| | |
| | X{.var} X.value |
| | X{.x,y} X.1024.768 |
| | |
|-----+-----------------------------------------------------------|
| / | Pfadsegmente, Schrägstrich-Präfix (Abs 3.2.6) |
| | |
| | {/var} /value |
| | {/var,x}/here /value/1024/here |
| | |
|-----+-----------------------------------------------------------|
| ; | Pfadstil-Parameter, Semikolon-Präfix (Abs 3.2.7) |
| | |
| | {;x,y} ;x=1024;y=768 |
| | {;x,y,empty} ;x=1024;y=768;empty |
| | |
|-----+-----------------------------------------------------------|
| ? | Formularstil-Abfrage, Ampersand-getrennt (Abs 3.2.8) |
| | |
| | {?x,y} ?x=1024&y=768 |
| | {?x,y,empty} ?x=1024&y=768&empty= |
| | |
|-----+-----------------------------------------------------------|
| & | Formularstil-Abfragefortsetzung (Abs 3.2.9) |
| | |
| | ?fixed=yes{&x} ?fixed=yes&x=1024 |
| | {&x,y,empty} &x=1024&y=768&empty= |
| | |
'-----------------------------------------------------------------'
Schließlich fügen Level 4-Vorlagen Wertmodifikatoren (Value Modifiers) als optionales Suffix zu jedem Variablennamen hinzu. Ein Präfixmodifikator (Prefix Modifier) (":") gibt an, dass bei der Expansion nur eine begrenzte Anzahl von Zeichen vom Anfang des Werts verwendet wird (Abschnitt 2.4.1). Ein Explode-Modifikator (Explode Modifier) ("*") gibt an, dass die Variable als zusammengesetzter Wert (Composite Value) behandelt werden soll, der entweder aus einer Liste von Namen oder einem assoziativen Array von (name, value)-Paaren besteht, das so expandiert wird, als ob jedes Mitglied eine separate Variable wäre (Abschnitt 2.4.2).
.-----------------------------------------------------------------.
| Level 4 Beispiele, mit Variablenwerten: |
| |
| var := "value" |
| hello := "Hello World!" |
| path := "/foo/bar" |
| list := ("red", "green", "blue") |
| keys := [("semi",";"),("dot","."),("comma",",")] |
| |
| Op Ausdruck Expansion |
|-----------------------------------------------------------------|
| | Zeichenkettenexpansion mit Modifikatoren (Abs 3.2.2) |
| | |
| | {var:3} val |
| | {var:30} value |
| | {list} red,green,blue |
| | {list*} red,green,blue |
| | {keys} semi,%3B,dot,.,comma,%2C |
| | {keys*} semi=%3B,dot=.,comma=%2C |
| | |
|-----+-----------------------------------------------------------|
| + | Reservierte Expansion mit Modifikatoren (Abs 3.2.3) |
| | |
| | {+path:6}/here /foo/b/here |
| | {+list} red,green,blue |
| | {+list*} red,green,blue |
| | {+keys} semi,;,dot,.,comma,, |
| | {+keys*} semi=;,dot=.,comma=, |
| | |
|-----+-----------------------------------------------------------|
| # | Fragment-Expansion mit Modifikatoren (Abs 3.2.4) |
| | |
| | {#path:6}/here #/foo/b/here |
| | {#list} #red,green,blue |
| | {#list*} #red,green,blue |
| | {#keys} #semi,;,dot,.,comma,, |
| | {#keys*} #semi=;,dot=.,comma=, |
| | |
|-----+-----------------------------------------------------------|
| . | Label-Expansion, Punkt-Präfix (Abs 3.2.5) |
| | |
| | X{.var:3} X.val |
| | X{.list} X.red,green,blue |
| | X{.list*} X.red.green.blue |
| | X{.keys} X.semi,%3B,dot,.,comma,%2C |
| | X{.keys*} X.semi=%3B.dot=..comma=%2C |
| | |
|-----+-----------------------------------------------------------|
| / | Pfadsegmente, Schrägstrich-Präfix (Abs 3.2.6) |
| | |
| | {/var:1,var} /v/value |
| | {/list} /red,green,blue |
| | {/list*} /red/green/blue |
| | {/list*,path:4} /red/green/blue/%2Ffoo |
| | {/keys} /semi,%3B,dot,.,comma,%2C |
| | {/keys*} /semi=%3B/dot=./comma=%2C |
| | |
|-----+-----------------------------------------------------------|
| ; | Pfadstil-Parameter, Semikolon-Präfix (Abs 3.2.7) |
| | |
| | {;hello:5} ;hello=Hello |
| | {;list} ;list=red,green,blue |
| | {;list*} ;list=red;list=green;list=blue |
| | {;keys} ;keys=semi,%3B,dot,.,comma,%2C |
| | {;keys*} ;semi=%3B;dot=.;comma=%2C |
| | |
|-----+-----------------------------------------------------------|
| ? | Formularstil-Abfrage, Ampersand-getrennt (Abs 3.2.8) |
| | |
| | {?var:3} ?var=val |
| | {?list} ?list=red,green,blue |
| | {?list*} ?list=red&list=green&list=blue |
| | {?keys} ?keys=semi,%3B,dot,.,comma,%2C |
| | {?keys*} ?semi=%3B&dot=.&comma=%2C |
| | |
|-----+-----------------------------------------------------------|
| & | Formularstil-Abfragefortsetzung (Abs 3.2.9) |
| | |
| | {&var:3} &var=val |
| | {&list} &list=red,green,blue |
| | {&list*} &list=red&list=green&list=blue |
| | {&keys} &keys=semi,%3B,dot,.,comma,%2C |
| | {&keys*} &semi=%3B&dot=.&comma=%2C |
| | |
'-----------------------------------------------------------------'
1.3. Design Considerations (Designüberlegungen)
Mechanismen ähnlich den URI-Vorlagen wurden in mehreren Spezifikationen definiert, darunter WSDL [WSDL], WADL [WADL] und OpenSearch [OpenSearch]. Diese Spezifikation erweitert und definiert die Syntax formal, sodass URI-Vorlagen konsistent über mehrere Internetanwendungen und in Internet-Nachrichtenfeldern verwendet werden können, während gleichzeitig die Kompatibilität mit diesen früheren Definitionen erhalten bleibt.
Die URI-Vorlagen-Syntax wurde sorgfältig entworfen, um die Notwendigkeit eines leistungsfähigen Expansionsmechanismus mit der Notwendigkeit einer einfachen Implementierung auszubalancieren. Die Syntax ist so konzipiert, dass sie trivial zu parsen ist und gleichzeitig genügend Flexibilität bietet, um viele gängige Vorlagenszenarien auszudrücken. Implementierungen können die Vorlage parsen und die Expansionen in einem einzigen Durchgang durchführen.
Vorlagen sind einfach und lesbar, wenn sie mit gängigen Beispielen verwendet werden, da die Einzelzeichen-Operatoren mit den URI-generischen Syntaxtrennzeichen übereinstimmen. Das mit dem Operator verbundene Trennzeichen (".", ";", "/", "?", "&" und "#") wird weggelassen, wenn keine der aufgelisteten Variablen definiert ist. Ebenso wird der Expansionsprozess für ";" (Pfadstil-Parameter) das "=" weglassen, wenn der Variablenwert leer ist, während der Prozess für "?" (Formularstil-Parameter) das "=" nicht weglässt, wenn der Wert leer ist. Mehrere Variablen und Listenwerte haben ihre Werte mit "," verbunden, wenn es keinen vordefinierten Verbindungsmechanismus für den Operator gibt. Die Operatoren "+" und "#" ersetzen nicht-kodierte reservierte Zeichen, die in den Variablenwerten gefunden werden; die anderen Operatoren führen eine Prozentkodierung von reservierten Zeichen durch, die in den Variablenwerten vor der Expansion gefunden werden.
Die häufigsten Fälle für URI-Räume können mit Level 1-Vorlagenausdrücken beschrieben werden. Wenn wir uns nur um die URI-Generierung kümmern würden, könnte die Vorlagensyntax auf einfache Variablenexpansion beschränkt werden, da komplexere Formen durch Ändern der Variablenwerte generiert werden könnten. URI-Vorlagen haben jedoch das zusätzliche Ziel, das Layout von Identifikatoren im Hinblick auf vorhandene Datenwerte zu beschreiben. Daher enthält die Vorlagensyntax Operatoren, die widerspiegeln, wie Ressourcen-Identifikatoren üblicherweise zugewiesen werden. Ebenso bieten Modifikatoren auf Variablenwerten, da Präfix-Teilzeichenfolgen häufig verwendet werden, um große Ressourcenräume zu partitionieren, eine Möglichkeit, sowohl die Teilzeichenfolge als auch die vollständige Wertzeichenfolge mit einem einzigen Variablennamen anzugeben.
1.4. Limitations (Einschränkungen)
Da eine URI-Vorlage eine Obermenge (Superset) der Identifikatoren beschreibt, gibt es keine Implikation, dass jede mögliche Expansion für jeden begrenzten Variablenausdruck einem URI einer vorhandenen Ressource entspricht. Unsere Erwartung ist, dass eine Anwendung, die URIs gemäß der Vorlage konstruiert, mit einem geeigneten Satz von Werten für die zu substituierenden Variablen versorgt wird, oder zumindest mit einem Mittel zur Validierung der Benutzerdateneingabe für diese Werte.
URI-Vorlagen sind keine URIs: Sie identifizieren keine abstrakten oder physischen Ressourcen, sie werden nicht als URIs geparst, und sie sollten (should) nicht an Stellen verwendet werden, an denen ein URI erwartet würde, es sei denn, die Vorlagenausdrücke werden von einem Vorlagenprozessor vor der Verwendung expandiert. Unterschiedliche Feld-, Element- oder Attributnamen sollten verwendet werden, um Protokollelemente, die eine URI-Vorlage tragen, von solchen zu unterscheiden, die eine URI-Referenz erwarten.
Einige URI-Vorlagen können umgekehrt für Zwecke des Variablenabgleichs (Variable Matching) verwendet werden: Vergleichen der Vorlage mit einem vollständig geformten URI, um die variablen Teile aus diesem URI zu extrahieren und sie den benannten Variablen zuzuweisen. Variablenabgleich funktioniert nur gut, wenn die Vorlagenausdrücke durch den Anfang oder das Ende des URI oder durch Zeichen begrenzt werden, die nicht Teil der Expansion sein können, wie reservierte Zeichen, die einen einfachen Zeichenkettenausdruck umgeben. Im Allgemeinen sind reguläre Ausdruckssprachen besser für den Variablenabgleich geeignet.
1.5. Notational Conventions (Notationskonventionen)
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.
Diese Spezifikation verwendet die erweiterte Backus-Naur-Form (Augmented Backus-Naur Form, ABNF) Notation von [RFC5234]. Die folgenden ABNF-Regeln werden aus den normativen Referenzen [RFC5234], [RFC3986] und [RFC3987] importiert.
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; Groß-/Kleinschreibung unwichtig
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD
iprivate = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD
1.6. Character Encoding and Unicode Normalization (Zeichenkodierung und Unicode-Normalisierung)
Diese Spezifikation verwendet die Begriffe "character (Zeichen)", "character encoding scheme (Zeichenkodierungsschema)", "code point (Codepunkt)", "coded character set (kodierte Zeichenmenge)", "glyph (Glyphe)", "non-ASCII (Nicht-ASCII)", "normalization (Normalisierung)", "protocol element (Protokollelement)" und "regular expression (regulärer Ausdruck)", wie sie in [RFC6365] definiert sind.
Die ABNF-Notation definiert ihre Terminalwerte als nichtnegative Ganzzahlen (Codepunkte), die eine Obermenge der US-ASCII-kodierten Zeichenmenge [ASCII] sind. Diese Spezifikation definiert Terminalwerte als Codepunkte innerhalb der Unicode-kodierten Zeichenmenge [UNIV6].
Obwohl die Syntax und der Vorlagenexpansionsprozess in Bezug auf Unicode-Codepunkte definiert sind, sollte verstanden werden, dass Vorlagen in der Praxis als eine Sequenz von Zeichen in welcher Form oder Kodierung auch immer für den Kontext geeignet ist, in dem sie auftreten, auftreten, sei es Oktette, die in einem Netzwerkprotokollelement eingebettet sind, oder Glyphen, die auf der Seite eines Busses gemalt sind. Diese Spezifikation schreibt kein bestimmtes Zeichenkodierungsschema für die Abbildung zwischen URI-Vorlagenzeichen und den Oktetten vor, die zum Speichern oder Übertragen dieser Zeichen verwendet werden. Wenn eine URI-Vorlage in einem Protokollelement erscheint, wird das Zeichenkodierungsschema durch dieses Protokoll definiert; ohne eine solche Definition wird angenommen, dass eine URI-Vorlage im gleichen Zeichenkodierungsschema wie der umgebende Text vorliegt. Nur während des Vorlagenexpansionsprozesses ist es ERFORDERLICH (REQUIRED), dass eine Zeichenkette in einer URI-Vorlage als Sequenz von Unicode-Codepunkten verarbeitet wird.
Der Unicode-Standard [UNIV6] definiert verschiedene Äquivalenzen zwischen Zeichensequenzen für verschiedene Zwecke. Unicode-Standard-Anhang #15 [UTR15] definiert verschiedene Normalisierungsformen (Normalization Forms) für diese Äquivalenzen. Die Normalisierungsform bestimmt, wie äquivalente Zeichenketten konsistent kodiert werden. Theoretisch sollten alle URI-Verarbeitungsimplementierungen, einschließlich Vorlagenprozessoren, die gleiche Normalisierungsform verwenden, um eine URI-Referenz zu generieren. In der Praxis tun sie das nicht. Wenn ein Wert vom selben Server wie die Ressource bereitgestellt wurde, kann davon ausgegangen werden, dass die Zeichenkette bereits in der von diesem Server erwarteten Form vorliegt. Wenn ein Wert von einem Benutzer bereitgestellt wird, beispielsweise über einen Dateneingabedialog, SOLLTE (SHOULD) die Zeichenkette als Normalisierungsform C (NFC: Canonical Decomposition, followed by Canonical Composition, kanonische Zerlegung gefolgt von kanonischer Zusammensetzung) normalisiert werden, bevor sie von einem Vorlagenprozessor in Expansionen verwendet wird.
Ebenso MUSS (MUST) ein Vorlagenprozessor, wenn Nicht-ASCII-Daten, die lesbare Zeichenketten darstellen, prozentkodiert werden, um in einer URI-Referenz verwendet zu werden, die Zeichenkette zuerst als UTF-8 [RFC3629] kodieren und dann alle Oktette prozentkodieren, die in einer URI-Referenz nicht erlaubt sind.