One document matched: draft-iab-dns-zone-codepoint-pples-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<rfc category="info" ipr="trust200902" docName="draft-iab-dns-zone-codepoint-pples-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc tocompact="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<front>
<title abbrev="DNS Zone Code Point Principles">Principles for
Unicode Code Point Inclusion in Labels in the DNS</title>
<author initials="A." surname="Sullivan" fullname="Andrew Sullivan">
<organization>Dyn, Inc.</organization>
<address>
<postal>
<street>150 Dow St</street>
<city>Manchester</city>
<region>NH</region>
<code>03101</code>
<country>U.S.A.</country>
</postal>
<email>asullivan@dyn.com</email>
</address>
</author>
<author initials="D." surname="Thaler" fullname="Dave Thaler">
<organization>Microsoft</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>U.S.A.</country>
</postal>
<email>dthaler@microsoft.com</email>
</address>
</author>
<author fullname="John C Klensin" initials="J.C."
surname="Klensin" >
<!-- <organization /> -->
<address>
<postal>
<street>1770 Massachusetts Ave, Ste 322</street>
<city>Cambridge</city> <region>MA</region>
<code>02140</code>
<country>USA</country>
</postal>
<phone>+1 617 491 5735</phone>
<!-- facsimile phone number and URI if appropriate -->
<email>john-ietf@jck.com</email>
</address>
</author>
<author initials="O." surname="Kolkman" fullname="Olaf Kolkman">
<organization>NLnet Labs</organization>
<address>
<postal>
<street>Science Park 400</street>
<city>Amsterdam</city>
<code>1098 XH</code>
<country>The Netherlands</country>
</postal>
<email>olaf@NLnetLabs.nl</email>
</address>
</author>
<date year="2012"/>
<abstract>
<t>
IDNA makes available to DNS zone administrators a very wide
range of Unicode code points. Most operators of zones should
probably not permit registration of U-labels using the entire
range. This is especially true of zones that accept
registrations from outside parties, including (and most
importantly) the root. It is unfortunately not possible to
generate algorithms to determine whether a code point is
intrinsically safe to permit. This memo presents a set of
principles that can be used to guide the decision of whether a
Unicode code point may be wisely included in the repertoire of
permissible code points in a U-label in a zone.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> Operators of a DNS zone need to set policies around what Unicode
code points are allowed in labels in that zone. Typically
there a number of important goals to consider when constructing
such policies. These include, for instance, possible visual
confusability between two labels, possible confusion between
Fully-Qualified Domain Names (FQDNs) and IP address literals,
and other usability and accessibility issues.
</t>
<t> This document provides a set of principles that zone operators
can use to construct their code point policies in order to
improve usability and clarity and thereby reduce confusion.
</t>
<section title="Terminology" anchor="terms">
<t>This document uses the following terms.</t>
<t><list style="hanging">
<t>LDH Label: a string consisting of ASCII letters, digits,
and the hyphen, with additional restrictions as explained
in Section 2.3.1 of <xref target="RFC5890" />.
</t>
<t>A-label: an LDH label that starts with "xn--" and
meets all the IDNA requirements, with additional
restrictions as explained in Section 2.3.2.1 of
<xref target="RFC5890" />.
</t>
<t>U-label: a string of Unicode characters that meets all
the IDNA requirements and includes at least one non-ASCII
character, with additional restrictions as explained
in Section 2.3.2.1 of <xref target="RFC5890" />.
</t>
<t>Public zone: in this document, a DNS zone that accepts
registration requests from organizations outside the zone
administrator's own organization. (Whether the zone performs
delegation is a separate question. What is important is
the diversity of the registration-requesting community.)
Note that under this definition, the root zone is a public
zone, though one that has a unique function in the DNS.
</t>
<t>Character: a member of a set of elements used for the
organization, control, or representation of data. See
Section 2 of <xref target="RFC6365" /> for more details.
</t>
<t>Language: a way that humans communicate. The use of language
occurs in many forms, the most common of which are speech,
writing, and signing. See
Section 2 of <xref target="RFC6365" /> for more details.
</t>
<t>Rendering: the display of a string of text. See
Section 5 of <xref target="RFC6365" /> for more details.
</t>
<t>Script: a set of graphic characters used for the written
form of one or more languages. See
Section 2 of <xref target="RFC6365" /> for more details.
</t>
<t>Writing system: a set of rules for using one or more scripts
to write a particular language. See
Section 2 of <xref target="RFC6365" /> for more details.
</t>
</list></t>
<!--
<t>Terms relevant to IDNA2008 can be found in <xref target="RFC5890" />.
Other relevant internationalization terms are defined in <xref target="RFC6365" />.
</t>
-->
<t>This memo does not propose a protocol standard, and the use
of words such as "should" follow the ordinary English meaning,
and not that laid out in <xref target="RFC2119" />.
</t>
</section>
</section>
<section title="Background">
<t>In recent communications (<xref target="IABCOMM1" /> and
<xref target="IABCOMM2" />), the IAB has emphasized the
importance of conservatism in allocating labels conforming to
IDNA2008 (<xref target="RFC5890" />, <xref target="RFC5891" />,
<xref target="RFC5892" />, <xref target="RFC5893" />, <xref
target="RFC5894" />, <xref target="RFC5895" />) in DNS zones,
and especially in the root
zone. Traditional LDH-labels
<!-- DT: updated with Terminology section prior to here
(see <xref target="RFC5890" /> for
definitions of IDNA terms such as LDH-label, A-label, and U-label)
<vspace blankLines="0"/><cref> JcK: the number of pointers to
other documents here could easily send the reader on a merry
chase. Such chases discourage reading, especially for an
ICANN-like audience. So I think it is probably useful to be
explicit about what definitions they can find where.</cref><vspace blankLines="0"/>
-->
in the root zone used only alphabetic
characters (i.e., ASCII a-z or A-Z). Matters are more
complicated with U-labels, however. The IAB communications
recommended that U-labels permit only code points with a
General_Category (gc) of Ll (Lowercase_Letter), Lo
(Other_Letter), or Lm (Modifier_Letter), but noted that for
practical considerations other code points might be permitted on
a case-by-case basis.
<!-- <cref source="ajs@anvilwalrusden.com"> Since JcK hated it so much, the pseudo-math notation is replaced </cref>
In what follows we will use the Unicode
notation; e.g., gc=Ll. -->
</t>
<t>
<!-- DT: did a very minor rewording. We'll see how the rest of the discussion goes
and then see what else is needed.
<vspace blankLines="1"/><cref>JcK: The next few paragraphs need
to be rewritten to be sure it is when we are talking about
zones in general and when the topic is the root. I haven't
attempted that because I think the story will depend on the
final organization of the material and how it is introduced. </cref><vspace blankLines="0"/>
-->
The IAB recommendation does, however, leave some issues open
<!-- DT: Agreed, accepted.
<vspace blankLines="0"/><cref>JcK: I think "problems" is
incorrect and looking for trouble. There may be better terms
that "open issues" but that is the best I could come up with
quickly.</cref><vspace blankLines="0"/>
-->
that need to be addressed. First, it is by no means clear that
all of the code points with General_Category Lo or Lm and which
are permitted under IDNA2008 are appropriate for a zone such as
the root zone. To take but one example, the code point U+02BC
MODIFIER LETTER APOSTROPHE has a General_Category of Lm. In
practically every rendering (and we are unaware of an
exception), U+02BC is indistinguishable from U+2019 RIGHT SINGLE
QUOTATION MARK, which has a General_Category of Pf
(Final_Punctuation). U+02BC will also be read by large numbers
of people as being the same character as U+0027 APOSTROPHE,
which has a General_Category of Po (Other_Punctuation). U+02BC
is PROTOCOL VALID (PVALID) under IDNA2008 (see <xref
target="RFC5892" />), whereas both other code points are
DISALLOWED. So, to begin with, it is plain that not every code
point with a General_Category of Ll, Lo, or Lm is consistent
with the type of conservatism principle discussed in <xref
target="conservatism"/> or the IAB recommendation.</t>
<t>To make matters worse, some languages are dependent on code
points with General_Category Mc (Spacing_Mark) or
General_Category Mn (Nonspacing_Mark). This dependency is
particularly common in Indic languages, though not exclusive to
them. (At the risk of vastly oversimplifying, the overarching
issue is mostly the interaction of complex writing systems and
the way Unicode works.) To restrict users of those languages
only to code points with General_Category of Ll, Lo, or Lm.
<!-- DT: done.
<vspace blankLines="0"/><cref>JcK: Unless we are trying to make
the point "unless you have already read the Unicode spec and
understand the way it is constructed, including the
pseudo-mathematical languages, go play elsewhere" the use of
that writing style is not helpful. Please consider following
the IDNA2008 spec and say, e.g., "... code points with
general category Ll, Lc, or Lm."</cref><vspace blankLines="0"/>
-->
would be extremely limiting. While DNS labels are not words, or
sentences, or phrases (as noted in <xref target="RFC4690" />),
they are intended to support useful mnemonics. Mnemonics that
diverge wildly from the usual conventions in a language are
likely to attract strong objections, particularly in the root.
The objections might drag the discussion away from sound
management of the DNS zone in question and towards discussions
of cultural hegemony. That sort of discussion itself might
present risks for the operation of the zone.</t>
<t>Many of the issues above turn out to be relevant to all
public zones.
<!--
so-called "public" zones - that is, zones that accept
registration requests from organizations outside the zone
administrator's own organization. (For the purposes of the
present discussion, whether the zone performs delegation is less
important. What is instead important is the diversity of
the registration-requesting community.)
-->
Moreover, the overall
issue of developing a policy for code point permission is common
to all zones that accept A-labels or U-labels for registration.
As section 4.2.4 of <xref target="RFC5891" /> says, every
registry at every level of the DNS is "expected to establish
policies about label registrations."</t>
<t>For reasons of sound management, it is not desirable to
decide whether to permit a given code point only when an
application containing that code point is pending. That
approach reduces predictability and is bound to appear subject
to special pleas. It is better instead to come up with the
rules governing acceptance of code points in advance.</t>
<t>As is evident from the foregoing discussion about the Letter
and Mark categories, it is simply not possible to make code
point decisions algorithmically. If it were possible to develop
such an algorithm, it would already exist: the DNS is hardly
unique in needing to impose restrictions on code points while
accommodating many different linguistic communities. Rules
can nevertheless be made sensibly by using overarching
principles to guide the rule-making. These principles function
as meta-rules, guiding the establishment of rules for inclusion
of any code point (from those permitted by IDNA) in labels in a
given zone.</t>
<section title="Less-restrictive Rules Going Down the DNS Tree">
<!-- DT: Accepted, but reversed order per later comments.
<t><cref>JcK: This paragraph is really important and its alpha predecessor
was lost in the introductory material. I suggest pulling it
into a separate subsection and rewriting a bit to something
like the following. It might even be pulled out into a new
Section 2 with renumbering - matter of taste.</cref></t>
-->
<t>A set of principles derived from the above ideas follows in
<xref target="allzones" />
through <xref target="root" /> below. Such principles fall
into three categories. Some principles apply to every DNS
zone. Some additional principles apply to all public zones,
including the root zone. Finally, other principles apply
only to the root zone. This means that zones higher in the
DNS tree tend to have more restrictive rules (since
additional principles apply), and zones lower in the DNS tree
tend to have less restrictive rules, since they are used
within a more narrow context. In general, the relevant
context for a principle is that of the zone, not that of a
given subset of the user community; for the root zone, for
example, the context is "the entire Internet population".
<!-- DT: pending discussion, but I've moved the definition of "public zone"
prominently to the front
<vspace blankLines="0"/><cref>JcK: I think the above is ok, although
I've rewritten it a bit. However, if you want to include
non-public zones, I think there there are really four cases:
root/TLD, SLD (or highest level zone at which a [DNS]
delegation boundary does not also represent a administrative
authority change (intermediate/structural doamins like CO.UK
are more like TLDs than SLDs); public zones below the SLD
level; and non-public zones (SLDs or below unless associated
with local/fake TLDs that do not appear in the public root).</cref>
-->
<!-- DT: I agree, reordered.
<vspace blankLines="0"/><cref>Despite the ICANN present-day obsession
with TLDs and the root, I also think it would be lots
easier to get the points here across clearly if we explained
the broadest-applicability rules ("any zone") first, then
the narrowed things toward the root with each higher level
being "all of the prior rule, plus additional restrictions".
Follow the categories of the IAB presentation, but not
necessarily the ordering - good order for a high-level
presentation is not necessarily good order for a document.</cref>
-->
</t>
</section>
</section>
<section title="Principles applicable to all zones"
anchor="allzones">
<section title="Longevity Principle" anchor="longevity">
<t>Unicode properties of a code point ought to be stable
across the versions of Unicode that users of the zone are
likely to have installed. Because it is possible for the
properties of a code point to change between Unicode versions,
a good way to predict such stability is to ensure that a code
point has in fact been stable for multiple successive versions
of Unicode. This principle is related to the Stability
Principle in <xref target="stability" />.</t>
<t>The more diverse the community using the zone, the greater
the importance of following this principle. The policy for a
leaf zone in the DNS might only require stability across two
Unicode versions, wereas a more public zone might require
stability across four or more releases before the code point's
properties are considered long-lived and stable.</t>
</section>
<section title="Usability Principle" anchor="usability">
<t>Every zone administrator should be sensitive to the
potential use of a code point to be permitted, and to be as
cautious as practical in permitting code points in the zone.
The Conservatism Principle outlined in <xref
target="conservatism" /> is in general a good idea, though
less conservatism may be appropriate in the case of
well-delineated and less-diverse user communities. Zone
administrators should especially consider whether a candidate
code point could be used maliciously or could present
difficulty if the code point is encountered outside the usual
linguistic circumstances.</t>
</section>
</section>
<section title="Principles applicable to all public zones"
anchor="PublicPrinciples">
<section title="Conservatism Principle" anchor="conservatism">
<t>Public zones are, by definition, zones that are shared by
different groups of people. Therefore, any decision to permit
a code point in a public zone (including the root) should be
as conservative as practicable. Doubts should always be
resolved in favor of rejecting a code point for inclusion
rather than in favor of including it, in order to minimize
risk.</t>
</section>
<section title="Inclusion Principle" anchor="inclusion">
<t>Just as IDNA2008 starts from the principle that the Unicode
range is excluded, and then adds code points according to
derived properties of the code points, so a public zone should
only permit inclusion of a code point if it is known to be
"safe" in terms of usability and confusability within the
context of that zone.
<!-- DT: Agree, reworded
<vspace blankLines="0"/><cref>JcK: "Safety" may be a
zone-specific context. Get far enough down in the tree and
any label permitted by RFC 2181 may be "safe".</cref><vspace blankLines="0"/>
-->
The default treatment of a code point should be that it
is excluded.
<!-- DT: I don't think such a note is needed but have no objection if
some else feels strongly.
<vspace blankLines="0"/><cref>JcK: Might be worth noting here
that Inclusion is also the basis for the ICANN IDN guidelines
for SLD names and giving a reference.</cref><vspace blankLines="0"/>
-->
</t>
</section>
<section title="Simplicity Principle" anchor="simplicity">
<t>The rules for determining whether a code point is to be
included should be simple enough that they are readily
understood by someone with a moderate background in the DNS and
Unicode issues. This principle does not mean that a completely
naive person needs to be able to understand the rationale for
why a code point is included, but it does mean that the reason
for inclusion of very peculiar code points, even if the code
points are safe in themselves, will be too difficult to
understand and such code points will therefore be rejected.</t>
<t>The meaning of "simple" or "readily understood" is
context-dependent. For instance, the root zone has to serve everyone in
the world; for practical purposes, this means that the reasons
for including a code point need to be comprehensible even to
people who cannot use the script where the code point is found.
In a zone that permits a constrained subset of Unicode characters
(for instance, only those needed to write a single alphabetic
language)
<!-- DT: changed "very small" to "constrained"
<vspace blankLines="0"/><cref>JcK: If one includes Chinese, we
aren't talking about a "very small subset". </cref><vspace blankLines="0"/>
-->
and
that supports a clearly-delineated linguistic community (for
instance, the speakers of a single language with well-understood
written conventions), more complicated rules might be
acceptable. Compare this principle with the Usability
Principle in <xref target="usability" />.
</t>
</section>
<section title="Predictability Principle" anchor="predictability">
<t>The rules for determining whether a code point is to be
included should be predictable enough that those with the
requisite understanding of DNS, IDNA, and Unicode will
usually reach the same conclusion. This is not a requirement
for algorithmic treatment of code points; as previously noted,
that is not possible. It is rather to say that the consistent
application of professional judgment is likely to yield the same
results; combined with the principle in <xref target="conservatism"
/>, when results are not predictable the anomalous code point
would not be permitted.</t>
<t>Just as in <xref target="simplicity" />, this principle
tends to cause more restriction the more diverse the community
using the zone; it is most restrictive for the root zone.
This is because what is predictable within a given language
community is possibly very surprising across languages.</t>
</section>
<section title="Stability Principle" anchor="stability">
<t>Once a code point is permitted, it is at least very hard to
stop permitting that code point. In public zones (including
the root), the list of code points to be permitted should
change very slowly, if at all, and usually only in the
direction of permitting an addition as time and experience
indicates that inclusion of such a code point is both safe and
consistent with these principles.</t>
</section>
</section>
<section title="Principle specific to the root zone"
anchor="root">
<section title="Letter Principle" anchor="letters">
<t>In keeping with the spirit of the note in <xref
target="RFC1123" /> that top-level labels "will be
alphabetic", U-labels in the root zone should exclude code
points that are not normally used to write words, or that are
in some cases normally used for purposes other than writing
words. This is not the same as using Unicode's
General_Category to include only letters. It is a restriction
that expands the possible class of included code points beyond
the Unicode letters, but only expands so far as to include the
things that are normally used the way letters are. Under this
principle, code points with (for example) General_Category Mn
(Nonspacing_Mark) might be included -- but only those that are
used to write words and not (for instance) musical symbols.
This principle should be applied as narrowly as possible; as
<xref target="RFC4690" /> says, "While DNS labels may
conveniently be used to express words in many circumstances,
the goal is not to express words (or sentences or phrases),
but to permit the creation of unambiguous labels with good
mnemonic value."
<!-- DT: hopefully addressed above
<vspace blankLines="0"/><cref>JcK: See comments supra about {TLD,
SLD, other public, any} and note that ICANN's guidelines and
the historic IANA rules apply the LDH principle variation to
public SLDs. If one used the narrowing approach I recommend,
you'd probably have "LDH Principle" for SLDs (at least) and
then note that it is further narrowed into the Letter
Principle for the root.</cref>
-->
</t>
<!-- DT: my take is that yes the root zone excludes such things.
But the Letter Principle isn't applicable to "all public zones".
Of course some public zones can apply it to their zone too,
but it's not a core principle for such zones.
<vspace blankLines="0"/><cref>You need to be
careful about how much you hand wave here because the letter
Principle and even the LDH one exclude SRV records and
similar stuff as well as, e.g., entering UTF-8 in private
zones. </cref>
</t>
-->
</section>
</section>
<section title="Conclusion">
<t>The principles outlined in this document can be applied when
considering any range of Unicode code points for possible
inclusion in a DNS zone. It is worth observing that doing
anything (especially in light of <xref target="stability" />)
implicitly disadvantages communities with a writing system not
yet well understood and not represented in the technical and
policy communities involved in the discussion. That
disadvantage is to be guarded against as much as practical, but
is effectively impossible to prevent (while still taking action)
in light of imperfect human knowledge.
<!-- DT: Agree. Reworded
<vspace blankLines="0"/><cref>JcK: Note that this is entirely
about the root. Needs to be rewritten.</cref><vspace blankLines="0"/>
-->
</t>
</section>
<section title="Security Considerations">
<t>The principles outlined in this memo are intended to improve
usability and clarity and thereby reduce confusion among different labels.
While these principles may contribute to reduction of risk, they
are not sufficient to provide a comprehensive
internationalization policy for zone management.
<!-- DT: Agree. Reworded.
<vspace blankLines="0"/><cref>JcK: I don't think this is just
about the elusive "confusion" and that "partly" above doesn't
help. I think they also increase usability and
accessibility. They also reduce the chance of confusion
between FQDNs and IP addresses, which is, by many readings of
the 1123 text, where the "must be alphabetic" rule came from
(not actually true, more of a useful side effect of other
decisions). Can we say something like "improve usability and
clarity and thereby somewhat reduce confusion..." or words to
that effect?</cref><vspace blankLines="0"/>
-->
</t>
</section>
<section title="IANA Considerations">
<t>None. RFC Editor: this section may be removed on
publication.
<!-- DT: Agree we should ignore that here.
<vspace blankLines="0"/><cref>JcK: NTIA _very_ clearly intends
that IANA refuse to delegate anything from the root that does
not conform to rules/principes like this. I think we can
safely ignore that and leave "IANA Considerations" out, but
we should at least be aware of it. </cref><vspace blankLines="0"/>
-->
</t>
</section>
<section title="Acknowledgements">
<t>The authors thank the participants in the IAB
Internationalization programme for the discussion of the ideas
in this memo. Marc Blanchet made specific comments.</t>
</section>
</middle>
<back>
<references title="Informative References">
<!-- BEGIN INCLUDED references file draft-sullivan-dns-zone-codepoint-pples-01alpha.xml-informative -->
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='IABCOMM1'>
<front>
<title>IAB Statement: 'The interpretation of rules in the ICANN gTLD Applicant Guidebook.'</title>
<author>
<organization>Internet Architecture Board</organization>
<address>
<email>iab@iab.org</email></address></author>
<date year='2012' month='February' /></front>
<format type='TXT' target='http://www.iab.org/documents/correspondence-reports-documents/2012-2/iab-statement-the-interpretation-of-rules-in-the-icann-gtld-applicant-guidebook/' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='IABCOMM2'>
<front>
<title>Response to ICANN questions concerning 'The interpretation of rules in the ICANN gTLD Applicant Guidebook'</title>
<author>
<organization>Internet Architecture Board</organization>
<address>
<email>iab@iab.org</email></address></author>
<date year='2012' month='March' /></front>
<format type='TXT' target='http://www.iab.org/documents/correspondence-reports-documents/2012-2/iab-statement-the-interpretation-of-rules-in-the-icann-gtld-applicant-guidebook/' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC1123'>
<front>
<title>Requirements for Internet Hosts - Application and Support</title>
<author initials='R.' surname='Braden' fullname='Robert Braden'>
<organization>University of Southern California (USC), Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country></postal>
<phone>+1 213 822 1511</phone>
<email>Braden@ISI.EDU</email></address></author>
<date year='1989' month='October' /></front>
<seriesInfo name='STD' value='3' />
<seriesInfo name='RFC' value='1123' />
<format type='TXT' octets='245503' target='http://www.rfc-editor.org/rfc/rfc1123.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC4690'>
<front>
<title>Review and Recommendations for Internationalized Domain Names (IDNs)</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<author initials='C.' surname='Karp' fullname='C. Karp'>
<organization /></author>
<author>
<organization>IAB</organization></author>
<date year='2006' month='September' />
<abstract>
<t>This note describes issues raised by the deployment and use of Internationalized Domain Names. It describes problems both at the time of registration and for use of those names in the DNS. It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA)
standard and its supporting tables, based on experience gained since those standards were completed. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='4690' />
<format type='TXT' octets='100929' target='http://www.rfc-editor.org/rfc/rfc4690.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC5890'>
<front>
<title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5890' />
<format type='TXT' octets='54245' target='http://www.rfc-editor.org/rfc/rfc5890.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC5891'>
<front>
<title>Internationalized Domain Names in Applications (IDNA): Protocol</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRAC
K]</t></abstract></front>
<seriesInfo name='RFC' value='5891' />
<format type='TXT' octets='38105' target='http://www.rfc-editor.org/rfc/rfc5891.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC5892'>
<front>
<title>The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)</title>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).</t><t> It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5892' />
<format type='TXT' octets='187370' target='http://www.rfc-editor.org/rfc/rfc5892.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC5893'>
<front>
<title>Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)</title>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization /></author>
<author initials='C.' surname='Karp' fullname='C. Karp'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5893' />
<format type='TXT' octets='38870' target='http://www.rfc-editor.org/rfc/rfc5893.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC5894'>
<front>
<title>Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. This document is not an Internet Standards
Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='5894' />
<format type='TXT' octets='115174' target='http://www.rfc-editor.org/rfc/rfc5894.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC5895'>
<front>
<title>Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008</title>
<author initials='P.' surname='Resnick' fullname='P. Resnick'>
<organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<date year='2010' month='September' />
<abstract>
<t>In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS). The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the
result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='5895' />
<format type='TXT' octets='16556' target='http://www.rfc-editor.org/rfc/rfc5895.txt' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor='RFC6365'>
<front>
<title>Terminology Used in Internationalization in the IETF</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2011' month='September' />
<abstract>
<t>This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo documents an Internet Best Current Practice.</t></abstract></front>
<seriesInfo name='BCP' value='166' />
<seriesInfo name='RFC' value='6365' />
<format type='TXT' octets='103155' target='http://www.rfc-editor.org/rfc/rfc6365.txt' />
</reference>
<!-- END INCLUDED references file draft-sullivan-dns-zone-codepoint-pples-01alpha.xml-informative -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:38:38 |