Re: [dhcwg] Call for adoption: draft-boucadair-dhc-address-name-encoding-03

[<[e-mail]>]

Hi Tomek,
 
Please see inline. 

Cheers,
Med

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De 
>la part de Tomek Mrugalski
>Envoyé : lundi 10 décembre 2012 17:36
>À : Bernie Volz (volz)
>Cc : [e-mail]
>Objet : Re: [dhcwg] Call for adoption: 
>draft-boucadair-dhc-address-name-encoding-03
>
>On 10.12.2012 16:37, Bernie Volz (volz) wrote:
>> Regarding "Depending on the implementation, parsing nested option is
>> sometimes very easy thing to do", I wasn't really worried about the
>> client parsing. What wasn't that nice was the server's user interface
>> for configuring this. That was actually why I lowered its preference.
>> I can also envision that over time additional choices might be added
>> to the mix and that would just further complicate the user interface
>> for this -- one nice UI would be to allow the user to enter either an
>> address or FQDN and have the UI figure it out ... oh wait ...
>:)
>
>> Regarding the address-name-encoding issue (which ties into above UI
>> issue), I think we would want to keep it simple in that only a
>> limited set of syntaxes would be fully interoperable. If the DHCP
>> server administrator entered 0x4a7d8864, I would not expect that to
>> work across all clients (whereas 74.125.136.100) would. We would also
>> be clear that no special characters such as [ and ] would be included
>> for addresses.
>I was just an example, perhaps not a good one. I was not 
>suggesting that
>those particular examples should or should not be allowed, just trying
>to point out that proposed text is vague and I don't see any simple way
>to make it more precise. Requirements from section 3 allow any UTF-8
>text without spaces and nulls. According to current text, the following
>are valid names: foo@#$!%^&*#@, "\t\t\n", (a series of random 
>bytes that
>is not equal to 0 or 32). Even if you extend the definition (replace
>"The Name MUST NOT contain spaces or nulls." from Section 3 with
>something more precise), you head into other problems with UTF-8. There
>are many types of hyphens, dashes and minuses and similar looking
>characters and that's all even without leaving Europe. Now think about
>folks in Asia (or Poland for that matter - we do have accented
>characters over here. Yes, we do have upper-case and lower-case for
>them.). I have no idea how to code a validation what is a proper
>Chineese, Korean or Japanese name and what is not. The draft does not
>give me any clues in that regard, but requires me to validate it anyway
>("The DHCP client decoding an option in this format MUST validate the
>contents of the option.").
>


Med: I have considered updating the text with more validation rules (in addition to the ones already listed in -03 of the draft), but after reading the following (excerpt from RFC6055) I decided to not add more rules:

   By 1997, things had progressed to a state where it was necessary to
   clarify these areas of confusion.  "Clarifications to the DNS
   Specification" [RFC2181], Section 11 states:

      The DNS itself places only one restriction on the particular
      labels that can be used to identify resource records.  That one
      restriction relates to the length of the label and the full name.
      The length of any one label is limited to between 1 and 63 octets.
      A full domain name is limited to 255 octets (including the
      separators).  The zero length full name is defined as representing
      the root of the DNS tree, and is typically written and displayed
      as ".".  Those restrictions aside, any binary string whatever can
      be used as the label of any resource record.  Similarly, any
      binary string can serve as the value of any record that includes a
      domain name as some or all of its value (SOA, NS, MX, PTR, CNAME,
      and any others that may be added).  Implementations of the DNS
      protocols must not place any restrictions on the labels that can
      be used.

   Hence, it clarified that the restriction to letters, digits, and
   hyphens does not apply to DNS names in general, nor to records that
   include "domain names".  Hence, the "preferred" name syntax described
   in the original DNS specification [RFC1034] is indeed merely
   "preferred", not mandatory.

   Since there is no restriction even to ASCII, let alone letter-digit-
   hyphen use, DNS does not violate the subsequent IETF requirement to
   allow UTF-8 [RFC2277].