You're doing it wrong. First, some background reading on MSDN:
When you use
assoc .ext=fileType, that fileType is actually the ProgID. As the last link above states:
The proper format of a ProgID key name is [Vendor or Application].[Component].[Version], separated by periods and with no spaces, as in Word.Document.6. The Version portion is optional but strongly recommended.
The file type description you can add as a FriendlyTypeName value in the registry.
Here .txt is obviously the extension and the (Default) value is set to the ProgID i.e. txtfile.
Here for the ProgID we have the (Default) value set to the file type description, and same for FriendlyTypeName. In general though the latter is used to display localised string resources and must be formatted as an indirect string (a fully qualified file name and resource value preceded by the @ symbol, for instance
@%SystemRoot%\system32\notepad.exe,-469 for txtfile).
I don't know why
ftype both allow you to use spaces in the fileType/ProgID strings, since that goes against MS' own guidelines. ProgIDs with spaces even work properly if created manually in the registry (I just tested), but significantly I found not a single ProgID created by any program that uses spaces. Stranger still is how
ftype seems to reject spaces while getting data (quotes don't help), whereas it has no problems accepting them while setting the command string in the first place (quotes aren't even required while setting).
My guess is someone forgot to inform the
ftype devs of this discrepancy, because I couldn't figure out a way to make the command retrieve the command string it had itself set previously for a ProgID containing spaces. My advice? Stick to the guidelines, don't use spaces in ProgIDs and save yourself the grief of trying to figure out Windows' quirks.