jpalme(_at_)dsv(_dot_)su(_dot_)se (Jacob Palme) wrote on 21.04.00 in
<v04210104b525c2f22a5b(_at_)[130(_dot_)237(_dot_)150(_dot_)138]>:
Possible solutions:
(a) Use content-type such as application/foobar-xml, where
"-xml" tells the mailer, that if no special "foobar-xml"
handler is available, then a general-purpose application/xml
handler should be used.
(b) Use content-type such as application/foobar, and add a
parameter to this content-type such as
Alternative-Content-Type: application/xml.
(c) A variant of (b), where the added header is named
Super-Content-Type: application/xml.
Pros and cons of the different solutions:
Solution Pros Cons
(a) application/ No change to Not neat to require
foobar-xml MIME specs. mailer to parse the
subtype string.
Will be handled right
even by software
ignorant of the
convention
(b) Alternative- Easy to implement, Some mailers which
Content-Type parameter neat. do not know of this
parameter may be
confused.
Also, worthless until
supported by both sides
(c) Super- Gives MIME new Should be carefully
Content-Type parameter powerful capability thought-through
with object-oriented to fit other possible
structure of content- uses, what about
types. several levels of
superclassing for example?
Also, worthless until
supported by both sides
My conclusion is that (b) seems to be the best alternative, unless
we want to really think through an object-oriented structuring of
subtypes.
So far, I've found the arguments for a far more convincing than those for
any alternative.
MfG Kai