[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] length restrictions on IDN label

James Seng wrote:


There is already restriction in the number of codepoint or octets in UTF-8
(or other) encoding.

The restriction is defined currently as octet(ToASCII(X)) < 63.
I already mentioned this in my first posting.
What I request is confirmation and clarification about that restriction.

If UTF8-encoded, that valid 8bit label will exceed 63 octets limits (up to 168 octets or more)
which is imposed by RFC1035 even upon non-ASCII 8bit labels .
IDNA section 6.3 does not rule out that utf8 encoded labels may be used
in DNS wire protocols in the future. And that will affect UDP based DNS protocols
which suffers from lack of space in the UDP packet length limits (512).
Packet truncation or protcol errors are inevitable.

That is why i suggest that some separate length restriction on utf8 (other encoding) IDN labels
be needed. Or clarifications about those problems, at least.

Soobok Lee


-James Seng


That is true only in protocols predating IDNA draft.
IDN labels can be typed in/ displayed/ copy&pasted/ or exchanged in
UTF8 (or other) encoding
in now and future applications or protocols slots as described in IDNA
draft itself.
See enclosed excerpts from IDNA draft ( "SEE HERE").

I think some length restriction in code points is needed, rather than in
octets ....
IDNA is the right place to put such things..

Soobok Lee

6.3 DNS servers

Domain names stored in zones follow the rules for "stored strings" from
[STRINGPREP].

For internationalized labels that cannot be represented directly in
ASCII, DNS servers MUST use the ACE form produced by the ToASCII
operation. All IDNs served by DNS servers MUST contain only ASCII
characters.

If a signaling system which makes negotiation possible between old and
new DNS clients and servers is standardized in the future, the encoding
of the query in the DNS protocol itself can be changed from ACE to
something else, such as UTF-8. The question whether or not this should

(SEE HERE)

be used is, however, a separate problem and is not discussed in this
memo.



6.1 Entry and display in applications

(snip)

In protocols and document formats that define how to handle
specification or negotiation of charsets, labels can be encoded in any
charset allowed by the protocol or document format. If a protocol or
document format only allows one charset, the labels MUST be given in
that charset.

In any place where a protocol or document format allows transmission of
the characters in internationalized labels, internationalized labels
SHOULD be transmitted using whatever character encoding and escape ( SEE

HERE )

mechanism that the protocol or document format uses at that place.

All protocols that use domain name slots already have the capacity for
handling domain names in the ASCII charset. Thus, ACE labels
(internationalized labels that have been processed with the ToASCII
operation) can inherently be handled by those protocols.


6. Implications for typical applications using DNS

In IDNA, applications perform the processing needed to input
internationalized domain names from users, display internationalized
domain names to users, and process the inputs and outputs from DNS and
other protocols that carry domain names.

The components and interfaces between them can be represented
pictorially as:

+------+
| User |
+------+
^
| Input and display: local interface methods
| (pen, keyboard, glowing phosphorus, ...)
+-------------------|-------------------------------+
| v |
| +-----------------------------+ |
| | Application | |
| | (ToASCII and ToUnicode | |
| | operations may be | |
| | called here) | |
| +-----------------------------+ |
| ^ ^ | End system
| | | |
| Call to resolver: | | Application-specific |
| ACE | | protocol: |
| v | ACE unless the |
| +----------+ | protocol is updated |
| | Resolver | | to handle other |
| +----------+ | encodings | (SEE HERE)
| ^ | |
+-----------------|----------|----------------------+
DNS protocol: | |
ACE | |
v v
+-------------+ +---------------------+
| DNS servers | | Application servers |
+-------------+ +---------------------+