Content features and feature type

As usual, many thanks to Graham for his work on the recent set of
drafts related to MIME content types.  I have a very small number of
comments on the two drafts, so I'm going to combine them into a single
message.

In -feature-type-, which registers a feature named "type" which corresponds
to MIME Content-type, I suggest moving the definition of media feature
to the top of 1.1, just so that the grounding work is laid for the
other terms.  This actual applies to -content-features- as well.  

In -feature-type-, section 3. I'm not sure whether the should in
"The media type should be given without any parameter value" is
a SHOULD or is not normative.  I believe that it would be okay for
it to be normative at the SHOULD level.  If that is the consensus
of the group, I would change the note to read

NOTE: Implementors should keep in the feature set matching in [1] when
deciding whether to include parameters in "type" values.  Each string
will be considered a distinct value, and types with parameters will
not match those without parameters.

The NOTE in -feature-type- section 4.3 seems to be formatted incorrectly.

In -content-features-, I believe the first bullet in section 2. is missing
a word, probably "information", after the "detailed media feature" phrase.

In -content-features- section 3.1.1., the text states that the Content
features header "may suggest a content type that is different than that
given by the MIME 'Content-type:' header".  I'm not certain what is
meant by "suggest" here, but I really don't see why we would allow that.
What's the rationale here?

If we are going to treat multipart/* MIME types, I believe we must
have examples for both multipart/alternative (which I suspect is a
big potential user) and multipart/related.  If anyone can help Graham
come up with appropriate examples for those, it would be greatly
appreciated.
			regards,
				Ted Hardie
				[email protected]