Re: [xml-dev] Registration status

Ian Graham <[email protected]>
Newsgroups gmane.ietf.xml-mime
Message-ID <[email protected]>

On Sun, 18 Nov 2001 [email protected] 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.