8 Srp
2013
8 Srp
'13
12:56
The addresses are parsed as a different token, so it shouldn't be allowed.
My point was that if it is either strict or relaxed, you don't have to
think about how to write it out.
If there are exceptions, it may work well but it also might be
annoying to configure, if you are not
able to guess whether it should or shouldn't be quoted instinctively.
I think if we require quoted string for values, it is a good compromise.
Things where it is obvious like paths, TSIG secret, CH TXT + NSID
related strings and I can't think
of what else. So this change would touch only several parameters, to
which most of the people use
quoted strings anyway?
Marek
On 8 August 2013 11:31, Ondřej Surý <ondrej.sury(a)nic.cz> wrote:
I would say that IP addresses are also identifier and
I would let them
unquoted.
The only problem I could think of is when you create token in form of
IP address, e.g.
interface {
10.0.0.1 {
address 10.0.0.1;
}
}
remotes {
10.0.0.10 {
address 10.0.0.10;
via 10.0.0.1;
}
}
Is is even possible to do so?
O.
On 8. 8. 2013, at 11:20, Marek Vavruša <marek.vavrusa(a)nic.cz> wrote:
This could work I think, a reasonable compromise.
Although some cases
are quite debatable.
remotes {
server0 {
address "127.0.0.1"; # ok here
via ipv4; # we use ipv4 interface identifier, so no quotes
via "[::cafe]" # direct value
}
}
Paths should be always quoted, time and size human readable values
should be unquoted (e.g. 1G not "1G"). But I would probably have to
think for a second whether should I quote it or not.
Marek
On 8 August 2013 11:06, Ondřej Surý <ondrej.sury(a)nic.cz> wrote:
> That has a simple solution - keep unquoted strings where you use strings as
> identifiers/tokens and use quoted strings if it's a value.
>
> Ondřej Surý
>
> On 8. 8. 2013, at 9:53, Peter Andreev <andreev.peter(a)gmail.com> wrote:
>
> 2013/8/7 Ondřej Caletka <ondrej.caletka(a)gmail.com>
>>
>> Hi Marek,
>>
>> Dne 6.8.2013 17:17, Marek Vavrusa napsal(a):
>>> I am thinking of disallowing unquoted strings in the next release, hope
>>> there's no big fan of this. Is there?
>>
>> Do you mean that config file should look like this?
>> ---cut---
>> remotes {
>> "slave0" {
>> address 203.0.113.1@53;
>> }
>> "slave1" {
>> address 198.51.100.1@53;
>> }
>> }
>>
>> zones {
>> "example.com" {
>> file "/etc/knot/example.com.zone";
>> xfr-out "slave0", "slave1";
>> notify-out "slave0", "slave1";
>> }
>> }
>> ---cut---
>
>
>
>>
>> In that case, I would vote for keeping unquoted strings allowed.
>> However, if quoting would be required only in possibly ambiguos fields,
>> I would have no problem with that.
>
>
> It will be ambiguously in itself.
>
> From my point of view, strictly following to defined rules is better. Of
> course, if rules are defined at all.
>
>>
>>
>> Cheers,
>> Ondřej Caletka
>> _______________________________________________
>> knot-dns-users mailing list
>> knot-dns-users(a)lists.nic.cz
>> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
>
>
>
>
> --
> Is there any problem Exterminatus cannot solve? I have not found one yet.
>
> _______________________________________________
> knot-dns-users mailing list
> knot-dns-users(a)lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
>
>
> _______________________________________________
> knot-dns-users mailing list
> knot-dns-users(a)lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
--
Ondřej Surý -- Chief Science Officer
-------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, Czech Republic
mailto:ondrej.sury@nic.cz http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------