[getdns-api] Presentation format for null terminated domain name strings

[Paul Hoffman]

On Nov 22, 2013, at 2:04 AM, Willem Toorop <willem at nlnetlabs.nl> wrote:

> op 21-11-13 18:52, Paul Hoffman schreef:
>> On Nov 21, 2013, at 8:56 AM, Andrew Sullivan <asullivan at dyn.com> wrote:
>> 
>>> On Wed, Nov 20, 2013 at 06:43:58PM -0800, Paul Hoffman wrote:
>>>> 
>>>> Can you be more specific about "master file format" and "presentation format" mean here?
>>> 
>>> Doubtless what they always mean in a DNS context.  www.example.com. is
>>> in master file or presentation format (as opposed to wire, which is
>>> conceptually 3www7example3com0).
>> 
>> Not "doubtless" because there is an "or" in the original statement. And, given that that is the current format, I want to be sure we understand what is being proposed before it changes.
> 
> Sorry, the "or" was intended to mean "also known as".
> 
> But more specifically, I meant it to be like the syntax of <domain-name>
> as described in section 5.1 of RFC1035.
> I propose to include something like this in the specification:
> 
> 
> 	The labels of the <domain-name> are expressed as character
> 	strings separated by dots.  Quoting/escaping conventions are
> 	applied so that,
> 
> 	X	Each character X other than the dot (.), the backslash
> 		(\) and the null character represent themselves (X).
> 	\X	A character X other than a digit (0-9) following a
> 		backslash represents X.  For example, "\." can be used
> 		to place a dot character in a label.  A backslash
> 		followed by a null character is no different than other
> 		quoted characters and thus means the null character.
> 	\DDD	A backslash followed by three digits D (0-9) represents
> 		the byte with decimal value DDD.  This rule causes an
> 		error message when there are less than three digits
> 		following the backslash or when the value of DDD is
> 		larger than 255.
> 
> 	No DHL rules as specified in [RFC0952] and relaxed in [RFC1123]
> 	are applied.

Excellent, this is the right way to do it.

> I think it is important to make such behaviour explicit, because the
> behaviour of getaddrinfo varies greatly with different systems.

Quite right.

--Paul Hoffman