This is a discussion on Re: UTF-8 issues (Re: Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs) - DNS ; > --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 > > ...
> --On 2. februar 2006 16:38 -0500 Ralph Droms
> > 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  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".
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?
> Content-Type: application/pgp-signature
> Content-Transfer-Encoding: 7bit
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> iD8DBQFD4pIMOMj+2+WY0F4RAvZIAJ0X6mjMkoIMa7z8MyFxFx 1RwWB0uACg6DyN
> -----END PGP SIGNATURE-----
> to unsubscribe send a message to firstname.lastname@example.org with
> the word 'unsubscribe' in a single line as the message text body.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.