From willem at nlnetlabs.nl  Mon Oct  5 13:07:06 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Mon, 5 Oct 2015 15:07:06 +0200
Subject: [getdns-api] Getting from dicts by subscript operator
In-Reply-To: <A5B7EB90-7704-4C1C-8357-3762D1D2E9BA@cisco.com>
References: <55FBD5B9.1020706@nlnetlabs.nl>
 <67E636A7-12E7-467D-B14A-E04A8C1690BF@verisign.com>
 <D225BC1C.178AF%ngoyal@verisign.com>
 <DD20A8D2-7397-4EF2-AD14-0F6C2197156A@cisco.com>
 <20150923133725.3983027b@casual>
 <A5B7EB90-7704-4C1C-8357-3762D1D2E9BA@cisco.com>
Message-ID: <561275FA.7040401@nlnetlabs.nl>

Op 23-09-15 om 21:37 schreef Joe Hildebrand (jhildebr):
> On 9/23/15, 7:37 AM, "Shane Kerr" <shane at time-travellers.org> 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. :)
> 
> 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.

Good point.  Since it has to become part of the spec, it is easier to
reference an existing syntax (especially since it is standardized) than
to describe a new one.  I have come up with the following wording, to
append to the first subsection of section 2. (so just before 2.1. starts)

	When the name parameter to the getdns_dict_get_ functions, starts with
a '/' (%x2F) character, it is interpreted as a JSON Pointer as described
in RFC6901, and will then be used to dereference the nested data
structures to get to the requested data type.


And at the end of section 2.1.


	When the name parameter to the getdns_dict_set_ functions, starts with
a '/' (%x2F) character, it is interpreted as a JSON Pointer as described
in RFC6901, and will then be used to dereference the nested data
structures to get to the requested data type.


Comments or better wordings are welcome.

I think the examples in the spec could also benefit from using JSON
Pointer syntax.  They are likely to become much shorter and therefor
more readable and easier to digest.  Take for example this alternative
for the example in section 6.4 (I started with the shortest):

https://github.com/getdnsapi/getdns/blob/features/json-pointers/spec/example/synchronous-json-pointer.c

What do you think?

-- Willem


From willem at nlnetlabs.nl  Mon Oct  5 13:15:11 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Mon, 5 Oct 2015 15:15:11 +0200
Subject: [getdns-api] Getting from dicts by subscript operator
In-Reply-To: <561275FA.7040401@nlnetlabs.nl>
References: <55FBD5B9.1020706@nlnetlabs.nl>
 <67E636A7-12E7-467D-B14A-E04A8C1690BF@verisign.com>
 <D225BC1C.178AF%ngoyal@verisign.com>
 <DD20A8D2-7397-4EF2-AD14-0F6C2197156A@cisco.com>
 <20150923133725.3983027b@casual>
 <A5B7EB90-7704-4C1C-8357-3762D1D2E9BA@cisco.com>
 <561275FA.7040401@nlnetlabs.nl>
Message-ID: <561277DF.2020607@nlnetlabs.nl>

Op 05-10-15 om 15:07 schreef Willem Toorop:
> Op 23-09-15 om 21:37 schreef Joe Hildebrand (jhildebr):
>> On 9/23/15, 7:37 AM, "Shane Kerr" <shane at time-travellers.org> 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. :)
>>
>> 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.
> 
> Good point.  Since it has to become part of the spec, it is easier to
> reference an existing syntax (especially since it is standardized) than
> to describe a new one.  I have come up with the following wording, to
> append to the first subsection of section 2. (so just before 2.1. starts)
> 
> 	When the name parameter to the getdns_dict_get_ functions, starts with
> a '/' (%x2F) character, it is interpreted as a JSON Pointer as described
> in RFC6901, and will then be used to dereference the nested data
> structures to get to the requested data type.
> 
> 
> And at the end of section 2.1.
> 
> 
> 	When the name parameter to the getdns_dict_set_ functions, starts with
> a '/' (%x2F) character, it is interpreted as a JSON Pointer as described
> in RFC6901, and will then be used to dereference the nested data
> structures to get to the requested data type.


Sorry, I copy pasted but forgot to alter.  So I propose this paragraph
the the spot:

	When the name parameter to the getdns_dict_set_ functions, starts with
