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