Re: Last Call: Indicating media features for MIME content to (fwd)

Comments from Ned Freed. Can you comment please, and IF you find that you
want to tweak the I-D, let me know _before_ you start doing that process,
and then, when I say ok, let me know when the new I-D is announced.

   Thanks, Patrik

---------- Forwarded Message ----------
Date: måndag 14 februari 2000 14.00 -0800
From: [email protected]
To: [email protected]
Subject: Re: Last Call: Indicating media features for MIME content to


Here are my comments on these documents:

   Comments on draft-ietf-conneg-feature-type-02.txt:

   I'm very concerned about the handling of content-type parameters in
   section 3. I really don't like allowing them as part of the type tag. I
   see real problems with canonicalization, ordering, case sensitivity, and
   so on.

   I suggest that content-type parameters be excluded from the type feature
   tag. If we need to be able to describe parameters (and I think we do need
   to be able to do this, if only to handle charset= for text subtypes),
   I would suggest defining a new tag "type-parameter" whose value is of the
   form "name=value". (I'm assuming that a feature tag can be repeated with
   different values; if not then there's a real problem representing MIME
   information in feature tags.)

   Comments on draft-ietf-conneg-content-features-02.txt:

   In section 3, I think the interaction between filter syntax and header
   line folding needs to be stated explicitly. According to RFC 2533,
   whitespace is allowed between lexical elements of a media feature
   expression. This then interacts in a nice way with RFC822/MIME header
   folding rules, since it lets you fold long expressions in
   content-features fields to avoid line length restrictions.

   I would suggest adding a new section 3.1 (and moving the others down
   one) that explains this fact, and suggests putting plenty of whitespace
   into content-features header fields so that folding will be facilitated
   in agents that otherwise don't grok the syntax of the field.

   I am concerned about the section 3.1.2 "No one-to-one relationship
   between headers and contained body parts is assumed" rule, especially in
   the case of multipart/alternative. I think it would be useful to have
   the ability to express specific per-part content features in the
   multipart/alternative case. And more importantly, I think people are
   likely to assume a relationship unless this restriction is called out a
   lot more aggressively in the document.

   If there's a strong consensus that specific per-part indicators are too
   complex (and I do see the issues with multipart/alternative where the
   parts are themselves composite) or have other problems and hence this
   restriction should be retained, that's fine. But in such a case I would
   use language like "implementations MUST NOT assume a one-to-one
   relationship" in section 3.1.2, I would reiterate this point in section
   4.3, and I would deliberately make the example in section 4.3,
   incomplete, out of order, more complex, or perhaps all three.

   In section 5 (security considerations) the issues associated with the use
   of this facility in conjunction with multipart/signed should be
   elaborated. In particular, putting content-features information outside
   the signed object has the virtue of not requiring a parse of the
   message, but since it isn't protected under the hash could be tampered
   with, possibly fooling implementations into not displaying material they
   really can handle, or displaying information they really can't handle.
   On the other hand, putting content-features information inside the hash
   means implementations have to parse the structure to find it, but it
   will be protected there.

That's it for these documents. I have some comments on some other conneg
documents that I'll send in separately to the WG list.

				 Ned

---------- End Forwarded Message ----------