Subject: UTF-8 issues (Re: Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs)

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 02 Feb 2006 15:13:16 -0800

--On 2. februar 2006 16:38 -0500 Ralph Droms <[email-masked]> wrote:

> Included below is a summary list of the open issues in this package of
> documents:
>
> draft-ietf-dnsext-dhcid-rr-10.txt
> draft-ietf-dhc-ddns-resolution-10.txt
> draft-ietf-dhc-dhcpv6-fqdn-03.txt
> draft-ietf-dhc-fqdn-option-11.txt
> 11. UTF-8 character set usage (Harald Alvestrand, gen-art)
>
> Issue 11 needs some clarification; Harald, I hope you'll kick off a
> separate thread to discuss how to resolve this issue.
>
> - Ralph, for Olafur, Stig and Olaf

I'll try....
back in the days (November - how time flies), my comments on 
draft-ietf-dhc-fqdn-option-11.txt said:

>A smaller piece of missing material is this, from section 3.3.1 of the v4
>document:
>
>   Clients and servers SHOULD follow the character-set recommendations
>   of RFC 1034 [2] and RFC 1035 [3].  However, implementers SHOULD also
>   be aware that some client software could be using UTF-8 [10]
>   character encoding.  This specification does not require any support
>   for UTF-8.
>
>Given DNS experts' insistence that the DNS protocol does not place any
>limits on character sets, it would be good to have a clearer pointer to
>what recommendations are intended here.
>Given that it's in section 3.3.1 (Deprecated ASCII encoding), one can
>assume that this refers to a character set recommendation for characters 
in
>the ASCII encoding; a DNS encoded name should probably be used "as is", no
>matter what it contains (although it would be good if the doc said so).
>
>
>It's also unclear from the text whether or not there's a trailing dot on
>the name in the deprecated ASCII encoding (there's no need for one, since 
a
>non-FQDN name can only be one component, but other fields of use have done
>this in the past, so it's best to be clear that this field does not do so).

On the point of character set recommendations, I think what you should be 
pointing at is not 1034 and 1035 in general, but say that they SHOULD 
follow the recommendation of RFC 1035 section 2.3.1.
Since the rule was actually relaxed in RFC 1123 section 2.1, I think the 
sentence should say "SHOULD follow the character set recommendation of RFC 
1035 section 2.3.1, as modified by RFC 1123 section 2.1".

That's not an UTF-8 issue, but is a charset issue. The UTF-8 text is a 
cop-out (I think), but it's appropriate to cop-out here; you're basically 
saying "don't be surprised if people don't do what this spec recommends".

Does this make sense now?

                         Harald

---

From: Pekka Savola <[email-masked]>
Date: Wed, 8 Feb 2006 14:57:43 +0200 (EET)

On Thu, 2 Feb 2006, Ralph Droms wrote:
> Included below is a summary list of the open issues in this package 
> of documents:
>

Just checking, did you also check the following mails:

http://www1.ietf.org/mail-archive/web/ietf/current/msg38995.html
http://www1.ietf.org/mail-archive/web/ietf/current/msg38994.html
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05678.html

?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Feb 2006 11:41:51 -0700

> http://www1.ietf.org/mail-archive/web/ietf/current/msg38994.html

It's because of this one that I'm arguing that we should just not do the hash 
at all.   Algorithm-switching is expensive.