Re: Review of CONNEC MIME documents

At 16:00 16/07/99 +0200, Jacob Palme wrote:
>At the IETF meeting in Oslo, I was asked to review some
>CONNEC documents from a MIME viewpoint. Here is that review.

Jacob,

Thank you for your comments.  I will add my responses inline below.


>draft-ietf-conneg-content-features-01.txt
>-----------------------------------------
>
>Section 3.1.1 first line contains the word "should". The
>appearance of the word "should" in a standard is often
>confusing. Do you mean "SHOULD". If so, you should spell it
>in uppercase. If you do not mean "SHOULD" it might be
>better to use some other wording, which cannot be confused
>with the word "SHOULD".

This specification does not invoke RFC 2119 terminology.  There are two
main reasons for this:

(1) it is intended to be used as a protocol element as part of some
complete application protocol (e.g. Internet fax);  as such, I felt that it
was more appropriate for the master application protocol specification to
indicate the range of normative elements.

(2) as a matter of personal preference, I feel that the normative language
elements (MUST, SHOULD, etc.) are overused, at the expense of clear
unambiguous prose, so my approach has been to try and draft language that
clearly states the specifications.

That said, I would be happy to incorporate the RFC 2119 style of normative
terminology if the group feels that is helpful to understanding of the
specification.

>Section 3.1.1 first paragraph last sentence "This is
>possible but not recommended": This does not agree with the
>recommendation in 3.1.2 to use "Content-Type: Multipart"
>combined with another Content-Type in the
>"Content-Features" header.

I agree this is not entirely clear (I had intended the statement to be
qualified by the context of the section in which it appears).

I propose qualifying the sentence in 3.1.1 so that it reads:

  This is possible but not recommended when applied to a non-
  composite body part:  in any case, MIME content type 
  processing must be performed in accordance with the 
  'Content-type:' header.

>Section 3.1.2 perhaps you should specify that if the same
>content-feature occurs on both an outer and an inner MIME
>body part, then the inner feature applies, but that
>features on outer body parts which are not repeated on
>inner body parts will still apply to that inner body part.

Hmmm... content feature expressions are a bit more subtle than that:  e.g.
if I specify (dpi=200) on an outer body part, and (& (ua-media=screen)
(dpi=100) ) on a contained body part, which is to apply?

So, I think you raise two interesting questions here:

(1) is it appropriate to specify here what is meant when content-feature is
applied to a container and to a contained body part, or leave that to a
application protocol specification that invokes this specification?

(My view is that they would be processed separately:  content-features on
the container part might be used to decide  whether and how to process a
composite message, and any inner content-features would be used when
processing the body part to which they apply.  I don't think that
applications should necessarily be required to check consistency across
layers of wrapping.)

(2) if cross-layer combinations are to be processed, how should they be
handled?

(My view here would that they should be treated as a conjunction:  the
outer and inner features would be combined as:  (& (outer) (inner) ).  This
would permit an application to build up the kind of refinement that you
suggest.)

>Section 4 in general: See comment on
>draft-ietf-conneg-feature-type-01.txt and the charset
>parameter below.

OK, I'll add charset parameters where applicable to the content-type
headers in the examples.

>Section 4.2 should perhaps be liased with the IETF groups
>working on Internet Fax.

Yes, I agree.  That example was based on a (now obsolete) proposal to the
fax WG.  For the time being, I propose to change the content type on that
example to multipart/mixed and remove the content-coverpage header, but I
would certainly hope to maintain some alignment with current ideas the fax WG.

>Section 4.6: Possibly the standard for Multipart/Related,
>RFC 2387, should be references?

Yes.

>draft-ietf-conneg-feature-type-01.txt
>-------------------------------------
>
>The MIME standard (part 2) specifies: "In order to
>eliminate such ambiguity and variations in the future, it
>is strongly recommended that new user agents explicitly
>specify a character set as a media type parameter in the
>Content-Type header field."
>
>It is a well-known problem with not specifying any
>character set, especially since e-mail says that the
>default character set is US-ASCII, while HTTP says that the
>default character set is ISO-8859-1. If the standards were
>redone today, the charset parameter should be mandatory for
>all "Content-Type: Text"s. Because of this, it is not so
>nice that the draft gives many examples where no charset is
>specified, neither as a parameter to "Content-Type" nor in
>the "Content-Features" header. Suggestion: Specify the
>character set either in the "Content-Type: Text" or in the
>"Content-Features" header.

OK, I broadly agree.  But I don't want to put the charset parameter as part
of the value of a "type" feature tag, for reasons stated in the draft.

For the examples, I shall add a content-type charset parameter where
applicable.  For the expressions, there is a proposal by Paul Hoffman to
register charset and language feature tags:  I shall add a charset tag to
the relevant examples.


Many thanks for your comments.

#g

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