a '/' (%x2F) character, it is interpreted as a JSON Pointer as described
in RFC6901, and will then be used to dereference the nested data
structures to set the given value at the specified name or list index.


> 
> 
> Comments or better wordings are welcome.
> 
> I think the examples in the spec could also benefit from using JSON
> Pointer syntax.  They are likely to become much shorter and therefor
> more readable and easier to digest.  Take for example this alternative
> for the example in section 6.4 (I started with the shortest):
> 
> https://github.com/getdnsapi/getdns/blob/features/json-pointers/spec/example/synchronous-json-pointer.c
> 
> What do you think?
> 
> -- Willem
> _______________________________________________
> spec mailing list
> spec at getdnsapi.net
> 



From willem at nlnetlabs.nl  Tue Oct  6 08:30:02 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 6 Oct 2015 10:30:02 +0200
Subject: [getdns-api] vBSDcon 2015 presentation video online
Message-ID: <5613868A.6010105@nlnetlabs.nl>

Hi All,

Half September, I gave an one hour overview presentation of the getdns
API implementation.  It was very nice to have a slot this large.  It
gave me the opportunity to give a complete overview of what we've done,
(including surrounding research etc.) and where we stand (future plans).
 This is also the first time I've talked about and illustrated the - as
of yet undocumented - feature of hooking getdns into your application's
native event base (albeit a bit hasty).

Last week I noticed the nice vBSDcon people have put the video online.
So if you're interested... here it is:
https://www.youtube.com/watch?v=73M7h56Dsas


-- Willem

PS.  Sorry about me squinting so much... that happens sometimes when I'm
a little tired...


From gwiley at verisign.com  Tue Oct  6 08:32:39 2015
From: gwiley at verisign.com (Wiley, Glen)
Date: Tue, 6 Oct 2015 08:32:39 +0000
Subject: [getdns-api] [getdns-users] vBSDcon 2015 presentation video
	online
In-Reply-To: <5613868A.6010105@nlnetlabs.nl>
References: <5613868A.6010105@nlnetlabs.nl>
Message-ID: <2109CD82-B8A3-4C19-B568-E41B2FF76FED@verisign.com>

It was an excellent talk Willem, thanks for being part of making vbsdcon such a great conference.

Sent from my iPhone

> On Oct 6, 2015, at 10:31, Willem Toorop <willem at nlnetlabs.nl> wrote:
> 
> Hi All,
> 
> Half September, I gave an one hour overview presentation of the getdns
> API implementation.  It was very nice to have a slot this large.  It
> gave me the opportunity to give a complete overview of what we've done,
> (including surrounding research etc.) and where we stand (future plans).
> This is also the first time I've talked about and illustrated the - as
> of yet undocumented - feature of hooking getdns into your application's
> native event base (albeit a bit hasty).
> 
> Last week I noticed the nice vBSDcon people have put the video online.
> So if you're interested... here it is:
> https://www.youtube.com/watch?v=73M7h56Dsas
> 
> 
> -- Willem
> 
> PS.  Sorry about me squinting so much... that happens sometimes when I'm
> a little tired...
> _______________________________________________
> Users mailing list
> Users at getdnsapi.net
> http://getdnsapi.net/mailman/listinfo/users
> 




From willem at nlnetlabs.nl  Tue Oct  6 21:18:53 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 6 Oct 2015 23:18:53 +0200
Subject: [getdns-api] Getting from dicts by subscript operator
In-Reply-To: <561277DF.2020607@nlnetlabs.nl>
References: <55FBD5B9.1020706@nlnetlabs.nl>
 <67E636A7-12E7-467D-B14A-E04A8C1690BF@verisign.com>
 <D225BC1C.178AF%ngoyal@verisign.com>
 <DD20A8D2-7397-4EF2-AD14-0F6C2197156A@cisco.com>
 <20150923133725.3983027b@casual>
 <A5B7EB90-7704-4C1C-8357-3762D1D2E9BA@cisco.com>
 <561275FA.7040401@nlnetlabs.nl> <561277DF.2020607@nlnetlabs.nl>
Message-ID: <56143ABD.5000706@nlnetlabs.nl>

Here are the other examples from the spec, rewritten to use json
pointers, and extended to deal and report all fail cases.

For section 6.1: Get Both IPv4 and IPv6 Addresses for a Domain Name
Using Quick Results:
https://github.com/getdnsapi/getdns/blob/features/json-pointers/spec/example/simple-json-pointer.c

