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

From: Patrik Fältström <[email-masked]>
Date: Tue, 15 Feb 2000 07:25:49 +0100

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-masked]
To: [email-masked]
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 ----------

---

From: Graham Klyne <[email-masked]>
Date: Tue, 15 Feb 2000 12:00:50 +0000

>and then, when I say ok, let me know when the new I-D is announced.

Patrik,

I think there are some useful comments here.  I think a revision would be 
good, but I'd like to clarify with Ned some of the points raised before 
proceeding.

#g
--

>    information in feature tags.)

I generally agree with the basic premise -- I have tried to discourage the 
use of parameters in type parameters, but was maybe too timid in not 
prohibiting them outright.  I personally have no problem, with outright 
prohibition of parameters within a "type" value.

However, I don't think that Ned's proposed solution works too well, for a 
couple of reasons:

(a) the assumption that a tag can be repeated with different values does 
not hold:  the logical structure of feature expressions assumes only one 
value can be asserted for a given feature tag in any  particular feature 
collection ("instance").  For example, suppose we have three type parameters:

     charset=US-ASCII
     charset=UTF-8
     language=EN-US

is this to mean all three must be simultaneously true (logical AND, leading 
to a contradiction), or that any one must be true (logical OR, which fails 
to assert anything about charset of language), or some combination such as:

    (& (| (charset=US-ASCII) (charset=UTF-8) ) (language=EN-US) )

The intent of the feature framework is to be able to capture combinations 
like the final example.

(b) one of the design principles that we agreed for feature tags is that 
the _meaning_ of a tag should _never_ depend on the value of another 
tag.  This would be violated by having a generic 'type-parameter' tag whose 
meaning would depend on the value of a 'type' tag.

The solution I would suggest is that new feature tags are defined for 
content-type parameter values that are significant for content 
negotiation/description.  Paul Hoffman has prepared a draft dealing with 
charset and language, which I would like to see progressed on a similar 
timeframe to these.

>    content-features fields to avoid line length restrictions.

OK.  I am entirely happy to add some text to this effect.

>    in agents that otherwise don't grok the syntax of the field.

Good point.

>    lot more aggressively in the document.

I had taken the view that per-part content feature indications would be 
expressed by applying 'Content-features' directly to the part concerned.

Maybe my text isn't clear?  I had meant to say that there was no 1:1 
correspondence between headers on the outermost content-type and the 
contained body parts.  e.g:

     Content-type: multipart/alternative;boundary="next"
     Content-features: (<foo>)
     Content-features: (<bar>)

     --next
     Content-type: text/plain
     Content-features: (<foo>)
      :
     --next
     Content-type: text/html
     Content-features: (<foo>)
      :
     --next
     Content-type: image/tiff
     Content-features: (<bar>)
      :
     --next--

The intent here is allow the multipart/alternative to give an indication of 
what lies inside, without having to be specific about _where_ inside it may 
be found.

>    incomplete, out of order, more complex, or perhaps all three.

Is this affected by my explanaton above?

>    means implementations have to parse the structure to find it, but it

I think that's a useful addition.

--end--

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

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 15 Feb 2000 14:07:07 +0100

> good, but I'd like to clarify with Ned some of the points raised before

Definitely. It might happen that some more comments will pour in from other
IESG members the next week or so (until we discuss the document next
thursday), so take it easy with doing too much work. Resolv issues with
Ned, perfect! Update document, maybe not yet.

  paf

---

From: [email-masked]
Date: Tue, 15 Feb 2000 13:16:38 -0800 (PST)

> charset and language, which I would like to see progressed on a similar

I'm not particularly fond of this as it creates an open-ended registration
problem. However, given the way this stuff works I agree there is realistically
no other way to do it. So I suggest proceeding by prohibiting parameters from
the content-type feature tag and adding text describing what must be done when
such parameters come up.

> what lies inside, without having to be specific about _where_ inside it may

That's fine, but in such a case you need to be very clear that's what's
intended. The problem is that people will naturally assume ordering in such
a case.

> Is this affected by my explanaton above?

No, your explanation makes these changes necessary IMO. All this is doing is
making it very clear that there is no order to these sets.

				Ned

---

From: Graham Klyne <[email-masked]>
Date: Wed, 16 Feb 2000 12:16:26 +0000

Ned,

I think we are in agreement.  To summarize the proposed changes (mainly for 
the benefit of others following this):

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

(a) restrict content of type to content-type only, without parameters.

(b) add text explaining how to deal with content-type parameters.

draft-ietf-conneg-content-features-xx.txt:

(c) clarification of interpretation of Content-feature headers on outer 
multipart.  Specifically, MUST NOT assume relationship between outer header 
and any specific inner part.  Also explain that content-feature can be 
applied directly to any inner body part.

(d) add text pointing out that whitespace is allowed in feature 
expressions, and that this facilitates header wrapping.

(e) add text to security considerations about placement of content-features 
header on a multipart/signed document.

#g
--

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