We might have to find a better way for dealing with content-formats which contain additional parameters in the future. At the moment, only the part before the first ; is being used. This approach, however, is not usable with new content-formats like application/cose; cose-type="cose-encrypt" or application/cose; cose-type="cose-mac" where the parameters actually contain important information.

@awwright: Would you still be interested in this issue?

I recall the reason I didn't was because it could break backwards compatibility in applications that use merely text/plain to refer to format 0. I'm not sure how much of a problem this actually is or a good way to fix it.

I recall the reason I didn't was because it could break backwards compatibility in applications that use merely text/plain to refer to format 0. I'm not sure how much of a problem this actually is or a good way to fix it.

Hmm, yeah, I am not so sure either. Maybe a more complex process (i. e. actually parsing the parameters) is needed to distinguish different content-formats, at least when they are given as an input. In any case, considering the potential breaking change it might be better to defer this PR to version 1.0.0.

Pull Request Test Coverage Report for Build 1282106479

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.006%) to 89.828%

Totals
Change from base Build 1280604248:	0.006%
Covered Lines:	1091
Relevant Lines:	1182

💛 - Coveralls

I now opened and merged #282 which deals (partly) with the parameters issue. I am closing this PR for now but Content-Format 0 should probably be revisited in the future.