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

["Bernie Volz \(volz\)" <[e-mail]>]

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

I'm confused by what this means in terms of changes to the draft?

This UTF-8 reference is in the following section:

3.3.1.  Deprecated ASCII Encoding

   A substantial population of clients implemented an earlier draft
   version of this specification, which permitted an ASCII encoding of
   the Domain Name field.  Server implementations SHOULD be aware that
   clients which send the Client FQDN option with the "E" bit set to 0
   are using an ASCII encoding of the Domain Name field.  Servers MAY be
   prepared to return an ASCII encoded version of the Domain Name field
   to such clients.  Servers that are not prepared to return an ASCII
   encoded version MUST ignore the Client FQDN option if the "E" bit is
   0.  The use of ASCII encoding in this option SHOULD be considered
   deprecated.

   A DHCP client which used ASCII encoding was permitted to suggest a
   single label if it was not configured with a fully-qualified name.
   Such clients send a single label as a series of ASCII characters in
   the Domain Name field, excluding the "." (dot) character.

   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.

This is *DEPRECATED* and all we wanted to point out is that this data is *NOT* just ASCII, although the encoding is called "ASCII encoding".

So, I think we want to drop or replace the LAST paragarph in section 3.3.1 of draft-ietf-dhc-fqdn-option-11.txt. Can folks suggest explicit text? But please remember all we're trying to do is give people a warning that this data is *NOT* necessarily strict ASCII although that it what the encoding was called. Perhaps one solution is to use a different term than "ASCII encoding", although I don't have a suggestion.

This really seems like a whole lot of effort for something that we're trying to get people NOT to use and is there for historical completeness (as it has been implemented since the FQDN option has been in active use for many many years even though there is no RFC).

Actually, I do now have a suggestion:

   Clients and servers SHOULD follow the character-set recommendations
   of RFC 1035 section 2.3.1.  However, implementers SHOULD also
   be aware that some client software may use other character-sets.
   This specification does not require support for any other
   character-sets.

If you don't like this, PLEASE SUGGEST ALTERNATIVE TEXT.

- Bernie 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Mark Andrews
> Sent: Thursday, February 02, 2006 6:58 PM
> To: Harald Tveit Alvestrand
> Cc: Olaf Kolkman; [e-mail]; dhcwg; Stig 
> Venaas; Ólafur Gu>mundsson /DNSEXT co-chair; Ralph Droms (rdroms)
> Subject: [dhcwg] Re: UTF-8 issues (Re: Open issues in DHCP 
> FQDN,DHCID and DDNS-DHCP Related RFCs) 
> 
> 
> > --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]
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 


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