[avahi] Binary data in TXT records

[Jeff Koftinoff]

I just read the following from http://www.zeroconf.org/Rendezvous/txtrecords.html which states that while it is a TXT record, the NAME is ASCII, but the VALUE is 8 bit binary and you SHOULD NOT convert binary values into hexadecimal ascii!

What is the best way to encode binary values in a TXT record as defined by the xml service file in avahi? 

Does avahi handle embedded nulls in the value?

Regards,
Jeff Koftinoff
Rules for values in DNS-SD Name/Value pairs

If there is an '=', then everything after the first '=' to the end of the string is the value. The value can contain any eight-bit values including '='. Leading or trailing spaces are part of the value, so don't put them there unless you intend them to be there. Any quotation marks around the value are part of the value, so don't put them there unless you intend them to be part of the value.

The value is opaque binary data. Often the value for a particular attribute will be US-ASCII (or UTF-8) text, but it is legal for a value to be any binary data. For example, if the value of a key is an IPv4 address, that address should simply be stored as four bytes of binary data, not as a variable-length 7-15 byte ASCII string giving the address represented in textual dotted decimal notation.

Generic debugging tools should generally display all attribute values as if they were UTF-8 text, except for attributes where the debugging tool has embedded knowledge that the value is some other kind of data.

Authors defining DNS-SD (Rendezvous) profiles SHOULD NOT convert binary attribute data types into printable text (e.g. using hexadecimal, Base64 or UU encoding) merely for the sake of making the data be printable text when seen in a generic debugging tool. Doing this simply bloats the size of the TXT record, without truly making the data any more understandable to someone looking at it in a generic debugging tool.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/avahi/attachments/20100810/27eb9f21/attachment.htm>