This is a discussion on UTF-8 issues (Re: Open issues in DHCP FQDN, DHCID and DDNS-DHCPRelated RFCs) - DNS ; --==========26E6B02998774739D698========== 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 ...
Content-Type: text/plain; charset=us-ascii; format=flowed
--On 2. februar 2006 16:38 -0500 Ralph Droms
> Included below is a summary list of the open issues in this package of
> 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
back in the days (November - how time flies), my comments on=20
>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  and RFC 1035 . However, implementers SHOULD also
> be aware that some client software could be using UTF-8 
> 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
-----END PGP SIGNATURE-----
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.