On Sun, 18 Nov 2001 ned+xml-mime(_at_)mrochek(_dot_)com wrote:
My thinking is that, if an application is XML aware, it can take take
advantage of namespace identifiers to obtain more detailed 'subtype' data
than a content-type header can provide. The rationale for expanding this
outside of the content-type header is that the header is too limited to
express much detail about the payload content -- and, as you quite rightly
note, the parameter extension mechanism is largely ignored.
Defining additional header fields for this purpose is NOT the answer.
There's already a very complete, extensible system for indicating media
features in MIME. See RFC 2912 for details.
Thank you for this -- the mechanism described in 2912 (with syntax
detailed in RFC 2566) seems to allow for all that I (and I believe others)
have suggested, and much more.
Defining the necessary tags for namespace identifiers and so on would seem
to me to be reasonably straightforward.
Yes.
The background questions, however, are these -- i) how can you reveal more
about the type of a MIME part, and ii) how useful would that information
really be.
i is a solved problem. ii remains to be seen. Thus far I've seen little use
made of this facility.
I think (ii) is the $1000 question. A $500 question might be: "Did the
authors of RFC 3023 consider the RFC 2912 mechanism for providing internal
data about XML typed data?" (RFC 2912 isn't mentioned in 3023).
I can imagine many possible reasons (e.g., easy adaptation for current
MIME dispatchers), but would like to know which one the authors found most
compelling.
I'd also am curious to know if others see the contet-features: header as
an appropriate mechanisms for providing additional 'internal' data about
XML message parts.
Best wishes --
Ian