Subject: [idn] IDN refocus, v4

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Nov 2001 15:52:19 -0600

There is a stated need for a clearer focus on WG output. Although text was
requested, it seems that in order to effectively define the output goals,
we should come up with a set of core objectives that we can reach basic
agreement on. However, the objectives should be specified as practical
tangible results, rather than restrictions on implementation targets that
result in unintended consequences.

The list of objectives that I would start with are as follows (note that
this is not a vote, but a list of possible ballot items for a vote):

  1) Define an internationalized domain name and host name syntax
     for compliant protocols and applications to use.

     [ ] yes
     [ ] no

  2) Define a seven-bit label encoding that legacy protocols and
     applications can use to store and represent i18n domain names
     as defined data.

     [ ] yes
     [ ] no

  3) Define an UTF-8 label encoding that BCP18-compliant protocols
     and applications can use to store and represent i18n domain
     names as defined data.

     [ ] yes
     [ ] no

  4) Provide proposals to DNSEXT for handling these label encodings
     in the DNS service.

     [ ] yes
     [ ] no

  5) Provide guidelines for the protocol and data-formatting groups
     to use when they extend their services to tag, store, decipher
     and/or display (as necessary) these encodings.

     [ ] yes
     [ ] no

  n) others...?

We should be able to come to immediate agreement on 1 and 2. If the
existing proposals are not modified, items 4 and 5 will also have to be
done (item 4 is already done actually), even if it is not entirely obvious
to all of their advocates.

I would also suggest that any further attempts by interested third parties
to redefine the charter without a vote be summarily rejected.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Nov 2001 13:59:32 -0800

At 03:52 PM 11/19/2001 -0600, Eric A. Hall wrote:
>There is a stated need for a clearer focus on WG output.

Correct.

That is what the new charter that is being forwarded to the IESG achieves.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 19 Nov 2001 17:13:48 -0500

Dave,

I didn't think so (that the current text actually improved things).

Eric

---

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 20 Nov 2001 09:05:19 +0800

>      for compliant protocols and applications to use.

It become more apparent that it is dangerous to into the discussion of
internationalized domain names vs internationalized host names. Such
discussion is half-technical and half-policy and this group may not have
sufficient information to determined what is a considered a valid
hostname, and that is subjective to registries.

>      and applications can use to store and represent i18n domain

(2) & (3) are solution-focus statement. And neither have rough consensus
nor sufficient fact. I think we should put a scope around this and not
specify any solution.

Define an IDN label encoding that protocols and applcations can used to
store and represent i18n domain names.

>   4) Provide proposals to DNSEXT for handling these label encodings

Longer term goal maybe.

>      and/or display (as necessary) these encodings.

Care to explain a bit more?

> to redefine the charter without a vote be summarily rejected.

We dont do vote in IETF.

-James Seng

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Nov 2001 20:40:00 -0600

> hostname, and that is subjective to registries.

I don't want to make a big deal out of this point, but I would like to say
that the distinction is required for basic functionality. For example, SRV
entries use underscore, which is not a permitted character in nameprep
(rightly) for use with host names, so domain names and host names have to
be defined individually if both are to function.

The distinction is not that fuzzy. Domain names are simply sequences of
octets, while host names are those domain names which identify connection
targets (either in part [relative] or in sum [FQDN]) and which conform to
the rules provided by RFC952, STD3 and STD13. We really need to define
i18n equivalents in order to meet the requirements of the DNS community.

> >   4) Provide proposals to DNSEXT for handling these label encodings

My understanding (which may be wrong) is that DNSEXT is leaving
specification to us but reserving the right of ratification. Some work is
likely to be required. If the IDN WG task list will be fluid this will
show up sooner or later so I'm not going to argue the point.

> Care to explain a bit more?

Defer all display processing, but give guidance on basic elements such as
boundaries and illegal conditions. For example, we know that seven-bit
domain names cannot be encoded in ACE, are harmful when provided, and MUST
be discarded when discovered, and this information has to be relayed to
other working groups.

> store and represent i18n domain names.

I see this as an opportunity to establish the consensus, which would
facilitate finite deliverables for the WG. We can cut the overall timeline
down if we go through the pain once and for all. Once we can agree on the
objectives, arguing over deployment mechanics is a lot less stressful
(hopefully). We really should come to terms with the objectives first, or
else this will remain a perpetual open issue.

---

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 20 Nov 2001 13:52:21 +0800

> be defined individually if both are to function.

Our opinion on host vs domain name isnt really different :-). The
question is which one do we do? Or both? All are valid answer.

> be discarded when discovered, and this information has to be relayed
to

