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=="")