Again, I'm not especially supportive of the frob as I fail to see very much
utility in it. But I also don't oppose it. I see it as "mostly harmless".
here's the question: say someone else wants to define another frob,
and it's orthogonal to xml. does a type that uses both the new
frob and the xml frob then become application/foo-xml-newfrob
or application/foo-newfrob-xml?
And the answer is that we need to define a rule, probably as part of the
current proposal. It can be any of:
(1) Any additional things of this sort are always added after the -xml, and
there's a clear ordering to them.
(2) Any additional things of this sort are always added before the -xml, and
there's a clear ordering to them.
(3) Any additional things of this sort can be added before or after the -xml,
but for any given type there is one and only one valid ordering.
I don't much care which of these we pick. In fact we actually don't even need
to have a rule now, but if we ever added another of these in the future we'd be
forced to use rule (2) at that point, since anything else would not be
backwards compatible.
or do MIME readers have to recognize both forms?
Absolutely not. This would be a fundamental change to the namespace where names
would no longer be unique strings, and there's no need for it in any case.
what happens when there are three frobs?
One of the rules applies.
can they appear in any order?
No.
if we're going to add frobs to content-types, then it seems like we
should do this in a way that allows for extensibility.
Extensibiity can actually be deferred if we want to. See above.
Ned