Subject: Review of CONNEC MIME documents

From: Jacob Palme <[email-masked]>
Date: Fri, 16 Jul 1999 16:00:01 +0200

At the IETF meeting in Oslo, I was asked to review some
CONNEC documents from a MIME viewpoint. Here is that review.
I am not a subscriber to the ietf-medfree mailing list,
so if you want me to see your comments on this message,
then include me in the recipient list for these comments.

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

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.

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.

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

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

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

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.

------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

---

From: Graham Klyne <[email-masked]>
Date: Tue, 20 Jul 1999 15:18:57 +0100

>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

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.

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

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

>draft-ietf-conneg-feature-type-01.txt and the charset

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

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.

>RFC 2387, should be references?

Yes.

>draft-ietf-conneg-feature-type-01.txt

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