Allow an empty TXT record when using DNS-SD encoding?

[EskoDijk]

Current draft mentions that DNS-SD does not allow an empty TXT record

A variation may have the option of being represented by the empty string "". This is not allowed in the DNS-SD encoding, and instead the alternative variation string MUST always be used for DNS-SD.

However, an empty string is allowed - just use a single byte 0 in the TXT record as defined by https://datatracker.ietf.org/doc/html/rfc6763#autoid-13 which makes the TXT keys set empty.

Even if other TXT keys would be defined such as

mynicekey=hello world
abc=42

then the absence of a specific variation string implies that the default variation "" is used, I think.

[EskoDijk]

@toerless to comment on this!

[toerless]

Thanks, Esko. I also recently stumbled across this but would have forgotten to fix it.
Let me keep it open until i fix this for DNS...

But there is also the question of how to deal with "" in CORE-LF. Right now the encoding is to have only a space contatenated string of variations. This format would not permit an empty string.

So i wonder if we want to still say "We can never be sure that some future encoding may not support an empty string, so we should always have an alternative to it...

Opinions ?

[EskoDijk]

So i wonder if we want to still say "We can never be sure that some future encoding may not support an empty string, so we
should always have an alternative to it...

Right, that could be the case for future methods/encodings. Seems good to have a default alternative with name, so the name can always be used in case the empty string "" is not supported.

[becarpenter]

Doesn't that mean that for interop, all implementations would have to support receiving either "" or "None"?

My inner Python programmer came up with a Boolean function:

def none(s):
    return(s=="None" or s=="")

[EskoDijk]

@becarpenter Where would the "None" come from? That feels like the producer of such a string made a Python code mistake :) It would not be compliant to our specification.

[becarpenter]

"None" is just an arbitrary string that I chose. If you want an alternative to the empty string, you need to define it as a reserved value. And then I think robust code would need to always accept it, even if the encoding can support an empty string. So there's a cost of a few instructions to specifying this.

[EskoDijk]

I see what you mean now! But defining a string like "none" or "default" would not be needed because the default variation also has a real name. See Section 4.2.3: in the cBRSKI context for example, "rrm-cose" is the name of the default method. So if the given discovery method doesn't support empty strings it would just use "rrm-cose". That's what I meant with "default alternative with name".

[becarpenter]

Got it!