Hmm, good point. I agree with the concept of doing so. I am not sure of
the exact mechanism to do so tho but that is what a goal is for ;) But I
do see this as the goal for the next step when we have one.

> else this will remain a perpetual open issue.

Okay, then I have one more questions before (2) & (3).

Do we need more than one IDN label encoding that protocols and
applications can use to store and represent i18n domain names?

-James Seng

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Nov 2001 01:34:21 -0600

> question is which one do we do? Or both? All are valid answer.

The encoded values being passed around are supposed to -decode- as UCS
character codes, so it would seem best to maintain consistency across all
outputs. We do not want to make it more complex than necessary and
defining multiple extraction profiles would make processing much more
complex: "we promise that this encoding will represent a series of UCS
characters" should be it. For that reason, my opinion is that any UCS
character code (including those not yet assigned) should be valid for
internationalized domain names (with nameprep providing the host name
subset filter). Going that route incurs a responsibility to tell
implementations that they have to be careful with data they process, but
in truth we had that responsibility already given the broader exposure of
the combining characters.

> applications can use to store and represent i18n domain names?

I would submit that we are describing transfer encodings and their
handling. The application media being used to transfer the encoded values
provide seven- and eight-bit paths. For the sake of maximum efficiency
with the applications that transfer and use the domain names, we should
provide seven- and eight-bit encodings. The encapsulation constraints in
DNS are difficult to work with but that does not change the above. We
should not be defining mandatory seven-bit encodings for eight-bit
applications especially if they are compliant with BCP18 for every unit of
protocol and/or application data.

---

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 20 Nov 2001 16:01:05 +0800

> the combining characters.

Right! As I said, we are not disagreeing :-) But I think it is useful to
continue this discussion as I think it is leading somewhere.

Definition:

domain names - any 8-bit characters, usually (but not neccessary)
US-ASCII

host names - limited to LDH, no leading or trailing "-", delimited by
".", cannot contain have all digits-only labels

What is a definiton of internationalized domain names and
internationalized host names?

We seem to agree at least that

i18n domain names - any unicode characters

i18n host names - i18n domain names subjected to prohibited list defined
in Section 5 of nameprep (host names limitation, space characters,
control characters, private use, etc)

but is i18n host name sufficient for normal use? as technical
implementation, maybe. for policy implementation, unlikely. perhaps we
need a new term for that...

> protocol and/or application data.

We differ in this.

The question if we need more than one CCS have been answered long time
back. The choice clearly ISO/IEC 10646.

TES is an encoding. CES is an encoding. I am asking if we need more than
one encoding (either TES or CES). That is my first question.

If the answer is that we need more than one encoding, then the next
question would be how many separate cases do we have, ie, how many
encodings do we need? (I could argue it is more "fair" to use UTF-32 in
EDNS labels)

Then we can start asking which is the appropriate encoding for each
case, ie, your question 2 and 3.

-James Seng

---

From: Rick H Wesson <[email-masked]>
Date: Tue, 20 Nov 2001 00:42:58 -0800 (PST)

On Tue, 20 Nov 2001, James Seng/Personal wrote:

[snip]

> ".", cannot contain have all digits-only labels

I believe host names can be all digits, don't know if its in a rfc but
there are hosts and lables that are all digets.

-rick

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 20 Nov 2001 11:11:49 +0100 (CET)

> show up sooner or later so I'm not going to argue the point.

On the relationship between IDN and DNSEXT ...

I think in such a case DNSEXT would just like to see the requirements
from the IDN WG and they can figure out what protocol mechanisms are need to
make it fit with DNS.

Thus discussing how such a mechanism works in general, what the issues are
with respect to CNAME, PTR, etc, and of course transition issues makes sense
to do in the IDN WG. But not much more. The DNS expertise is in the DNSEXT
group thus they can figure out whether and how things like EDNS can be
applied to solve such requirements.

Of course, in order for the IDN WG to be able to understand and discuss the 
issues in such an approach there must be a worked out proposal that folks can
look at, which might mean that some initial idea of some DNS things might
be specified. Just don't expect DNSEXT to rubber stamp such a thing.

   Erik

---

From: David Hopwood <[email-masked]>
Date: Tue, 20 Nov 2001 07:24:31 +0000

-----BEGIN PGP SIGNED MESSAGE-----

> That is what the new charter that is being forwarded to the IESG achieves.

No, the new draft charter includes this text:

# Hence this enhancement to the DNS
# involves only end-user software.  In particular software that needs to
# be changed is restricted to:  DNS client.  No other modules will need
# to be changed.

