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

[Mark Andrews <[e-mail]>]

> --On 2. februar 2006 16:38 -0500 Ralph Droms <[e-mail]> 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
> >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=20
> 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=20
> 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=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".

	RFC 1123 relaxed RFC 952 (and RFC 822 by implication) not
	RFC 1035.  It relaxed to *hostnames* not domain names.
	Domain names were already general enough to support mapping
	the expanded hostnames to domainnames using the null mapping.

	The rest follows from that relaxation.  RFC 1035 section
	2.3.1 is advisary based on the state of RFC 952 and RFC
	822 when it was written.

> 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".

	For IDN's I would recommend using the output of ToASCII.
 
> Does this make sense now?
> 
>                          Harald
> 
> 
> 
> --==========26E6B02998774739D698==========
> Content-Type: application/pgp-signature
> Content-Transfer-Encoding: 7bit
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> 
> iD8DBQFD4pIMOMj+2+WY0F4RAvZIAJ0X6mjMkoIMa7z8MyFxFx1RwWB0uACg6DyN
> s8bXurZt6s6CWcvE9ELeS/A=
> =I6Vk
> -----END PGP SIGNATURE-----
> 
> --==========26E6B02998774739D698==========--
> 
> 
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>