Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale
draft-ietf-idnabis-rationale-17

[Ballot comment]
From a review by Christian Vogt:

- Section 1.1 says that "case-insensitivity is treated slightly
  differently in IDNA2008" than in IDNA2003.  It is not clear from the
  context why this is so.

- At the beginning of section 3, the term "code-point" is used without
  definition.  Suggest adding a definition.

- It may make sense to re-consider the title of section 4.  The current
  title is "Issues that Constrain Possible Solutions", and one would
  hence assume that the section covers issues that have made the
  design of IDNA2008 harder.  But the section rather describes issues
  related to applications supporting IDNA2008.  Therefore, a title
  such as "Application-Related Issues" would in my opinion be
  preferable.

[Ballot comment]
Slightly puzzled by Section 1.1

  Internationalized Domain Names in Applications (IDNA) is a collection
  of standards that allow client applications to convert some Unicode
  mnemonics to an ASCII-compatible encoding form ("ACE") which is a
  valid DNS label containing only letters, digits, and hyphens.

Why is this specific to mnemonics?
Surely the purpose of the characters is out of scope except that they
are locally displayable/configurable.

Shows up in 1.3.1 as more of an example than a rule.

---

idnits doesn't seem to be too happy with the way you have used references. I quote:

  == Unused Reference: 'ASCII' is defined on line 1886, but no explicit
    reference was found in the text

  == Unused Reference: 'Unicode-UAX15' is defined on line 1927, but no
    explicit reference was found in the text

  == Unused Reference: 'BIG5' is defined on line 1943, but no explicit
    reference was found in the text

  == Unused Reference: 'GB18030' is defined on line 1952, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC0810' is defined on line 1962, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC2673' is defined on line 1990, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4690' is defined on line 2020, but no explicit
    reference was found in the text

  == Unused Reference: 'Unicode-UTR36' is defined on line 2038, but no
    explicit reference was found in the text

  -- No information found for draft-ietf-idnabis-mapping - is the name
    correct?

  -- Obsolete informational reference (is this intentional?): RFC  810
    (Obsoleted by RFC 952)

I think the RFC Editor will require that all references are cited in the text, or removed from the list.

---

FWIW I got seriously berated over Christmas by a relative who is a Bahá'í. Apparently we are facilitating non-convergence of communication between the peoples, and that is contrary to the teachings of Bahá'u'lláh.

[Ballot comment]
The first two COMMENTs are related to my DISCUSS.

I worry about listing rules or algorithms like those in section 7.1.3 in a non-normative document where the normative definition is elsewhere.  It's not clear to me the explicit list of process steps is required for clarity or completeness in 7.1.3, so I suggest that the editors consider replacing the explicit process with a pointer(s) to the normative definition(s).

Nit... "Anyone looking up a label in a DNS zone is required to" seems imprecise.  Is "anyone" a user or an application or a DNS resolver?

-----

In section 7.2.3: "these characters" refer to which characters?

[Ballot discuss]
This DISCUSS should be easy to clear...

Section 7.1.1 carefully explains that "the actual rules are rigorously defined in [IDNA2008-Protocol] and [IDNA2008-Tables]", to make sure that the text in section 7.1.1 is not considered normative.  I assume the text in sections 7.1.2 and 7.1.3 is similarly non-normative.  If I have that right, text should be added to clarify and point to the normative references.

[Ballot comment]
idnits doesn't seem to be too happy with the way you have used references. I quote:

  == Unused Reference: 'ASCII' is defined on line 1886, but no explicit
    reference was found in the text

  == Unused Reference: 'Unicode-UAX15' is defined on line 1927, but no
    explicit reference was found in the text

  == Unused Reference: 'BIG5' is defined on line 1943, but no explicit
    reference was found in the text

  == Unused Reference: 'GB18030' is defined on line 1952, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC0810' is defined on line 1962, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC2673' is defined on line 1990, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4690' is defined on line 2020, but no explicit
    reference was found in the text

  == Unused Reference: 'Unicode-UTR36' is defined on line 2038, but no
    explicit reference was found in the text

  -- No information found for draft-ietf-idnabis-mapping - is the name
    correct?

  -- Obsolete informational reference (is this intentional?): RFC  810
    (Obsoleted by RFC 952)

I think the RFC Editor will require that all references are cited in the text, or removed from the list.

[Ballot comment]
Should the [IDNA2008-Mapping] reference be normative for this Informational document?

7.1.  Design Criteria

  o  to permit incrementally adding new characters, character groups,
      scripts, and other character collections as they are incorporated
      into Unicode, doing so without disruption and, in the long term,
      without "heavy" processes (an IETF consensus process is required
      by the IDNA2008 specifications

I am not entirely sure which part you are calling "heavy" process: IETF Consensus process, or something else?

      and is expected to be required and
      used until significant experience accumulates with IDNA operations
      and new versions of Unicode).

7.1.3.  Labels in Lookup

  To further clarify the rules about handling characters that require
  contextual rules, note that one can have a context-required character
  (i.e., one that requires a rule), but no rule.  In that case, the
  character is treated the same way DISALLOWED characters are treated,
  until and unless a rule is supplied.  That state is more or less
  equivalent to "the idea of permitting this character is accepted in
  principle, but it won't be permitted in practice until consensus is
  reached on a safe way to use it".

Just to double check: my understanding that currently there are no "no rule" CONTEXTO characters defined. Is this correct?

IANA has a question about this document.

As described in the IANA Considerations section, we understand that this
document has no specific IANA Actions.

IANA further understands that the IDNA Character Registry and the IDNA Context Registry are specified in another document and are new registries for IANA.

IANA has a question about the impact of this document on the Repository of IDN Practices located at http://www.iana.org/domains/tables

Upon approval of this document, do the authors expect any further codepoints to be registered in the Repository of IDN Practices? Further, is it up to any TLD operator to make any needed changes to this repository as a result of the approval of this document (and the associated IDNAbis series)?