Paul,
I am trying very hard, as I believe John Levine is trying, to
identify some substantive and significant issues that we see
with this draft. I don't think the discussion is moved forward
by the your apparently taking sufficient offense at those
comments and explanations to respond in the tone that you have
adopted. In the hope of keeping temperatures down, I won't
quote or respond further on those points.
However, because I'm fairly well acquainted with the authors of
RFC 5890/5891 and 6530, I do feel a need to try to correct
misunderstandings that your reading of those documents and their
predecessors seem to have produced.
--On Friday, September 11, 2015 13:38 -0400 Paul Wouters
<paul@xxxxxxxxx> wrote:
>> I note in that regard that the first sentence of Section 3 of
>> the I-D is simply false.
>
> The first sentence reads:
>
> The DNS does not allow the use of all characters that are
> supported
> in the "local-part" of email addresses as defined in
> [RFC5322] and
> [RFC6530].
>
> RFC 6530 Section 7.1:
>
> Permits the use of UTF-8 strings in email addresses, both
> local
> parts and domain names.
SMTP has a syntax rule -- going back at least to RFC 821 and
transposed into RFC 822 or vice versa (I don't remember and it
makes no difference at this point) -- that prohibits non-ASCII
characters in local parts and imposes that and additional
restrictions on the domain part of mailboxes. Those
restrictions are specific to email although the SMTP domain
rules became the basis for the "preferred syntax" in RFC
1034/1035. Those mailbox syntax rules are fairly widely
enforced in email applications. What RFC 6530 "permits" is the
use of non-ASCII strings in mailbox names as an extension to
SMTP that eliminates that strict ASCII-only syntax rule. It has
almost nothing to do with the DNS.
RFC 6055 essentially argues that applications should do the
encodings required by IDNA as late (and close to actual DNS
lookups) as possible. RFC 6530ff are consistent with that
recommendation.
> So you are claiming that DNS can take any UTF-8 character? I
> guess you should file an errata for IDNA RFC-3492.
RFC 3492 ("Punycode") simply specifies an ASCII-compatible
encoding ("ACE") that can be used when non-ASCII characters are
problematic. RFC 3490 and its successors 5890, 5801, and the
explanations in 5894 provide, I thought very clearly,
explanations of why such an encoding was (and is) desirable for
IDN use in applications. Key issues included maintaining a
reasonable level of compatibility with already-deployed
applications that had ASCII-only restrictions and working around
some canonicalization and encoding issues that the installed
base of DNS servers did not handle well. But there was never a
claim that the DNS couldn't store characters coded in UTF-8 or,
for that matter, any bit sequence in octets. The latter
capability is made quite clear in the DNS base documents
(1034/1035) and RFC 2181.
Now, for your application, you are defining a new RR Type.
There are no deployed applications that are likely to look that
RR Type up that have ASCII (or "preferred syntax") restrictions
so the IDNA arguments for sticking with an ACE form (whether
using the Punycode algorithm or something you invent) do not
apply. It may well be that simply using UTF-8 strings is
inappropriate. However, especially if you are trying to
establish linkages to email mailbox addresses that _must_ be in
UTF-8 or its ASCII subset (not coincidentally, largely because
of the same "no one but the delivery server interprets" rules
that John and I have cited several times), using it directly is
the most obvious solution, obvious to the point that, IMO, you
need to justify anything else. Whatever that justification
might be, it cannot be that the DNS cannot represent non-ASCII
characters (UTF-8 or otherwise), or even arbitrary octets,
because it definitely can handle such strings in labels and has
been able do so since its inception.
best regards,
john