Entering multiple DNS TXT values as a single TXT entry, with each value in " marks, but separated by spaces

I have done this with other DNS providers but I'm stuck on UltraDNS's DNS management interface. I need to enter multiple values in a TXT entry so they resolve as a single string with each value in " marks and separated by a space.

An example of what we want the TXT record to return is as follows (using dig for Linux to test these):

;; ANSWER SECTION:

name._avaya-ep-config._tcp.example.com. 119 IN  TXT "txtvers=1" "proto=https" "path=/acs/resources/configurations"

However, UltraDNS support said that we have to enter them as separate TXT records - when we do that it returns the below and the software that is looking for this TXT value doesn't recognize it and it doesn't work:

;; ANSWER SECTION:

name._avaya-ep-config._tcp.example.com. 218 IN  TXT "proto=https"

name._avaya-ep-config._tcp.example.com. 218 IN  TXT "txtvers=1"

name._avaya-ep-config._tcp.example.com. 218 IN  TXT "path=/acs/resources/configurations"

We have tried using double quotes, using \ for quoting per RFC, using also per RFC - based on RFC here: https://www.rfc-editor.org/rfc/rfc1464

When we tried some of the suggestions from the RFC example, UltraDNS's web interface wouldn't let us enter it saying we had to only enter ASCII characters (which all were, but they were also code for other ASCII char-sets).

Invalid Input: Only ASCII characters are supported for comment

When entering as this for example:

\txtvers=1\"<sp>\"proto=https\"<sp>\"path=/acs/resources/configurations\

The software also uses SRV and PTR records and those work - it's just not getting our path from the TXT value as it should due to this formatting issue.

What is important to recognize here is that a TXT record can be multi-valued, with the record data containing one or more strings, each up to 255 characters long.
Ie, one TXT record with multiple values and multiple TXT records with one value each are not the same thing and should not be expected to be interpreted the same.

What you showed initially is not actually a TXT record that has a single string with each value in " marks and separated by a space but rather a TXT record which has three separate string values that do not contain any quotation marks or spaces.
This understanding is particularly important as one of the things you tried to do in your attempts of solving the problem involved escaping these characters that are used for formatting purposes but are not actually part of the value.

For any software that understands and uses the DNS master file format (standard text representation of DNS records), what you included initially ... TXT "txtvers=1" "proto=https" "path=/acs/resources/configurations" would be understood and interpreted as one TXT record with three separate string values (txtvers=1, proto=https, path=/acs/resources/configurations).

If your service provider has an interface that does not accept this form of input and they provide no other means of inputting multiple values (the answer you received from them suggests that may well be the case) there may be no way of entering the desired record into their system.
If that is indeed the case, you may have to look at hosting this record elsewhere (including options such as not moving your full zone but having the desired TXT record in a different zone hosted elsewhere and only adding a CNAME pointing there, provided the software in question does not somehow disagree with this).

That said, in specialized uses of TXT as part of other standards, it's more common (with widespread examples such as SPF and DKIM) to define the use of multiple string values in a TXT record purely as a means of allowing long values and defining that all of the string values should simply be concatenated before further interpretation, instead using some internal delimiter (typically ;) for multi-value content inside that single, potentially long, string.

It is very possible that your service provider has looked specifically at the very common "long value" scenario and supports that in one way or another (particularly likely because of DKIM).
Either way, if the design of the software that consumes these records is at all up to you, it may be a better idea to simply conform to the norm in this regard and use the same approach to storing multi-valued content as is used in these widespread TXT specializations instead. (However, such a change would obviously impact compatibility with existing records if this system is already in use).