For section 6.2: Get IPv4 and IPv6 Addresses for a Domain Name:
https://github.com/getdnsapi/getdns/blob/features/json-pointers/spec/example/tree-json-pointer.c

For section 6.4: Using the API Synchronously:
https://github.com/getdnsapi/getdns/blob/features/json-pointers/spec/example/synchronous-json-pointer.c

For section 6.5: Getting Names from the Reverse Tree:
https://github.com/getdnsapi/getdns/blob/features/json-pointers/spec/example/reverse-json-pointer.c

-- Willem

Op 05-10-15 om 15:15 schreef Willem Toorop:
> Op 05-10-15 om 15:07 schreef Willem Toorop:
>> Op 23-09-15 om 21:37 schreef Joe Hildebrand (jhildebr):
>>> On 9/23/15, 7:37 AM, "Shane Kerr" <shane at time-travellers.org> 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. :)
>>>
>>> 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.
>>
>> Good point.  Since it has to become part of the spec, it is easier to
>> reference an existing syntax (especially since it is standardized) than
>> to describe a new one.  I have come up with the following wording, to
>> append to the first subsection of section 2. (so just before 2.1. starts)
>>
>> 	When the name parameter to the getdns_dict_get_ functions, starts with
>> a '/' (%x2F) character, it is interpreted as a JSON Pointer as described
>> in RFC6901, and will then be used to dereference the nested data
>> structures to get to the requested data type.
>>
>>
>> And at the end of section 2.1.
>>
>>
>> 	When the name parameter to the getdns_dict_set_ functions, starts with
>> a '/' (%x2F) character, it is interpreted as a JSON Pointer as described
>> in RFC6901, and will then be used to dereference the nested data
>> structures to get to the requested data type.
> 
> 
> Sorry, I copy pasted but forgot to alter.  So I propose this paragraph
> the the spot:
> 
> 	When the name parameter to the getdns_dict_set_ functions, starts with
> a '/' (%x2F) character, it is interpreted as a JSON Pointer as described
> in RFC6901, and will then be used to dereference the nested data
> structures to set the given value at the specified name or list index.
> 
> 
>>
>>
>> Comments or better wordings are welcome.
>>
>> I think the examples in the spec could also benefit from using JSON
>> Pointer syntax.  They are likely to become much shorter and therefor
>> more readable and easier to digest.  Take for example this alternative
>> for the example in section 6.4 (I started with the shortest):
>>
>> https://github.com/getdnsapi/getdns/blob/features/json-pointers/spec/example/synchronous-json-pointer.c
>>
>> What do you think?
>>
>> -- Willem
>> _______________________________________________
>> spec mailing list
>> spec at getdnsapi.net
>>
> 
> _______________________________________________
> spec mailing list
> spec at getdnsapi.net
> 



From willem at nlnetlabs.nl  Wed Oct  7 15:26:12 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Wed, 7 Oct 2015 17:26:12 +0200
Subject: [getdns-api] Spec repo at https://github.com/getdnsapi/spec
Message-ID: <56153994.9010708@nlnetlabs.nl>

Hi ALl,

I hadn't told you yet, but at IETF93 in Prague, besides migrating the
spec mailing-list, we have also migrated the specification repository
from Paul's private svn repo to public github, here:
	
	https://github.com/getdnsapi/spec

It contains all commits since we started editing it (7 November 2013).

This is convenient, because now I can reference a specific development
branch for you to review.  For example to compare the develop branch
with the json-pointers branch, see:

https://github.com/getdnsapi/spec/compare/develop...json-pointers

The json-pointer examples I wanted you to review are now in the
json-pointers branch of the spec repo only.

The resulting document (including examples) can be viewed here:
	
	https://getdnsapi.net/json-pointers/


-- Willem


From willem at nlnetlabs.nl  Wed Oct  7 15:27:36 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Wed, 7 Oct 2015 17:27:36 +0200
Subject: [getdns-api] Removing "the_" prefexis
Message-ID: <561539E8.1050406@nlnetlabs.nl>

Would any of you mind if I would remove the "the_" prefixes in variable
and parameter names in the spec?

-- Willem


