> OK. So, let me make sure I have this straight. There are MIME types > that are, to the parser, opaque--it doesn't actually need to be aware of > these types or how to handle them, it just needs to return the content > to the caller (handling the proper decoding if necessary). For example, > application/*, audio/*, video/*, image/*, text/*, etc.
Yes. > Then there are MIME types that have structural semantics to them, e.g. > multipart/*, message/rfc822. The parser DOES need to understand these > types. Yes again. > > Is that accurate? I think so, yes. > And by "new MIME types" you're referring specifically to additions to > the latter group, that would require the parser to be modified? Mainly, yes, but also other things like new encodings which can be added to the list of legitimate "things" without requiring a new version of any RFC to be produced. The point is that there are some things specified by a fixed version of an RFC, but others are taken from a list of allowed values. Where the item is on a list, like content types or encodings, you would have a much more future proof product if you design in the ability to add appropriate functionality in these areas without the need to modify the code which complys with the more static RFC specifications. d. > > -jmc > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
