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

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