From melinda.shore at nomountain.net Wed Sep 2 02:21:17 2015 From: melinda.shore at nomountain.net (Melinda Shore) Date: Tue, 01 Sep 2015 18:21:17 -0800 Subject: [getdns-api] Error during "python setup.py install" In-Reply-To: References: Message-ID: <55E65D1D.5070605@nomountain.net> Hi, Shadrach: Thank you for reporting the problem. I've checked an updated setup.py script into the "develop" branch of our github repository (https://github.com/getdnsapi/getdns-python-bindings). The new version allows you to pass in an argument containing the root directory of your getdns installation. So, in your case you would build the Python bindings with python setup.py --with-getdns /home/deploy/build install Note that there is a space between the argument and its value rather than an equal sign. I've got a minor release with a few fixes coming out in the next week, but in the meantime you can pull this from the repo. Please let me know if you run into further problems. Thanks, Melinda From willem at nlnetlabs.nl Thu Sep 3 13:21:43 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 3 Sep 2015 15:21:43 +0200 Subject: [getdns-api] Remove IDNA functions from getdns? Message-ID: <55E84967.4010701@nlnetlabs.nl> Greetings getdns API spec developers, Currently the API defines two functions for IDNA 2008: getdns_convert_ulabel_to_alabel() and getdns_convert_alabel_to_ulabel() In our implementation, those are (more or less) direct mappings to the underlying idna_to_ascii_8z() and idna_to_unicode_8z8z() functions from the GNU IDN library. Applications that need to do IDNA conversions, might just as well use those functions from libidn directly instead of using the getdns facades. Because of those two functions our library has a dependency on libidn, but does not add any extra value on top of that library. Because of this, I propose to remove getdns_convert_ulabel_to_alabel() and getdns_convert_alabel_to_ulabel() from the API specification. What do you thing? -- Willem From willem at nlnetlabs.nl Thu Sep 3 13:31:26 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 3 Sep 2015 15:31:26 +0200 Subject: [getdns-api] Add a GETDNS_RETURN_NOT_IMPLEMENTED return code Message-ID: <55E84BAE.6030208@nlnetlabs.nl> Dear spec developers, Our implementation (at getdnsapi.net) now offers the possibility to compile without recursing resolution modus; for applications that are interested in stub resolution only. When recursing resolution mode is tried to be set, our library currently returns a GETDNS_RETURN_GENERIC_ERROR (by lack of something better). I would rather return something more specific that indicates unavailability of the requested configuration. The GETDNS_RETURN_NOT_IMPLEMENTED return code would fit this situation much better and could also be used with currently unimplemented features (such as TSIG support and call_debugging etc). How do you feel about this? -- Willem From shane at time-travellers.org Thu Sep 3 14:06:35 2015 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 3 Sep 2015 14:06:35 +0000 Subject: [getdns-api] Remove IDNA functions from getdns? In-Reply-To: <55E84967.4010701@nlnetlabs.nl> References: <55E84967.4010701@nlnetlabs.nl> Message-ID: <20150903140635.479da131@casual> Willem, On Thu, 3 Sep 2015 15:21:43 +0200 Willem Toorop wrote: > Because of this, I propose to remove getdns_convert_ulabel_to_alabel() > and getdns_convert_alabel_to_ulabel() from the API specification. I think it's good, especially if it gets rid of the dependency on libidn. ;) Cheers, -- Shane From asullivan at dyn.com Thu Sep 3 14:32:41 2015 From: asullivan at dyn.com (Andrew Sullivan) Date: Thu, 3 Sep 2015 10:32:41 -0400 Subject: [getdns-api] Remove IDNA functions from getdns? In-Reply-To: <55E84967.4010701@nlnetlabs.nl> References: <55E84967.4010701@nlnetlabs.nl> Message-ID: <20150903143239.GR5312@dyn.com> On Thu, Sep 03, 2015 at 03:21:43PM +0200, Willem Toorop wrote: > > Currently the API defines two functions for IDNA 2008: > getdns_convert_ulabel_to_alabel() and getdns_convert_alabel_to_ulabel() > > In our implementation, those are (more or less) direct mappings to the > underlying idna_to_ascii_8z() and idna_to_unicode_8z8z() functions from > the GNU IDN library. Applications that need to do IDNA conversions, > might just as well use those functions from libidn directly instead of > using the getdns facades. Because of those two functions our library > has a dependency on libidn, but does not add any extra value on top of > that library. The purpose of getdns, though, was to give applications a one-stop shop to do all these DNSy things, and IDNA is part of that. After all, in some sense every other thing in getdns can be achieved by lower-level functions as well. Best regards, A -- Andrew Sullivan Dyn asullivan at dyn.com From willem at nlnetlabs.nl Thu Sep 3 15:22:36 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 3 Sep 2015 17:22:36 +0200 Subject: [getdns-api] Remove IDNA functions from getdns? In-Reply-To: <20150903143239.GR5312@dyn.com> References: <55E84967.4010701@nlnetlabs.nl> <20150903143239.GR5312@dyn.com> Message-ID: <55E865BC.3060709@nlnetlabs.nl> Op 03-09-15 om 16:32 schreef Andrew Sullivan: > On Thu, Sep 03, 2015 at 03:21:43PM +0200, Willem Toorop wrote: >> >> Currently the API defines two functions for IDNA 2008: >> getdns_convert_ulabel_to_alabel() and getdns_convert_alabel_to_ulabel() >> >> In our implementation, those are (more or less) direct mappings to the >> underlying idna_to_ascii_8z() and idna_to_unicode_8z8z() functions from >> the GNU IDN library. Applications that need to do IDNA conversions, >> might just as well use those functions from libidn directly instead of >> using the getdns facades. Because of those two functions our library >> has a dependency on libidn, but does not add any extra value on top of >> that library. > > The purpose of getdns, though, was to give applications a one-stop > shop to do all these DNSy things, and IDNA is part of that. After > all, in some sense every other thing in getdns can be achieved by > lower-level functions as well. I don't know, getdns has some pretty unique features :) But even if all could be offered by other lower-level libraries, those other functionalities are all closely integrated in a coherent body. Not with IDNA support, which is just offered through those two - completely loose from everything else - functions. Perhaps it would be better to offer IDNA in a more getdns way? For example through an extension, which will process query names ulabel to alabel and return processed dname's converted from alabels to ulabels in the response dict? Best regards, -- Willem From asullivan at dyn.com Thu Sep 3 18:34:54 2015 From: asullivan at dyn.com (Andrew Sullivan) Date: Thu, 3 Sep 2015 14:34:54 -0400 Subject: [getdns-api] Remove IDNA functions from getdns? In-Reply-To: <55E865BC.3060709@nlnetlabs.nl> References: <55E84967.4010701@nlnetlabs.nl> <20150903143239.GR5312@dyn.com> <55E865BC.3060709@nlnetlabs.nl> Message-ID: <20150903183452.GS5312@dyn.com> On Thu, Sep 03, 2015 at 05:22:36PM +0200, Willem Toorop wrote: > Perhaps it would be better to offer IDNA in a more getdns way? For > example through an extension, which will process query names ulabel to > alabel and return processed dname's converted from alabels to ulabels in > the response dict? I think the idea was that an application can often need the U-label of an A-label or conversely, but nobody could think of anything else an application would need. Is there anything else? A -- Andrew Sullivan Dyn asullivan at dyn.com From jhildebr at cisco.com Thu Sep 3 20:57:27 2015 From: jhildebr at cisco.com (Joe Hildebrand (jhildebr)) Date: Thu, 3 Sep 2015 20:57:27 +0000 Subject: [getdns-api] Remove IDNA functions from getdns? In-Reply-To: <20150903183452.GS5312@dyn.com> References: <55E84967.4010701@nlnetlabs.nl> <20150903143239.GR5312@dyn.com> <55E865BC.3060709@nlnetlabs.nl> <20150903183452.GS5312@dyn.com> Message-ID: <71182702-B46F-4839-BEFD-9EE2A9F84E31@cisco.com> I think the current IDN API may be at the wrong level of granularity. I want to be able to pass in a UTF-8 encoded domain name, and have the library do whatever conversions are needed, like getaddrinfo does (now): >From http://man7.org/linux/man-pages/man3/getaddrinfo.3.html : Extensions to getaddrinfo() for Internationalized Domain Names Starting with glibc 2.3.4, getaddrinfo() has been extended to selectively allow the incoming and outgoing hostnames to be transparently converted to and from the Internationalized Domain Name (IDN) format (see RFC 3490, Internationalizing Domain Names in Applications (IDNA)). Four new flags are defined: AI_IDN If this flag is specified, then the node name given in node is converted to IDN format if necessary. The source encoding is that of the current locale. If the input name contains non-ASCII characters, then the IDN encoding is used. Those parts of the node name (delimited by dots) that contain non-ASCII characters are encoded using ASCII Compatible Encoding (ACE) before being passed to the name resolution functions. AI_CANONIDN After a successful name lookup, and if the AI_CANONNAME flag was specified, getaddrinfo() will return the canonical name of the node corresponding to the addrinfo structure value passed back. The return value is an exact copy of the value returned by the name resolution function. If the name is encoded using ACE, then it will contain the xn-- prefix for one or more components of the name. To convert these components into a readable form the AI_CANONIDN flag can be passed in addition to AI_CANONNAME. The resulting string is encoded using the current locale's encoding. AI_IDN_ALLOW_UNASSIGNED, AI_IDN_USE_STD3_ASCII_RULES Setting these flags will enable the IDNA_ALLOW_UNASSIGNED (allow unassigned Unicode code points) and IDNA_USE_STD3_ASCII_RULES (check output to make sure it is a STD3 conforming hostname) flags respectively to be used in the IDNA handling. -- Joe Hildebrand On 9/3/15, 12:34 PM, "spec on behalf of Andrew Sullivan" wrote: >On Thu, Sep 03, 2015 at 05:22:36PM +0200, Willem Toorop wrote: >> Perhaps it would be better to offer IDNA in a more getdns way? For >> example through an extension, which will process query names ulabel to >> alabel and return processed dname's converted from alabels to ulabels in >> the response dict? > >I think the idea was that an application can often need the U-label of >an A-label or conversely, but nobody could think of anything else an >application would need. > >Is there anything else? > >A > >-- >Andrew Sullivan >Dyn >asullivan at dyn.com >_______________________________________________ >spec mailing list >spec at getdnsapi.net From paul.hoffman at vpnc.org Thu Sep 3 17:27:27 2015 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Thu, 03 Sep 2015 10:27:27 -0700 Subject: [getdns-api] Remove IDNA functions from getdns? In-Reply-To: <55E865BC.3060709@nlnetlabs.nl> References: <55E84967.4010701@nlnetlabs.nl> <20150903143239.GR5312@dyn.com> <55E865BC.3060709@nlnetlabs.nl> Message-ID: On 3 Sep 2015, at 8:22, Willem Toorop wrote: > Op 03-09-15 om 16:32 schreef Andrew Sullivan: >> On Thu, Sep 03, 2015 at 03:21:43PM +0200, Willem Toorop wrote: >>> >>> Currently the API defines two functions for IDNA 2008: >>> getdns_convert_ulabel_to_alabel() and >>> getdns_convert_alabel_to_ulabel() >>> >>> In our implementation, those are (more or less) direct mappings to >>> the >>> underlying idna_to_ascii_8z() and idna_to_unicode_8z8z() functions >>> from >>> the GNU IDN library. Applications that need to do IDNA conversions, >>> might just as well use those functions from libidn directly instead >>> of >>> using the getdns facades. Because of those two functions our >>> library >>> has a dependency on libidn, but does not add any extra value on top >>> of >>> that library. >> >> The purpose of getdns, though, was to give applications a one-stop >> shop to do all these DNSy things, and IDNA is part of that. After >> all, in some sense every other thing in getdns can be achieved by >> lower-level functions as well. > > I don't know, getdns has some pretty unique features :) But even if > all > could be offered by other lower-level libraries, those other > functionalities are all closely integrated in a coherent body. Not > with > IDNA support, which is just offered through those two - completely > loose > from everything else - functions. > > Perhaps it would be better to offer IDNA in a more getdns way? For > example through an extension, which will process query names ulabel to > alabel and return processed dname's converted from alabels to ulabels > in > the response dict? I'm with Andrew on this one. getdns is supposed to be a modern DNS API for applications, and IDNA is certainly part of the modern DNS. The current functions are certainly more understandable to a typical programmer than an extension. The dependency on libidn would still be there, of course. --Paul Hoffman From willem at nlnetlabs.nl Fri Sep 4 09:24:24 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 4 Sep 2015 11:24:24 +0200 Subject: [getdns-api] getdns 0.3.2 released Message-ID: <55E96348.2090406@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear All, We have a bugfix release of getdns: version 0.3.2. The most prominent fix is fallback handling of stateful transports. Besides bugfixes, we have two new configure options. With - --enable-stub-only getdns will be compiled without libunbound. You can then only use getdns in stub resolution mode and this is also the default resolution mode. The --with-getdns_query option will build and install the getdns_query tool that is part of the getdns test suite, but might have use cases outside that setting too link : https://getdnsapi.net/dist/getdns-0.3.2.tar.gz md5 : 93c8d1149c6268798d2f000bc8c3a0d1 sha1 : 3f3e4b3ad2b9e9a7724e618f2a4d51f07653d16a pgp sig: https://getdnsapi.net/dist/getdns-0.3.2.tar.gz.asc ChangeLog =========: * 2015-09-04: Version 0.3.2 * Fix returned upstreams list by getdns_context_get_api_information() * Fix some autoconf issues when srcdir != builddir * Fix remove build date from manpage version for reproducable builds * Fix transport fallback issue, added transport fallback test script * Fix string bindata's need not contain trailing zero byte * --enable-stub-only configure option for stub only operation. Stub mode will be the default. Removes the dependency on libunbound * --with-getdns_query compiles and installs the getdns_query tool too * Fix assert on context destruction from a callback in stub mode too * Use a thread instead of a process for running the unbound event loop -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV6WNHAAoJEOX4+CEvd6SYj8gQAJJeKofF4N1Eer1iZsGR8S0B 1PDnRXUnqXs2tOBwbIhXY8RSwOg7KnqiW2OS+kUGX3o1xD6fpC1tvoUaR5TD7xlZ 0jrKtBmnQhVk/whT+j0taWNoArPMsgfZQzzUiLHUo/cjq8OMlNLlp2CQhRYxXuRx Q4sGjpnAzAF+gjab0K7MxgMz9BsXsgDUsXWu7pACpKV3Vhi5q0JyE2m73kc0M7aO RJwecRsn5T+oGYXQPR6lc3ZevTI2UCKj4lzjmSjfDTtbeaZvZC1Fqw/DjJ/Yp1iN fQxPmguFuuZ9u1m9iM8OoI0vlSHbPNcLl0p4tUWHsnH/UAgkECPhInBi4c8v61BC xIVC+UYTX2zoHMjPRDS/V6GX9Qp8Cd/jgdY03QQCKOiJ4LYOinBIlIpKT5OppfNm IEGEWa00jgKONF10wetGhjRjRTtypC5aeScClJCfMJoTUks9kLnr8vp5/c9rB3EF 8kPWz5t+l11He76k0UwSed5x+fKzMPp7Q0dqA+/vBHm4Bz7V6C6l+Cjvxp4+ieXv /hSzTx+mWMceh5lpghlt0Jatv0+9mUL75wQRMNeQ/ZVOg0soDZWnw2TbEYdVIuZa 2+2uyNfD03IwFlkPVwIhZuM2A3+XokxRSxbQKiCMWyCgazSSbuL/cmOiEabZG0cE jGk93BXZQ0YNDEy/4KCI =ewea -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Fri Sep 4 09:35:28 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 4 Sep 2015 11:35:28 +0200 Subject: [getdns-api] Remove IDNA functions from getdns? In-Reply-To: <71182702-B46F-4839-BEFD-9EE2A9F84E31@cisco.com> References: <55E84967.4010701@nlnetlabs.nl> <20150903143239.GR5312@dyn.com> <55E865BC.3060709@nlnetlabs.nl> <20150903183452.GS5312@dyn.com> <71182702-B46F-4839-BEFD-9EE2A9F84E31@cisco.com> Message-ID: <55E965E0.7010800@nlnetlabs.nl> Thank you Joe, Yes, the getaddrinfo approach is precisely what I meant. I.e. extensions are to getdns what flags are to getaddrinfo. Andrew & Paul, do you still think that approach would be too complex for the typical programmer? If getaddrinfo is doing it this way, why shouldn't we? -- Willem Op 03-09-15 om 22:57 schreef Joe Hildebrand (jhildebr): > I think the current IDN API may be at the wrong level of granularity. I want to be able to pass in a UTF-8 encoded domain name, and have the library do whatever conversions are needed, like getaddrinfo does (now): > >>From http://man7.org/linux/man-pages/man3/getaddrinfo.3.html : > > Extensions to getaddrinfo() for Internationalized Domain Names > Starting with glibc 2.3.4, getaddrinfo() has been extended to > selectively allow the incoming and outgoing hostnames to be > transparently converted to and from the Internationalized Domain Name > (IDN) format (see RFC 3490, Internationalizing Domain Names in > Applications (IDNA)). Four new flags are defined: > > AI_IDN If this flag is specified, then the node name given in node is > converted to IDN format if necessary. The source encoding is > that of the current locale. > > If the input name contains non-ASCII characters, then the IDN > encoding is used. Those parts of the node name (delimited by > dots) that contain non-ASCII characters are encoded using > ASCII Compatible Encoding (ACE) before being passed to the > name resolution functions. > > AI_CANONIDN > After a successful name lookup, and if the AI_CANONNAME flag > was specified, getaddrinfo() will return the canonical name of > the node corresponding to the addrinfo structure value passed > back. The return value is an exact copy of the value returned > by the name resolution function. > > If the name is encoded using ACE, then it will contain the > xn-- prefix for one or more components of the name. To > convert these components into a readable form the AI_CANONIDN > flag can be passed in addition to AI_CANONNAME. The resulting > string is encoded using the current locale's encoding. > > AI_IDN_ALLOW_UNASSIGNED, AI_IDN_USE_STD3_ASCII_RULES > Setting these flags will enable the IDNA_ALLOW_UNASSIGNED > (allow unassigned Unicode code points) and > IDNA_USE_STD3_ASCII_RULES (check output to make sure it is a > STD3 conforming hostname) flags respectively to be used in the > IDNA handling. > > From shadrach.r at gmail.com Fri Sep 4 11:12:06 2015 From: shadrach.r at gmail.com (shadrach rajasekar) Date: Fri, 4 Sep 2015 16:42:06 +0530 Subject: [getdns-api] Error during "python setup.py install" In-Reply-To: <55E65D1D.5070605@nomountain.net> References: <55E65D1D.5070605@nomountain.net> Message-ID: Hi Melinda, Thank You for the fix. I am able to install it successfully now. I have our Caching DNS server running on one of our servers. I have tried below 2 procedures to test the integration of getdns with our Caching server. But it is not successful. Could you please correct me where I go wrong Proc 1: ------- ./getdns_query @ www.zone.com A ( or ) ./getdns_query @ www.zone.com A The query is *NOT successful* and i get below timeout response. SYNC response: { "answer_type": GETDNS_NAMETYPE_DNS, "just_address_answers": [], "replies_full": [], "replies_tree": [], "status": GETDNS_RESPSTATUS_ALL_TIMEOUT } Response code was: GOOD. Status was: All queries for the name timed out All done. The query is not reaching our Caching server which runs of port 53. Proc 2 ---------- with python ./get-ip.py @:53 www.zone.com A I get core dump error Segmentation fault (core dumped) We are testing caching server in one of the trending DDI solutions. Currently we are planning to automate the testing procedures. We identified getdns would be useful in doing so. Can you please explain us how getdns would be useful in doing so. Regards, Shadrach On Wed, Sep 2, 2015 at 7:51 AM, Melinda Shore wrote: > Hi, Shadrach: > > Thank you for reporting the problem. I've checked an updated > setup.py script into the "develop" branch of our github > repository (https://github.com/getdnsapi/getdns-python-bindings). > The new version allows you to pass in an argument containing > the root directory of your getdns installation. So, > in your case you would build the Python bindings with > > python setup.py --with-getdns /home/deploy/build install > > Note that there is a space between the argument and its > value rather than an equal sign. > > I've got a minor release with a few fixes coming out in the > next week, but in the meantime you can pull this from the > repo. Please let me know if you run into further problems. > > Thanks, > > Melinda > -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at nlnetlabs.nl Fri Sep 4 11:48:26 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 4 Sep 2015 13:48:26 +0200 Subject: [getdns-api] Error during "python setup.py install" In-Reply-To: References: <55E65D1D.5070605@nomountain.net> Message-ID: <55E9850A.1010105@nlnetlabs.nl> Hello Shadrach, Try using the -s option to use stub mode with getdns_query (default is full recursion) ./getdns_query -s @8.8.8.8 at 53 www.zone.com A SYNC response: { "answer_type": GETDNS_NAMETYPE_DNS, "canonical_name": , "just_address_answers": [ { "address_data": , "address_type": }, { "address_data": , "address_type": } ], "replies_full": [ ], "replies_tree": [ { "additional": [ { "do": 0, "extended_rcode": 0, "rdata": { "rdata_raw": }, "type": GETDNS_RRTYPE_OPT, "udp_payload_size": 512, "version": 0, "z": 0 } ], "answer": [ { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "cname": , "rdata_raw": }, "ttl": 1717, "type": GETDNS_RRTYPE_CNAME }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "ipv4_address": , "rdata_raw": }, "ttl": 1717, "type": GETDNS_RRTYPE_A }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "ipv4_address": , "rdata_raw": }, "ttl": 1717, "type": GETDNS_RRTYPE_A } ], "answer_type": GETDNS_NAMETYPE_DNS, "authority": [], "canonical_name": , "header": { "aa": 0, "ad": 0, "ancount": 3, "arcount": 1, "cd": 0, "id": 367, "nscount": 0, "opcode": GETDNS_OPCODE_QUERY, "qdcount": 1, "qr": 1, "ra": 1, "rcode": GETDNS_RCODE_NOERROR, "rd": 1, "tc": 0, "z": 0 }, "question": { "qclass": GETDNS_RRCLASS_IN, "qname": , "qtype": GETDNS_RRTYPE_A } } ], "status": GETDNS_RESPSTATUS_GOOD } Response code was: GOOD. Status was: At least one response was returned All done. -- Willem Op 04-09-15 om 13:12 schreef shadrach rajasekar: > Hi Melinda, > > Thank You for the fix. I am able to install it successfully now. > > I have our Caching DNS server running on one of our servers. > > I have tried below 2 procedures to test the integration of getdns with > our Caching server. But it is not successful. Could you please correct > me where I go wrong > > Proc 1: > ------- > > ./getdns_query @ www.zone.com A ( or ) > ./getdns_query @ www.zone.com A > > The query is *NOT successful* and i get below timeout response. > > SYNC response: > { > "answer_type": GETDNS_NAMETYPE_DNS, > "just_address_answers": [], > "replies_full": [], > "replies_tree": [], > "status": GETDNS_RESPSTATUS_ALL_TIMEOUT > } > Response code was: GOOD. Status was: All queries for the name timed out > > All done. > > The query is not reaching our Caching server which runs of port 53. > > Proc 2 > ---------- > with python > > ./get-ip.py @:53 www.zone.com A > > I get core dump error > > Segmentation fault (core dumped) > > We are testing caching server in one of the trending DDI solutions. > Currently we are planning to automate the testing procedures. We > identified getdns would be useful in doing so. Can you please explain us > how getdns would be useful in doing so. > > Regards, > Shadrach > > On Wed, Sep 2, 2015 at 7:51 AM, Melinda Shore > > wrote: > > Hi, Shadrach: > > Thank you for reporting the problem. I've checked an updated > setup.py script into the "develop" branch of our github > repository (https://github.com/getdnsapi/getdns-python-bindings). > The new version allows you to pass in an argument containing > the root directory of your getdns installation. So, > in your case you would build the Python bindings with > > python setup.py --with-getdns /home/deploy/build install > > Note that there is a space between the argument and its > value rather than an equal sign. > > I've got a minor release with a few fixes coming out in the > next week, but in the meantime you can pull this from the > repo. Please let me know if you run into further problems. > > Thanks, > > Melinda > > > > > _______________________________________________ > spec mailing list > spec at getdnsapi.net > From asullivan at dyn.com Fri Sep 4 13:28:40 2015 From: asullivan at dyn.com (Andrew Sullivan) Date: Fri, 4 Sep 2015 09:28:40 -0400 Subject: [getdns-api] Remove IDNA functions from getdns? In-Reply-To: <55E965E0.7010800@nlnetlabs.nl> References: <55E84967.4010701@nlnetlabs.nl> <20150903143239.GR5312@dyn.com> <55E865BC.3060709@nlnetlabs.nl> <20150903183452.GS5312@dyn.com> <71182702-B46F-4839-BEFD-9EE2A9F84E31@cisco.com> <55E965E0.7010800@nlnetlabs.nl> Message-ID: <20150904132839.GC13318@dyn.com> On Fri, Sep 04, 2015 at 11:35:28AM +0200, Willem Toorop wrote: > Thank you Joe, > > Yes, the getaddrinfo approach is precisely what I meant. I.e. > extensions are to getdns what flags are to getaddrinfo. Andrew & Paul, > do you still think that approach would be too complex for the typical > programmer? If getaddrinfo is doing it this way, why shouldn't we? I have no objection, myself. A -- Andrew Sullivan Dyn asullivan at dyn.com From paul.hoffman at vpnc.org Fri Sep 4 15:26:45 2015 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Fri, 04 Sep 2015 09:26:45 -0600 Subject: [getdns-api] Remove IDNA functions from getdns? In-Reply-To: <55E965E0.7010800@nlnetlabs.nl> References: <55E84967.4010701@nlnetlabs.nl> <20150903143239.GR5312@dyn.com> <55E865BC.3060709@nlnetlabs.nl> <20150903183452.GS5312@dyn.com> <71182702-B46F-4839-BEFD-9EE2A9F84E31@cisco.com> <55E965E0.7010800@nlnetlabs.nl> Message-ID: <96AB46ED-1BB6-4323-805E-0C7C576B59D6@vpnc.org> Unless I'm misunderstanding the extension idea, this would limit the programmer to converting while doing a lookup. My original design allows the programmer to capture the return of the conversion and use it later, such as to do name matching in PKIX validation. --Paul Hoffman From asullivan at dyn.com Fri Sep 4 15:52:14 2015 From: asullivan at dyn.com (Andrew Sullivan) Date: Fri, 4 Sep 2015 11:52:14 -0400 Subject: [getdns-api] Remove IDNA functions from getdns? In-Reply-To: <96AB46ED-1BB6-4323-805E-0C7C576B59D6@vpnc.org> References: <55E84967.4010701@nlnetlabs.nl> <20150903143239.GR5312@dyn.com> <55E865BC.3060709@nlnetlabs.nl> <20150903183452.GS5312@dyn.com> <71182702-B46F-4839-BEFD-9EE2A9F84E31@cisco.com> <55E965E0.7010800@nlnetlabs.nl> <96AB46ED-1BB6-4323-805E-0C7C576B59D6@vpnc.org> Message-ID: <20150904155212.GF13318@dyn.com> On Fri, Sep 04, 2015 at 09:26:45AM -0600, Paul Hoffman wrote: > Unless I'm misunderstanding the extension idea, this would limit the > programmer to converting while doing a lookup. My original design > allows the programmer to capture the return of the conversion and > use it later, such as to do name matching in PKIX validation. Oh. Yes, I think we want that too. In particular, the "convert it later" stuff allows the application to leave its data in whatever form it got it until it needs to display (or lookup). The latter of course happens at lookup, but the former could easily not happen until much later or not at all. So there'd be no reason to do any conversion until display. A -- Andrew Sullivan Dyn asullivan at dyn.com From melinda.shore at nomountain.net Fri Sep 4 17:34:17 2015 From: melinda.shore at nomountain.net (Melinda Shore) Date: Fri, 04 Sep 2015 09:34:17 -0800 Subject: [getdns-api] Error during "python setup.py install" In-Reply-To: References: <55E65D1D.5070605@nomountain.net> Message-ID: <55E9D619.3020901@nomountain.net> On 9/4/15 3:12 AM, shadrach rajasekar wrote: > ./get-ip.py @:53 www.zone.com A > > I get core dump error > > Segmentation fault (core dumped) If this is the get-ip.py script in the examples directory, it's just a very simple script that takes a list of domain names to resolve and optionally does dnssec validation on them: Usage: get-ip.py [-s] [-4|-6] ... -s: only return DNSSEC secured answers -4: only return IPv4 address answers -6: only return IPv6 address answers -4 and -6 are mutually exclusive. If both are specified, IPv6 wins. However, it shouldn't dump core when fed arguments it doesn't recognize, so I'll take care of that. Melinda -- Melinda Shore No Mountain Software melinda.shore at nomountain.net "Software longa, hardware brevis." From melinda.shore at nomountain.net Fri Sep 4 19:14:26 2015 From: melinda.shore at nomountain.net (Melinda Shore) Date: Fri, 04 Sep 2015 11:14:26 -0800 Subject: [getdns-api] Error during "python setup.py install" In-Reply-To: References: <55E65D1D.5070605@nomountain.net> Message-ID: <55E9ED92.9020105@nomountain.net> On 9/4/15 3:12 AM, shadrach rajasekar wrote: > ./get-ip.py @:53 www.zone.com A I'm afraid that I'm not getting a segfault here. The bogus argument are being passed through to libgetdns correctly and libgetdns is correctly returning GETDNS_RESPSTATUS_NO_NAME: fedora21$ python ./get-ip.py @8.8.8.8:53 www.google.com A @8.8.8.8:53: getdns.address() returned error: 901 www.google.com: IPv6 2607:f8b0:400a:806::2004 www.google.com: IPv4 216.58.209.4 A: getdns.address() returned error: 901 If you could run it inside gdb and get a traceback from the segfault that could help us pin it down. Also, please confirm that you're running libgetdns 0.3.1. Thanks, Melinda -- Melinda Shore No Mountain Software melinda.shore at nomountain.net "Software longa, hardware brevis." From willem at nlnetlabs.nl Wed Sep 9 11:56:20 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 9 Sep 2015 13:56:20 +0200 Subject: [getdns-api] getdns 0.3.3 quickfix release Message-ID: <55F01E64.7030204@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear All, We have a fast-track single bugfix release of getdns: version 0.3.3. The native DNSSEC validation, which has been in getdns since version 0.3.0, failed to validate direct CNAME queries. This affected direct CNAME queries only. Queries that have CNAME redirections included are not affected. Also the (default) RECURSING resolution mode is not affected, except when used in combination with the dnssec_return_validation_chain extension. When a query is done for a valid CNAME in either STUB resolution mode or with the dnssec_return_validation_chain extension, with getdns version 0.3.0, 0.3.1 or 0.3.2, the returned dnssec_status will be GETDNS_DNSSEC_BOGUS always. This release has this issue resolved. A patch for getdns version 0.3.0, 0.3.1 and 0.3.2 is provided here: https://getdnsapi.net/patches/dnssec-cname-query-validation.patch Because of the smallness of the change and the severity of the flaw, we've decided to bypass a release candidate and do the release immediately. link: http://www.getdnsapi.net/dist/getdns-0.3.3.tar.gz md5 : 566f05047ece7ef6f113a8a4ba043531 sha1: 2de46171d1b39952e8f419979eda86fcec4ba839 pgp : http://www.getdnsapi.net/dist/getdns-0.3.3.tar.gz.asc ChangeLog ========= * 2015-09-09: Version 0.3.3 * Fix clearing upstream events on shutdown * Fix dnssec validation of direct CNAME queries. Thanks Simson L. Garfinkel. * Fix get_api_information():version_string also for release candidates -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV8B5kAAoJEOX4+CEvd6SYgYsP/j7Ir1Jp04hoVqcmrXQZdez8 OFfXobLCP2wovpPxvvVF/0DBz6jUj4FXpvGk46XyZa54IK+TwqnWXH1/HcE7gQgG MabiIJM0iqfRJXCpIf4wUxOTPHT/NEAon7ScPWWWpS5xLvGLAUFQKQfTW3NYD3SF 1EeLAskMBkxw8pr7QMuTNAqHHsWuung82hOPCJpE7OcK+dmpTXjXg2nabMvEqtHI mARsutswUp4wj4+O2iKBnSTUSE+i/eLAX3zvHu/ZZMou67K1cowhSR5hgzL9J/86 XM0DJESH/rdxZE+WzQHe1MI+t1vx0YcviCbtgsBGY8S4BESam5svMPAI5x/iUx3F bkkAKTnRVqg773oavywowGe+YUM3Dr6lwYrylPtudZ7Ks5r5+GQY7q0NBIvlXUVc CnsmGSQLvdt1u634Eh1qOZeCT0O/Gt8L3RfLQhsObEBdjoOnsk7WgYO6dJAbfnb4 mqT2vp20S8uKvQm+Xcv1T/bFfLGszfIlOB157Vzq2Uk5CW9Od9eTXeldcLUUNr2C fwqUlIqMypJcnShgBWMUNPQ641Lg3I50n4BWprK1hncj0q/jBU7LRx1HFmYsR16s X5KVSCc1OOxD5/DObxHi37/OBsjz9Fr5d5pvgx83iAmiJtKzo5UwFbF4Ciq5gIML 2wkZeMH+HAIl4uYt45Dz =t9Vh -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Fri Sep 18 08:42:04 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 18 Sep 2015 10:42:04 +0200 Subject: [getdns-api] Add a GETDNS_RETURN_NOT_IMPLEMENTED return code In-Reply-To: <55E84BAE.6030208@nlnetlabs.nl> References: <55E84BAE.6030208@nlnetlabs.nl> Message-ID: <55FBCE5C.6020009@nlnetlabs.nl> Ok, I will append the return code to section 5.2. Like this: GETDNS_RETURN_NOT_IMPLEMENTED The library did not have the requested API feature implemented. Object now or forever hold your peace ;) -- Willem Op 03-09-15 om 15:31 schreef Willem Toorop: > Dear spec developers, > > Our implementation (at getdnsapi.net) now offers the possibility to > compile without recursing resolution modus; for applications that are > interested in stub resolution only. When recursing resolution mode is > tried to be set, our library currently returns a > GETDNS_RETURN_GENERIC_ERROR (by lack of something better). I would > rather return something more specific that indicates unavailability of > the requested configuration. > > The GETDNS_RETURN_NOT_IMPLEMENTED return code would fit this situation > much better and could also be used with currently unimplemented features > (such as TSIG support and call_debugging etc). > > How do you feel about this? > > -- Willem > _______________________________________________ > spec mailing list > spec at getdnsapi.net > From willem at nlnetlabs.nl Fri Sep 18 09:13:29 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 18 Sep 2015 11:13:29 +0200 Subject: [getdns-api] Getting from dicts by subscript operator Message-ID: <55FBD5B9.1020706@nlnetlabs.nl> Dear getdns API designers, Getting into the specific parts of getdns data structures (notably the response dict) can be cumbersome in C. Take for example this (relatively short) example on how to get to the AD bit of the first reply of a response: getdns_list *replies_tree; getdns_dict *reply; getdns_dict *header; uint32_t ad; if ((r = getdns_dict_get_list(resp, "replies_tree", &replies_tree))) return r; else if ((r = getdns_list_get_dict(replies_tree, 0, &reply))) return r; else if ((r = getdns_dict_get_dict(reply, "header", &header))) return r; else if ((r = getdns_dict_get_int(header, "ad", &ad))) return r; Also, getting data members by text strings like getdns does, is unconventional in C libraries, but makes getdns very flexible and easy to extend. It also maps very well to modern scripting languages (python, javascript, perl, ruby etc.). Why don't we take this approach one step further, and get to the data members by allowing the text strings to contain subscript operators into the sub-dicts and sub-lists? To do the same as the example above with subscript operator: uint32_t ad; if ((r = getdns_dict_get_int(resp, "replies_tree[0][header][ad]", &ad))) return r; The conciseness and thereby clarity and readability is increasingly more prominent with more involved examples. What do you think? -- Willem From dwessels at verisign.com Mon Sep 21 16:26:20 2015 From: dwessels at verisign.com (Wessels, Duane) Date: Mon, 21 Sep 2015 16:26:20 +0000 Subject: [getdns-api] Getting from dicts by subscript operator In-Reply-To: <55FBD5B9.1020706@nlnetlabs.nl> References: <55FBD5B9.1020706@nlnetlabs.nl> Message-ID: <67E636A7-12E7-467D-B14A-E04A8C1690BF@verisign.com> Willem, I think this idea is really great! > On Sep 18, 2015, at 2:13 AM, Willem Toorop wrote: > > Dear getdns API designers, > > Getting into the specific parts of getdns data structures (notably the > response dict) can be cumbersome in C. Take for example this > (relatively short) example on how to get to the AD bit of the first > reply of a response: > > getdns_list *replies_tree; > getdns_dict *reply; > getdns_dict *header; > uint32_t ad; > > if ((r = getdns_dict_get_list(resp, "replies_tree", &replies_tree))) > return r; > else if ((r = getdns_list_get_dict(replies_tree, 0, &reply))) > return r; > else if ((r = getdns_dict_get_dict(reply, "header", &header))) > return r; > else if ((r = getdns_dict_get_int(header, "ad", &ad))) > return r; > > > Also, getting data members by text strings like getdns does, is > unconventional in C libraries, but makes getdns very flexible and easy > to extend. It also maps very well to modern scripting languages > (python, javascript, perl, ruby etc.). > > Why don't we take this approach one step further, and get to the data > members by allowing the text strings to contain subscript operators into > the sub-dicts and sub-lists? > > To do the same as the example above with subscript operator: > > uint32_t ad; > > if ((r = getdns_dict_get_int(resp, "replies_tree[0][header][ad]", &ad))) > return r; > > The conciseness and thereby clarity and readability is increasingly more > prominent with more involved examples. > > > What do you think? > > -- Willem > _______________________________________________ > spec mailing list > spec at getdnsapi.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4676 bytes Desc: not available URL: From ngoyal at verisign.com Mon Sep 21 17:54:00 2015 From: ngoyal at verisign.com (Goyal, Neel) Date: Mon, 21 Sep 2015 17:54:00 +0000 Subject: [getdns-api] Getting from dicts by subscript operator In-Reply-To: <67E636A7-12E7-467D-B14A-E04A8C1690BF@verisign.com> References: <55FBD5B9.1020706@nlnetlabs.nl> <67E636A7-12E7-467D-B14A-E04A8C1690BF@verisign.com> Message-ID: I like it - however I?d suggest tweaking the syntax a bit: "replies_tree[0][header][ad]? would become "replies_tree[0].header.ad? So the bracket syntax indicates that it?s an array index and then the dot specifier indicates it?s a field within a dict. On 9/21/15, 12:26 PM, "spec on behalf of Wessels, Duane" wrote: >Willem, > >I think this idea is really great! > > >> On Sep 18, 2015, at 2:13 AM, Willem Toorop wrote: >> >> Dear getdns API designers, >> >> Getting into the specific parts of getdns data structures (notably the >> response dict) can be cumbersome in C. Take for example this >> (relatively short) example on how to get to the AD bit of the first >> reply of a response: >> >> getdns_list *replies_tree; >> getdns_dict *reply; >> getdns_dict *header; >> uint32_t ad; >> >> if ((r = getdns_dict_get_list(resp, "replies_tree", &replies_tree))) >> return r; >> else if ((r = getdns_list_get_dict(replies_tree, 0, &reply))) >> return r; >> else if ((r = getdns_dict_get_dict(reply, "header", &header))) >> return r; >> else if ((r = getdns_dict_get_int(header, "ad", &ad))) >> return r; >> >> >> Also, getting data members by text strings like getdns does, is >> unconventional in C libraries, but makes getdns very flexible and easy >> to extend. It also maps very well to modern scripting languages >> (python, javascript, perl, ruby etc.). >> >> Why don't we take this approach one step further, and get to the data >> members by allowing the text strings to contain subscript operators into >> the sub-dicts and sub-lists? >> >> To do the same as the example above with subscript operator: >> >> uint32_t ad; >> >> if ((r = getdns_dict_get_int(resp, "replies_tree[0][header][ad]", &ad))) >> return r; >> >> The conciseness and thereby clarity and readability is increasingly more >> prominent with more involved examples. >> >> >> What do you think? >> >> -- Willem >> _______________________________________________ >> spec mailing list >> spec at getdnsapi.net > From jhildebr at cisco.com Mon Sep 21 18:09:11 2015 From: jhildebr at cisco.com (Joe Hildebrand (jhildebr)) Date: Mon, 21 Sep 2015 18:09:11 +0000 Subject: [getdns-api] Getting from dicts by subscript operator In-Reply-To: References: <55FBD5B9.1020706@nlnetlabs.nl> <67E636A7-12E7-467D-B14A-E04A8C1690BF@verisign.com> Message-ID: Please don't invent a new syntax. Use RFC 6901. http://tools.ietf.org/html/rfc6901 -- Joe Hildebrand On 9/21/15, 11:54 AM, "spec on behalf of Goyal, Neel" wrote: >I like it - however I?d suggest tweaking the syntax a bit: > >"replies_tree[0][header][ad]? would become "replies_tree[0].header.ad? > > >So the bracket syntax indicates that it?s an array index and then the dot >specifier indicates it?s a field within a dict. > > >On 9/21/15, 12:26 PM, "spec on behalf of Wessels, Duane" > wrote: > >>Willem, >> >>I think this idea is really great! >> >> >>> On Sep 18, 2015, at 2:13 AM, Willem Toorop wrote: >>> >>> Dear getdns API designers, >>> >>> Getting into the specific parts of getdns data structures (notably the >>> response dict) can be cumbersome in C. Take for example this >>> (relatively short) example on how to get to the AD bit of the first >>> reply of a response: >>> >>> getdns_list *replies_tree; >>> getdns_dict *reply; >>> getdns_dict *header; >>> uint32_t ad; >>> >>> if ((r = getdns_dict_get_list(resp, "replies_tree", &replies_tree))) >>> return r; >>> else if ((r = getdns_list_get_dict(replies_tree, 0, &reply))) >>> return r; >>> else if ((r = getdns_dict_get_dict(reply, "header", &header))) >>> return r; >>> else if ((r = getdns_dict_get_int(header, "ad", &ad))) >>> return r; >>> >>> >>> Also, getting data members by text strings like getdns does, is >>> unconventional in C libraries, but makes getdns very flexible and easy >>> to extend. It also maps very well to modern scripting languages >>> (python, javascript, perl, ruby etc.). >>> >>> Why don't we take this approach one step further, and get to the data >>> members by allowing the text strings to contain subscript operators into >>> the sub-dicts and sub-lists? >>> >>> To do the same as the example above with subscript operator: >>> >>> uint32_t ad; >>> >>> if ((r = getdns_dict_get_int(resp, "replies_tree[0][header][ad]", &ad))) >>> return r; >>> >>> The conciseness and thereby clarity and readability is increasingly more >>> prominent with more involved examples. >>> >>> >>> What do you think? >>> >>> -- Willem >>> _______________________________________________ >>> spec mailing list >>> spec at getdnsapi.net >> > > >_______________________________________________ >spec mailing list >spec at getdnsapi.net From ngoyal at verisign.com Mon Sep 21 18:29:33 2015 From: ngoyal at verisign.com (Goyal, Neel) Date: Mon, 21 Sep 2015 18:29:33 +0000 Subject: [getdns-api] Getting from dicts by subscript operator In-Reply-To: References: <55FBD5B9.1020706@nlnetlabs.nl> <67E636A7-12E7-467D-B14A-E04A8C1690BF@verisign.com> Message-ID: Wasn?t trying to - just used what JavaScript does to access JSON. Property and index accessors seem easy enough esp since we don?t have weird characters in field names. If a spec already exists for this sort of thing, go for it. On 9/21/15, 2:09 PM, "Joe Hildebrand (jhildebr)" wrote: >Please don't invent a new syntax. Use RFC 6901. > >http://tools.ietf.org/html/rfc6901 > > >-- >Joe Hildebrand > > > > > > > >On 9/21/15, 11:54 AM, "spec on behalf of Goyal, Neel" > wrote: > >>I like it - however I?d suggest tweaking the syntax a bit: >> >>"replies_tree[0][header][ad]? would become "replies_tree[0].header.ad? >> >> >>So the bracket syntax indicates that it?s an array index and then the dot >>specifier indicates it?s a field within a dict. >> >> >>On 9/21/15, 12:26 PM, "spec on behalf of Wessels, Duane" >> wrote: >> >>>Willem, >>> >>>I think this idea is really great! >>> >>> >>>> On Sep 18, 2015, at 2:13 AM, Willem Toorop >>>>wrote: >>>> >>>> Dear getdns API designers, >>>> >>>> Getting into the specific parts of getdns data structures (notably the >>>> response dict) can be cumbersome in C. Take for example this >>>> (relatively short) example on how to get to the AD bit of the first >>>> reply of a response: >>>> >>>> getdns_list *replies_tree; >>>> getdns_dict *reply; >>>> getdns_dict *header; >>>> uint32_t ad; >>>> >>>> if ((r = getdns_dict_get_list(resp, "replies_tree", &replies_tree))) >>>> return r; >>>> else if ((r = getdns_list_get_dict(replies_tree, 0, &reply))) >>>> return r; >>>> else if ((r = getdns_dict_get_dict(reply, "header", &header))) >>>> return r; >>>> else if ((r = getdns_dict_get_int(header, "ad", &ad))) >>>> return r; >>>> >>>> >>>> Also, getting data members by text strings like getdns does, is >>>> unconventional in C libraries, but makes getdns very flexible and easy >>>> to extend. It also maps very well to modern scripting languages >>>> (python, javascript, perl, ruby etc.). >>>> >>>> Why don't we take this approach one step further, and get to the data >>>> members by allowing the text strings to contain subscript operators >>>>into >>>> the sub-dicts and sub-lists? >>>> >>>> To do the same as the example above with subscript operator: >>>> >>>> uint32_t ad; >>>> >>>> if ((r = getdns_dict_get_int(resp, "replies_tree[0][header][ad]", >>>>&ad))) >>>> return r; >>>> >>>> The conciseness and thereby clarity and readability is increasingly >>>>more >>>> prominent with more involved examples. >>>> >>>> >>>> What do you think? >>>> >>>> -- Willem >>>> _______________________________________________ >>>> spec mailing list >>>> spec at getdnsapi.net >>> >> >> >>_______________________________________________ >>spec mailing list >>spec at getdnsapi.net From shane at time-travellers.org Wed Sep 23 13:37:25 2015 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 23 Sep 2015 13:37:25 +0000 Subject: [getdns-api] Getting from dicts by subscript operator In-Reply-To: References: <55FBD5B9.1020706@nlnetlabs.nl> <67E636A7-12E7-467D-B14A-E04A8C1690BF@verisign.com> Message-ID: <20150923133725.3983027b@casual> Joe, So I guess that you propose that instead of: "replies_tree[0][header][ad]" We would use: "replies_tree[0]/header/ad" Or: "replies_tree/0/header/ad" I think that the last one is "correct" JSON Pointer syntax if I understand the RFC, but I confess that the one above it looks easier to read to me. :) -- Shane On Mon, 21 Sep 2015 18:09:11 +0000 "Joe Hildebrand (jhildebr)" wrote: > Please don't invent a new syntax. Use RFC 6901. > > http://tools.ietf.org/html/rfc6901 > > > -- > Joe Hildebrand > > > > > > > > On 9/21/15, 11:54 AM, "spec on behalf of Goyal, Neel" wrote: > > >I like it - however I?d suggest tweaking the syntax a bit: > > > >"replies_tree[0][header][ad]? would become "replies_tree[0].header.ad? > > > > > >So the bracket syntax indicates that it?s an array index and then the dot > >specifier indicates it?s a field within a dict. > > > > > >On 9/21/15, 12:26 PM, "spec on behalf of Wessels, Duane" > > wrote: > > > >>Willem, > >> > >>I think this idea is really great! > >> > >> > >>> On Sep 18, 2015, at 2:13 AM, Willem Toorop wrote: > >>> > >>> Dear getdns API designers, > >>> > >>> Getting into the specific parts of getdns data structures (notably the > >>> response dict) can be cumbersome in C. Take for example this > >>> (relatively short) example on how to get to the AD bit of the first > >>> reply of a response: > >>> > >>> getdns_list *replies_tree; > >>> getdns_dict *reply; > >>> getdns_dict *header; > >>> uint32_t ad; > >>> > >>> if ((r = getdns_dict_get_list(resp, "replies_tree", &replies_tree))) > >>> return r; > >>> else if ((r = getdns_list_get_dict(replies_tree, 0, &reply))) > >>> return r; > >>> else if ((r = getdns_dict_get_dict(reply, "header", &header))) > >>> return r; > >>> else if ((r = getdns_dict_get_int(header, "ad", &ad))) > >>> return r; > >>> > >>> > >>> Also, getting data members by text strings like getdns does, is > >>> unconventional in C libraries, but makes getdns very flexible and easy > >>> to extend. It also maps very well to modern scripting languages > >>> (python, javascript, perl, ruby etc.). > >>> > >>> Why don't we take this approach one step further, and get to the data > >>> members by allowing the text strings to contain subscript operators into > >>> the sub-dicts and sub-lists? > >>> > >>> To do the same as the example above with subscript operator: > >>> > >>> uint32_t ad; > >>> > >>> if ((r = getdns_dict_get_int(resp, "replies_tree[0][header][ad]", &ad))) > >>> return r; > >>> > >>> The conciseness and thereby clarity and readability is increasingly more > >>> prominent with more involved examples. > >>> > >>> > >>> What do you think? > >>> > >>> -- Willem > >>> _______________________________________________ > >>> spec mailing list > >>> spec at getdnsapi.net > >> > > > > > >_______________________________________________ > >spec mailing list > >spec at getdnsapi.net > > _______________________________________________ > spec mailing list > spec at getdnsapi.net From jhildebr at cisco.com Wed Sep 23 19:37:03 2015 From: jhildebr at cisco.com (Joe Hildebrand (jhildebr)) Date: Wed, 23 Sep 2015 19:37:03 +0000 Subject: [getdns-api] Getting from dicts by subscript operator In-Reply-To: <20150923133725.3983027b@casual> References: <55FBD5B9.1020706@nlnetlabs.nl> <67E636A7-12E7-467D-B14A-E04A8C1690BF@verisign.com> <20150923133725.3983027b@casual> Message-ID: On 9/23/15, 7:37 AM, "Shane Kerr" wrote: >Joe, > >So I guess that you propose that instead of: > >"replies_tree[0][header][ad]" > >We would use: > >"replies_tree[0]/header/ad" > >Or: > >"replies_tree/0/header/ad" > >I think that the last one is "correct" JSON Pointer syntax if I >understand the RFC, but I confess that the one above it looks easier to >read to me. :) The last one. I know it's slightly strange to a C programmer, but to a JavaScript programmer, it's not *too* strange, where a['foo'] === a.foo. The advantage here is that in a getdns wrapper that is treating the results as JSON, you could use an existing json-pointer implementation. Also, you don't have to worry about specifying the BNF for the query syntax, thinking about the edge cases, and worrying about the security consequences quite as much. -- Joe Hildebrand From melinda.shore at nomountain.net Thu Sep 24 16:39:05 2015 From: melinda.shore at nomountain.net (Melinda Shore) Date: Thu, 24 Sep 2015 08:39:05 -0800 Subject: [getdns-api] Getting from dicts by subscript operator In-Reply-To: <20150923133725.3983027b@casual> References: <55FBD5B9.1020706@nlnetlabs.nl> <67E636A7-12E7-467D-B14A-E04A8C1690BF@verisign.com> <20150923133725.3983027b@casual> Message-ID: <56042729.4020603@nomountain.net> On 9/23/15 5:37 AM, Shane Kerr wrote: > I think that the last one is "correct" JSON Pointer syntax if I > understand the RFC, but I confess that the one above it looks easier to > read to me. :) It's probably worth pointing out that the getdns dictionary that's being returned in C is not a JSON dict, and the various language bindings already have their own language-idiomatic mechanisms for dereferencing data in the returned dictionaries. So, while I'm not necessarily against using JSON pointer syntax here I'm also not sure that it has any clear advantages over any other syntax. Melinda -- Melinda Shore No Mountain Software melinda.shore at nomountain.net "Software longa, hardware brevis."