Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--On 2. februar 2006 16:38 -0500 Ralph Droms 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=20
draft-ietf-dhc-fqdn-option-11.txt said:

>A smaller piece of missing material is this, from section 3.3.1 of the v4
> 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=20

>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=20

>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 =


On the point of character set recommendations, I think what you should be=20
pointing at is not 1034 and 1035 in general, but say that they SHOULD=20
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=20
sentence should say "SHOULD follow the character set recommendation of RFC=20
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=20
cop-out (I think), but it's appropriate to cop-out here; you're basically=20
saying "don't be surprised if people don't do what this spec recommends".

Does this make sense now?


Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

Version: GnuPG v1.4.2 (MingW32)



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.