From willem at nlnetlabs.nl  Wed Oct  7 15:31:58 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Wed, 7 Oct 2015 17:31:58 +0200
Subject: [getdns-api] Correction:  Removing "this_" prefexis
In-Reply-To: <561539E8.1050406@nlnetlabs.nl>
References: <561539E8.1050406@nlnetlabs.nl>
Message-ID: <56153AEE.4030408@nlnetlabs.nl>

Sorry, I meant the "this_" prefixes of course!

Op 07-10-15 om 17:27 schreef Willem Toorop:
> Would any of you mind if I would remove the "the_" prefixes in variable
> and parameter names in the spec?
> 
> -- Willem
> _______________________________________________
> spec mailing list
> spec at getdnsapi.net
> 



From sara at sinodun.com  Fri Oct 16 17:56:07 2015
From: sara at sinodun.com (sara)
Date: Fri, 16 Oct 2015 18:56:07 +0100
Subject: [getdns-api] Removing STARTTLS from the API
Message-ID: <3D4F16EB-FB2A-4A7A-BC25-FDD61D35ED15@sinodun.com>

Hi All, 

STARTTLS was removed as a mechanism for DNS privacy in the latest version of this draft:  http://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-01 <http://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-01>

Therefore, if there are no objections, I would like to propose that STARTTLS is removed from the list of values that can be specified via the 
      getdns_transport_list_t * transports
list in the next version of the API spec. 

Regards

Sara.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.getdnsapi.net/pipermail/spec/attachments/20151016/e20b63ab/attachment.htm>

From shane at time-travellers.org  Fri Oct 16 18:00:33 2015
From: shane at time-travellers.org (Shane Kerr)
Date: Fri, 16 Oct 2015 20:00:33 +0200
Subject: [getdns-api] Removing STARTTLS from the API
In-Reply-To: <3D4F16EB-FB2A-4A7A-BC25-FDD61D35ED15@sinodun.com>
References: <3D4F16EB-FB2A-4A7A-BC25-FDD61D35ED15@sinodun.com>
Message-ID: <20151016200033.404d5dc2@pallas.home.time-travellers.org>

Sara,

On Fri, 16 Oct 2015 18:56:07 +0100
sara <sara at sinodun.com> wrote:

> STARTTLS was removed as a mechanism for DNS privacy in the latest
> version of this draft:
> http://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-01
> <http://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-01>
> 
> Therefore, if there are no objections, I would like to propose that
> STARTTLS is removed from the list of values that can be specified via
> the getdns_transport_list_t * transports list in the next version of
> the API spec. 

Please do! The less (unneeded) functionality the better. :)

Cheers,

--
Shane


From asullivan at dyn.com  Fri Oct 16 20:20:23 2015
From: asullivan at dyn.com (Andrew Sullivan)
Date: Fri, 16 Oct 2015 16:20:23 -0400
Subject: [getdns-api] Removing STARTTLS from the API
In-Reply-To: <3D4F16EB-FB2A-4A7A-BC25-FDD61D35ED15@sinodun.com>
References: <3D4F16EB-FB2A-4A7A-BC25-FDD61D35ED15@sinodun.com>
Message-ID: <4C39FA49-A5FB-4CE3-9ECA-D1173AE3979D@dyn.com>

It seems a little premature to assume that's permanent.  Rather than changing now, could we wait until the wg decides for good?  (I think this is how it'll go, but why hurry?)

-- 
Andrew Sullivan 
Please excuse my clumbsy thums. 

> On Oct 16, 2015, at 13:56, sara <sara at sinodun.com> wrote:
> 
> Hi All, 
> 
> STARTTLS was removed as a mechanism for DNS privacy in the latest version of this draft:  http://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-01
> 
> Therefore, if there are no objections, I would like to propose that STARTTLS is removed from the list of values that can be specified via the 
>       getdns_transport_list_t * transports
> list in the next version of the API spec. 
> 
> Regards
> 
> Sara.
> _______________________________________________
> spec mailing list
> spec at getdnsapi.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.getdnsapi.net/pipermail/spec/attachments/20151016/b1960cf6/attachment.htm>

From shane at time-travellers.org  Mon Oct 19 11:38:48 2015
From: shane at time-travellers.org (Shane Kerr)
Date: Mon, 19 Oct 2015 12:38:48 +0100
Subject: [getdns-api] Removing STARTTLS from the API
In-Reply-To: <4C39FA49-A5FB-4CE3-9ECA-D1173AE3979D@dyn.com>
References: <3D4F16EB-FB2A-4A7A-BC25-FDD61D35ED15@sinodun.com>
 <4C39FA49-A5FB-4CE3-9ECA-D1173AE3979D@dyn.com>
