BIND 10 #2534: support minor cases for quoted character strings

BIND 10 Development do-not-reply at isc.org
Tue Feb 4 20:34:07 UTC 2014


#2534: support minor cases for quoted character strings
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:  muks
                Type:  task          |                       Status:
            Priority:  medium        |  reviewing
           Component:  libdns++      |                    Milestone:
            Keywords:                |  bind10-1.2-release-freeze
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DNS           |                 CVSS Scoring:
Estimated Difficulty:  4             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by kean):

 * owner:  kean => muks


Comment:

 > Even going by your description, it seems the representation above seems
 > incorrect; it is probably lacking a trailing double-quote (") to match
 > the beginning double-quote.
 Yeah sorry that was a typing error on my behalf. I will edit the reply
 above to correct that.

 > The lexer sees it as:
 >
 >  1. `Test-String` (a STRING token, followed by...)
 >  1. `"Test-String"` (a QSTRING token)
 >
 > Both parsed tokens' string values are `Test-String` respectively.
 >
 > This is because `"` is now a delimiter (to match BIND 9; see the ticket
 > description).
 If behaving the same way as BIND9 is the sole criteria, then fine, I see
 it your way. However, the ticket does also say "unless there is a good
 reason not to". I spent a lot of time reading and re-reading the RFC on
 {{{character-string}}} and nowhere does it indicate that {{{"}}} is a
 delimiter in a non-quoted string. RFC4408 does talk about concatenation of
 two quoted strings ({{{"string1" "string2"}}} is seen as
 {{{string1string2}}}). It is exactly this new behaviour of treating a
 {{{"}}} as a delimiter that is in question. If you decide it is a
 delimiter (and rather than referencing what BIND9 does please point out
 where in the RFC1035 it says it is - BIND9 can be interpreting the RFC
 incorrectly too) then your interpretation is correct. If it is not a
 delimiter, then I believe my interpretation is correct. If it doesn't
 matter what the RFC says and we want to reproduce BIND9's behaviour
 exactly, then your interpretation is of course also correct.

 I am absolutely sure that both BIND9 and your interpretation is what was
 *intended* by the RFC, but as I read it, that's not what was actually
 stated. I just don't know how pedantic one should be in interpreting
 RFC's. If we want to obey what the RFC states, rather than what it
 intends, then I'd like to see some evidence regarding {{{"}}} as a
 delimiter.

 It is worth noting that RFC4408 says that adjacent strings must be
 concatenated "without adding spaces" (section 3.1.3).

 > To you, I suggested a reading of `<character-string>` and the TXT RDATA
 It should be obvious that I have already done that, hence my original
 analysis.

 > You are asking if I adjusted the test providing the matching value just
 > to "accommodate a failing test". It's very insulting
 Sorry if my phrasing was interpreted as insult, none was intended I assure
 you.

 I am happy to accept things as they are if you either: a) point out in the
 RFC where it states that {{{"}}} is a delimiter or b) state that it is
 acceptable to do so simply because that is what BIND9 does and is probably
 what RFC1035 intended, even if it doesn't explicitly state it. If b) then
 please ignore my interpretation and feel free to merge and close.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2534#comment:15>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list