Subject: Content features and feature type

From: Ted Hardie <[email-masked]>
Date: Wed, 3 Mar 1999 15:57:52 -0800 (PST)

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-masked]

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Mar 1999 16:27:22 +0000

Ted,

Thanks for your comments:  my responses below.

At 15:57 03/03/99 -0800, Ted Hardie wrote:
[...]
>other terms.  This actual applies to -content-features- as well.  

Done.

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

>a word, probably "information", after the "detailed media feature" phrase.

Yes, fixed.

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

>come up with appropriate examples for those, it would be greatly

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-masked])