which is an unnecessary and undesirable restriction, that none of the
current proposals (including IDNA [*]) comply to - and in fact that is
impossible to comply to given the requirements. There is no place for
this kind of statement in a WG charter, and there is no concensus on
it, rough or otherwise.

[*] IDNA requires changes to end-user software that does not act as a
    DNS client, and to DNS administrative interfaces.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Nov 2001 10:42:55 -0600

> i18n domain names - any unicode characters

Any UCS character code (including codes without character representations)

> control characters, private use, etc)

Must specify normalized characters as the valid range. Non-normalized
characters are valid in domain names but for host names only the
normalized equivalents are valid.

Upper and lowercase have to be valid. Note that my draft required
lowercasing for protocol operations and comparisons although for other
operations the case is not relevant, and the case-neutral "host name"
concept has to be preserved at the end-system applications (regardless of
what happens in the network).

> need a new term for that...

I used the terms STD13 Domain Name, STD13 Host Identifier,
Internationalized Domain Name and Internationalized Host Identifier, which
may be suitable.

> one encoding (either TES or CES). That is my first question.

As stated, I believe that we need 7- and 8-bit TES because the transfer
media offer 7- and 8-bit paths, and it would impose inefficiencies on
those services to choose only one or the other.

> encodings do we need? (I could argue it is more "fair" to use UTF-32 in

We only need two to start with, since we only have 7- and 8-bit media to
worry about at the moment.

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 21 Nov 2001 00:49:05 +0800

> there are hosts and lables that are all digets.

labels can all be digits. host names cant.

james

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 20 Nov 2001 12:26:44 -0500

Eric,

> Any UCS character code (including codes without character representations)

Good catch. Both.

> labels can all be digits. host names cant.

If memory serves, we fixed the 3com problem in 1123, so someone is making
the claim that "3" can't be a hostname. In my more unimaginative youth I
used digits as hostnames, which only proves I've fewer hosts now.

Chapter and verse would be helpful, unless I've somehow managed to misquote
or mischaracterize yet another of James' wild swings at authority, and he
actually wrote "hostnames can (be all digits also)".

Eric

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 21 Nov 2001 02:01:30 +0800

read: *all* digits-only labels

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 20 Nov 2001 13:08:44 -0500

which rfc(s) did you cite? i seem to have missed it.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Nov 2001 12:48:36 -0600

James Seng/Personal wrote:

> applications will check validity of i18n domain names.
> policy will check validity of i18n host names.

Yes, more or less.

> 1. Do we need more than one CCS.
>    Conclusion: No, we only need one and ISO/IEC 10646.

Agree

> 2. Do we need more than one encoding (TES or CES) of ISO/IEC 10646?

We have more than one media (application) format. If we are to encapsulate
the domain names into the media efficiently, we need a TES for each of the
media formats.

I'm not sure we need to specify any CES rules at all. We only need to
specify the canonical CCS values, and do not need to specify a CES as far
as I can tell.

> 3. If answer to (2) is yes, then how many encodings cases do we need?

A trickier problem is finding the encapsulation substrate. Do we specify
encodings for protocols, or for data formats? In the latter case, do we
define TES for every registered MIME charset/encoding? I mean, do we
really want to define transfer encodings for ISO-2022-JP (including all of
the charset switching stuff)?

I would say that we should start with two core TES formats: 7-bit for
US-ASCII media, and 8-bit for UTF-8 media. We should also discuss the
issues surrounding the need for secondary transformations for all other
media formats and leave it up to the protocol and/or data working groups
for implementation. EG, if an email message contains ISO-2022-JP then our
suggestions should result in the 7-bit encoding being used, but we should
not have to specify that mapping explicitly.

> 3.1 For each cases, what is the right appropriate encoding?

If the approach above is the one that is taken, ACE and UTF-8.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Nov 2001 12:58:56 -0600

"Eric A. Hall" wrote:

> really want to define transfer encodings for ISO-2022-JP (including
> all of the charset switching stuff)?

I would point out here that the DNS message is also a data format which
has its own peculiarities, in that it provides the octet encoding syntax
for domain names, and which has to be recognized and supported as an
application-specific encoding. This is an example that shows how there
will be application-specific encodings, but that this WG does not have to
explicitly define every such encoding (DNSEXT owns this one, for example).

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 21 Nov 2001 03:21:47 +0800

I cant believe my english is that bad that so many people can
misunderstood me. :P

digits-only label
    => label with only digits e.g. 1234

all digits-only labels hostname
    => all labels of the hostnames is digits-only label
       e.g. 1234.4567.890

it is consistent with rfc1123.

but my focus is not dn vs hn...rather idn vs ihn...

james