Re: Content features and feature type

Ted,

Thanks for your comments:  my responses below.

At 15:57 03/03/99 -0800, Ted Hardie wrote:
[...]
>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.  

Done.

>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.

In drafting this, I did not feel a need to use RFC2119 conventions for
indicating normative elements.  If the WG feels that this is needed to make
the 'type' feature tag meaning clear then that's fine (but we'll need to
agree where the normative indicators should be placed).

In the particular example you mention, I don't see any fundamental
difference in meaning between using 'should' or 'SHOULD' here.  I've looked
at your proposed re-wording of the note, and come up with the following
which I think draws out the points you were trying to make:

  NOTE:  content type parameters in a 'type' 
  value are strongly discouraged, but not 
  prohibited.  In deciding whether or not to 
  include a parameter value, implementers should 
  bear in mind the feature set matching rules 
  [1].  These would cause 'type' values with and 
  without parameters to be treated as completely 
  distinct values, which may lead to unexpected 
  results.

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

Fixed.

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

Yes, fixed.

>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?

I've changed "suggest" to "indicate".

I saw no compelling reason to forbid such a discrepancy, particularly when
enforcing the prohibition might prove problematic.  In normal use, I see no
reason to do this, but I had to allow the possibility in order to go on and
state that Content-type must take precedence for the purposes of MIME
handling.

A total prohibition would be difficult because some composite types are not
obviously so;  e.g. the application/zip example from section 3.1.2.

>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.

I had intended that the external data reference be embodied in
multipart/alternative.  (This picks up on an idea raised a couple of years
ago, about an "Alternates" header being equivalent to message/external-body
within multipart/alternative.)

I agree that multipart/alternative might be a big user.  It might be a good
idea to also have a simpler multipart/alternative example (with a repeated
content-type and different features) -- what do you think?

I've added a placeholder for multipart/related, but I could definitely use
some help with an example.  Is there anything in the multipart/related RFC
I can plunder?  Do you know the RFC number off the top of your head?

Many thanks for all your comments.

#g

------------
Graham Klyne
([email protected])