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

At 07:25 AM 2/15/00 +0100, Patrik Fältström wrote:
>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.

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


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

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.


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

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


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

Good point.

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

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.

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

Is this affected by my explanaton above?


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

I think that's a useful addition.

--end--

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