Message-ID: <20151019123848.1bf00aa8@pallas.home.time-travellers.org>

Andrew,

In one sense you are correct, but the longer functionality is around the
harder it is to get rid of.

Perhaps it should be marked as "scheduled for removal" now in the
documentation and via comments in the code, and the actual removal
deferred until the magical day in the distant future when drafts become
RFCs?

Cheers,

--
Shane

On Fri, 16 Oct 2015 16:20:23 -0400
Andrew Sullivan <asullivan at dyn.com> wrote:

> It seems a little premature to assume that's permanent.  Rather than
> changing now, could we wait until the wg decides for good?  (I think
> this is how it'll go, but why hurry?)
> 
> -- 
> Andrew Sullivan 
> Please excuse my clumbsy thums. 
> 
> > On Oct 16, 2015, at 13:56, sara <sara at sinodun.com> wrote:
> > 
> > Hi All, 
> > 
> > STARTTLS was removed as a mechanism for DNS privacy in the latest
> > version of this draft:
> > http://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-01
> > 
> > Therefore, if there are no objections, I would like to propose that
> > STARTTLS is removed from the list of values that can be specified
> > via the getdns_transport_list_t * transports list in the next
> > version of the API spec. 
> > 
> > Regards
> > 
> > Sara.
> > _______________________________________________
> > spec mailing list
> > spec at getdnsapi.net  



From sara at sinodun.com  Mon Oct 19 13:45:14 2015
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 19 Oct 2015 14:45:14 +0100
Subject: [getdns-api] Removing STARTTLS from the API
In-Reply-To: <20151019123848.1bf00aa8@pallas.home.time-travellers.org>
References: <3D4F16EB-FB2A-4A7A-BC25-FDD61D35ED15@sinodun.com>
 <4C39FA49-A5FB-4CE3-9ECA-D1173AE3979D@dyn.com>
 <20151019123848.1bf00aa8@pallas.home.time-travellers.org>
Message-ID: <BAF87EBD-3E4C-4CE5-858A-EE66AC6C1609@sinodun.com>

Hi, 

I made an argument to the core development team that the STARTTLS functionality adds some complexity to the code. I didn?t feel the effort to maintain and test it moving forward (as various authentication mechanisms are added, code is re-factored, etc.) was warranted given the consensus in the WG to remove the mechanism from the draft. This was accepted, but if there are strong feelings that this shouldn?t be done now please speak to that.

On the separate question of updating the Official API, of course it could be handled as Shane suggests. But I felt that now the mechanism is no longer described in an active IETF draft it seemed a reasonable time to ask the question. 

Regards

Sara. 

> On 19 Oct 2015, at 12:38, Shane Kerr <shane at time-travellers.org> wrote:
> 
> Andrew,
> 
> In one sense you are correct, but the longer functionality is around the
> harder it is to get rid of.
> 
> Perhaps it should be marked as "scheduled for removal" now in the
> documentation and via comments in the code, and the actual removal
> deferred until the magical day in the distant future when drafts become
> RFCs?
> 
> Cheers,
> 
> --
> Shane
> 
> On Fri, 16 Oct 2015 16:20:23 -0400
> Andrew Sullivan <asullivan at dyn.com> wrote:
> 
>> It seems a little premature to assume that's permanent.  Rather than
>> changing now, could we wait until the wg decides for good?  (I think
>> this is how it'll go, but why hurry?)
>> 
>> -- 
>> Andrew Sullivan 
>> Please excuse my clumbsy thums. 
>> 
>>> On Oct 16, 2015, at 13:56, sara <sara at sinodun.com> wrote:
>>> 
>>> Hi All, 
>>> 
>>> STARTTLS was removed as a mechanism for DNS privacy in the latest
>>> version of this draft:
>>> http://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-01
>>> 
>>> Therefore, if there are no objections, I would like to propose that
>>> STARTTLS is removed from the list of values that can be specified
>>> via the getdns_transport_list_t * transports list in the next
>>> version of the API spec. 
>>> 
>>> Regards
>>> 
>>> Sara.
>>> _______________________________________________
>>> spec mailing list
>>> spec at getdnsapi.net  
> 
> _______________________________________________
> spec mailing list
> spec at getdnsapi.net




From asullivan at dyn.com  Mon Oct 19 14:05:20 2015
From: asullivan at dyn.com (Andrew Sullivan)
Date: Mon, 19 Oct 2015 10:05:20 -0400
Subject: [getdns-api] Removing STARTTLS from the API
In-Reply-To: <20151019123848.1bf00aa8@pallas.home.time-travellers.org>
References: <3D4F16EB-FB2A-4A7A-BC25-FDD61D35ED15@sinodun.com>
 <4C39FA49-A5FB-4CE3-9ECA-D1173AE3979D@dyn.com>
 <20151019123848.1bf00aa8@pallas.home.time-travellers.org>
Message-ID: <20151019140518.GA14027@dyn.com>

On Mon, Oct 19, 2015 at 12:38:48PM +0100, Shane Kerr wrote:
> Perhaps it should be marked as "scheduled for removal" now in the
> documentation and via comments in the code, and the actual removal
> deferred until the magical day in the distant future when drafts become
> RFCs?

No objection to that.

A 

-- 
Andrew Sullivan
Dyn
asullivan at dyn.com


From willem at nlnetlabs.nl  Thu Oct 22 13:19:23 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Thu, 22 Oct 2015 15:19:23 +0200
Subject: [getdns-api] October 2015 release of API
Message-ID: <5628E25B.1050008@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear All,

We have a new API October 2015 release which can be found here:
https://getdnsapi.net/spec/ .  This release adds JSON pointer
arguments to getdns_dict_get_* and getdns_dict_set_* to dereference
nested dicts and lists and the GETDNS_RETURN_NOT_IMPLEMENTED return code
.
For a comprehensive overview of all changes see:

https://github.com/getdnsapi/spec/compare/bb71616d...october-2015

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWKOJbAAoJEOX4+CEvd6SYK5oP/1+NnhRk87VodE+uOUwBVcGW
m7oqAlPNF0sduwNSpoH6PDtSsoqSKKnNrip+xQp3ey/hDDAWZfeWgC636Jo8aFY+
PoUEB63hPEho2btYJkR4Zty9AWK76guJkF6FtnNBAWt99M/BrTQO9SmZ5OB4k5EA
4mxXumh2RV/Vdv5mkbz4fE/LcKafj0Y8d0q8J/BYlgQMWJ+BYRFfXJRE0ymNPAed
YWbR4cdkoGhSfsP3pFzCNeXdpqPEgr8EVl2HKopoeBszn+xfkdPrXiWVc73GVsZP
7Iv/b6WM4RRx3IvQIrEnPtIlg6S757rKt7OC7HMoPCdsCGRVDabHTQNX+SbrhPdp
+exD2BGcMQUB2TBXbqEh280B812g9d33OYGDLnhco2Eo4F4tQQaRkz1/4V3f7Lms
UQEezdgN4Z/Vf5zHhaiJFdzETZMmc9JBXkNAHOVPwAwdqwbkh2HfaZGt7VVco7RL
d5Nu5CWD4uyl9uq4SQtQszx1yKUKF7sB2isfveHLd6Dbkr6oAkeWlOoPDRBlVk9B
31LGK8XMF7RgOZXW+aQMXFE5/TEKMfVPtq/8xGUwhg5J+Lohoq4m1Aup6CznEpCn
HKeD4OdaTOPZeXHGHhaSoRHFxG49QFDaFkgE8T4cBcPSbp+GjBCL717eJCvLdOT6
4IYgnC/OCl0kppwjcLQk
=W7Gh
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Thu Oct 22 17:59:31 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Thu, 22 Oct 2015 19:59:31 +0200
Subject: [getdns-api] getdns 0.5.0 release candidate
Message-ID: <56292403.7050005@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear All,

We have a release candidate for version 0.5.0 of getdns.

This is mostly a new features release

This release does all crypto operations using OpenSSL directly and has
no longer a dependency on libldns. Note however that libldns is still
used by the unit tests.

Following the October 2015 release of the API specification, this
library release now allows to accesses deeply embeded datastructure
members in getdns_dicts by JSON Pointer RFC 6901. This works both for
both the getter and setter functions.

DNS over TLS now uses the default IANA assigned port number for
domain-s: 853.

This release includes an experimental implementation of upstream
server hostname authentication for TLS connections in stub mode (note
that the default behaviour has not changed compared to the 0.3
release). A new, non-standard function
getdns_context_set_tls_authentication() can be used to set the
authentication to GETDNS_AUTHENTICATION_ which requires that a server
provides a valid certificate (validated using the default CA
repository) and that the hostname specified in the "tls_auth_name"
field of the upstream dict matches that in the certificate. The
authentication setting is only enforced when the transport list
contains only GETDNS_TRANSPORT_TLS and in this case if authentication
fails for all upstreams, queries will fail. If the transport list
contains other clear text transports then opportunistic TLS will be
performed which does not require authentication of the TLS connection.
Examples of usage using the getdns_query tool can be found in the
tests_transports.sh script in the test directory.

Please review this candidate carefully. If no issues arrise the actual
release will follow Thursday the 29th of October 2015.


link: https://getdnsapi.net/dist/getdns-0.5.0rc1.tar.gz
md5 : 725bcde3bfd344ecd9e680aa535b4771
sha1: fe76fd6cff4e118da91c592ff76e99d9da1f311e
pgp : https://getdnsapi.net/dist/getdns-0.5.0rc1.tar.gz.asc


ChangeLog
=========
* 2015-10-??: Version 0.5.0
  * Native crypto.  No ldns dependency anymore.
    (ldns still necessary to be able to run tests though)
  * JSON pointer arguments to getdns_dict_get_* and getdns_dict_set_*
    to dereference nested dicts and lists.
  * Bugfix: DNSSEC code finding zone cut with redirects +
    pursuing unsigned DS answers close to the root.
    Thanks Theogene Bucuti!
  * Default port for TLS changed to 853
  * Unofficial extension to the API to allow TLS hostname verification
    to be required for stub mode when using only TLS as a transport.
    When required a hostname must be supplied in the
    'hostname' field of the upstream_list dict and the TLS cipher
    suites are restricted to the 4 AEAD suites recommended in RFC7525.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWKSQCAAoJEOX4+CEvd6SYq98P/34BXNi5+3DXe90GCskg6nCu
bNaVwIg8J/VnevHZtM83+hhp837TI+F/TaAZz6vfYYXRBJ6tsU6J5q201J/DkgYm
Y3nPYRgHLRQ9lSNJ9+3qQvLZvMN0uyosDBkCCw7eoLYdQH22PrUUwDiyi8DxG5r3
MneVw00N4qS66FAF+fyA/wtH3zGqBImMhP4ENaGx4RCwH/UMUeSGcJEEIul+xrxT
3TpmLu1bS0JQyaJXXvEPe0q0kEU7CbTyDbyUvre/hwQdQw1lmF2IdGyZMdf7oLx7
7IGpCLwhLl8NumeF7Nr5MZ2uPiqVU9qMYIIFx5aUFsdRu0vlnE9vB4hsPNi/LE1c
vwVOcRsjoMUuZLRc07f75VXnbMNfgwCLWCn4nYaMv62CwGE5Ft+Ioo5X0+hAkYzI
V57D9ulo9ZwRoPLKXz/BI7SP1Z43e/gcbP1HzIiQ7iZXr5fTcbEqTsYvlwxOYawM
J3YOiUUtbs0uh5s1u1pAnuiheFy6mpDhVKjuLpcww/fddASVM5ovvjn7FMByxXWE
XmIKJnUvyG0YGn9bOnISKfeCjEopTvu0CvR3anMNWVkJF+8KfeLMyUDZPsaXNEqg
Jtw6n2J8dKA8f+B0USllkka5yT8HaGiEkYmKr+D1WnpVAdBc5W6tSSF5JK+VqIcz
6SI0wu1kmsOtat8gLQ09
=1u7/
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Thu Oct 29 19:29:28 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Thu, 29 Oct 2015 20:29:28 +0100
Subject: [getdns-api] getdns 0.5.0 release
Message-ID: <56327398.4030105@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear All,

We have a new release version 0.5.0 of getdns.

This is mostly a new features release

This release does all crypto operations using OpenSSL directly and has
no longer a dependency on libldns. Note however that libldns is still
used by the unit tests.

Following the October 2015 release of the API specification, the
library can now access deeply embedded data structure members in
getdns_dicts by using JSON Pointers as the name to be accessed (RFC
6901). This works for the getter and setter functions
(getdns_dict_get_* and getdns_dict_set_*).

DNS over TLS now uses the default IANA assigned port number for
domain-s: 853.

This release includes an experimental implementation of upstream
server hostname authentication for TLS connections in stub mode (note
that the default behaviour has not changed compared to the 0.3
release). A new, non-standard function
getdns_context_set_tls_authentication() can be used to set the
authentication to GETDNS_AUTHENTICATION_ which requires that a server
provides a valid certificate (validated using the default CA
repository) and that the hostname specified in the "tls_auth_name"
field of the upstream dict matches that in the certificate. The
authentication setting is only enforced when the transport list
contains only GETDNS_TRANSPORT_TLS and in this case if authentication
fails for all upstreams, queries will fail. If the transport list
contains other clear text transports then opportunistic TLS will be
performed which does not require authentication of the TLS connection.
Examples of usage using the getdns_query tool can be found in the
tests_transports.sh script in the test directory.


link: https://getdnsapi.net/dist/getdns-0.5.0.tar.gz
md5 : b0458582455c8e1be9de1a41ac4fa889
sha1: 67aafdd6566bd3c99b51524191a036710819c7cd
pgp : https://getdnsapi.net/dist/getdns-0.5.0.tar.gz.asc


ChangeLog
=========
* 2015-10-29: Version 0.5.0
  * Native crypto. No ldns dependency anymore.
    (ldns still necessary to be able to run tests though)
  * JSON pointer arguments to getdns_dict_get_* and getdns_dict_set_*
    to dereference nested dicts and lists.
  * Bugfix: DNSSEC code finding zone cut with redirects + pursuing
    unsigned DS answers close to the root. Thanks Theogene Bucuti!
  * Default port for TLS changed to 853
  * Unofficial extension to the API to allow TLS hostname verification
    to be required for stub mode when using only TLS as a transport.
    When required a hostname must be supplied in the
    'hostname' field of the upstream_list dict and the TLS cipher
    suites are restricted to the 4 AEAD suites recommended in RFC7525.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWMnOYAAoJEOX4+CEvd6SYVu0P/3os+8LtcsFMYPEjbuEFsReH
PtrchypJb8rp/UK/uZGH7r+jxsQcFCxURqE7qkXArw+RF5JTwxAWF44y7HLMZhbT
JPgJjSV7nafgzkXYBfRxZaO4b8VmOdYbjBu8N561i/nrHUF3teow+NK7IouXq8SU
3u8mPrvERhaaJq4/7iwb2uUFr3innhwEBdaTKy3f4Mib9nfKUW7gIQBFXAd6z9xp
pq+je+d2yfVk7bltggek5/oQhMb+cvCQP6iyhgvulenwYREm21HZElr/ECiTI4Oo
sHiEXmyG87WMiZoJQlIsWLyFCy3kJ2QaoOpl3sMH2is/LjPn9MazVztXw+O+wvPj
0uvcgQY+Gc3V5sejnMIEq0aMe2VqXFVeKKT2AZ8NFkInzvqEKCXmaJ2Di7zYonEH
d+RJCnYf3tFE7V6l5JzXfYScRZbidMALc1e99xCTdz/PcoCzFWgzFOIJqQRbkI9S
VevD3XCI1op/JJywzbJtnns5CMKOWsjX15exNzCGH3jHJgEFWArhwuLsr0yXsNfv
rDnFB0uwc6aCylDrSOj3Dl87vs4dq/zFymZkHQmtudLCP/kuWfs1zXaBBqcJ3BY5
rWfXhrnnQPBLwNxAW4As+2DNxPNtkWQyG049JLjOakAUsSs4neHnDcr8px0pZPWk
L73kzTzL7LG3VnOLDbS5
=DtbJ
-----END PGP SIGNATURE-----


From dkg at fifthhorseman.net  Fri Oct 30 22:33:07 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat, 31 Oct 2015 07:33:07 +0900
Subject: [getdns-api] getdns 0.5.0 release
In-Reply-To: <56327398.4030105@nlnetlabs.nl>
References: <56327398.4030105@nlnetlabs.nl>
Message-ID: <87wpu4rnq4.fsf@alice.fifthhorseman.net>

On Fri 2015-10-30 04:29:28 +0900, Willem Toorop wrote:
> We have a new release version 0.5.0 of getdns.

This is now available in debian unstable.

     --dkg