Subject: Re: [dnssd] Encoding limitations of the <Domain> portion of the Service Instance Name

From: Stuart Cheshire <[email-masked]>
Date: Wed, 22 Jan 2014 21:10:10 -0800

On 14 Dec, 2013, at 13:38, Ilya Kulakov <[email-masked]> wrote:

> RFC 6763 states the following regarding the <Domain> portion:
> In addition, because Service Instance Names are not constrained by
> the limitations of host names, this document recommends that they be
> stored in the DNS, and communicated over the wire, encoded as
> straightforward canonical precomposed UTF-8 [RFC3629] "Net-Unicode"
> (Unicode Normalization Form C) [RFC5198] text.
> 
> Which looks almost exactly as the <Instance> portion:
> The <Instance> portion of the Service Instance Name is a user-
> friendly name consisting of arbitrary Net-Unicode text [RFC5198].  It
> MUST NOT contain ASCII control characters (byte values 0x00-0x1F and
> 0x7F) [RFC20]…
> 
> Except that the <Instance> portion does not allow ASCII control characters. My question is whether such limitation is not set on the <Domain> and it indeed allows ASCII control characters?
> 
> Best regards, 
> Ilya Kulakov

You are right. The restrictions for the <Domain> portion should match the <Instance> portion: both disallow ASCII control characters (byte values 0x00-0x1F and 0x7F).

We should publish an update or erratum to clarify this.

The intention was to strike the right balance between expressiveness and restrictiveness. The decision, right or wrong, was to disallow ASCII control characters as having no conceivable legitimate use in names (e.g. adding linefeed 0x0A to move the cursor down and overwrite the next service name in the list, or adding BEL 0x07 to make the computer go ‘beep’, etc.) but to allow all other Unicode code points. Many of those other Unicode code points may also have no legitimate use, but we didn’t try to make that determination for every Unicode code point. The ASCII control characters were an obvious thing to disallow, because we couldn’t imagine any use for them except mischief.

Stuart Cheshire