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

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

At 01:16 PM 2/15/00 -0800, [email protected] wrote:
>> >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.
>
>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.
>
>> >    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.
>
>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.
>
>> >    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?
>
>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

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