Re: Comments on conneg-content-feature-01

At 19:04 14/07/99 +0200, Maurizio Codogno wrote:
>I read the draft, and there is some point I don't understand.
>
>- sect. 3.1.2: which is the reason, then, to have Content-features in the 
>main header lines, like in example 4.3? Is it just to warn the receiver
>that there is something which is text/html with limited colors and 
>something which is text/html in black and white?

Basically, yes.

>I would found it more logical if the features indicated in the main
>header have to be applied to all the parts of the message, like in the 
>fax example in 4.2.

Hmmm... the whole point of example 4.3 (multipart/alternative) was to show
different alternatives with the same content type might offer different
media features.

Also, in the case of fax, it is conceivable that different parts of (say) a
multipart/mixed would use (say) different resolutions.  (A particular case
with Internet fax is a composite type called MRC which combines multiple
sets of image data with different features in a single content type).

There are several ideas at work here:  one of them is to extend the ideas
inherent in the 1-pass multipart/alternative proposal to media features as
well as content type.  Another is to allow visibility of contained or
indirectly referenced media features (including content type) to a
receiving agent without requiring the inner MIME parts to be parsed.

It seems that I may need to do a bit more work on the motivation for this
section.

>It could be also nice to have a pseudofeature
>with the name of the relevant part: this is not really important
>for a multipart message, but in the case of a file whose type is
>application/zip you can choose to uncompress (inflate, or whatever) 
>only the files you can render.

Hmmm... I was trying to avoid getting into this area.  If this is *really*
required, then I would suggest using say a multipart/related, maybe with a
top-level "index" indicating subsidiary parts and associated media
features.  But I think there is too much here for what was intended to be
addressed by the content-features draft.

>- sect. 5: Maybe an example could be added to explain the last sentence:
>who knows, knowing that the file is text/html tells the attacker that 
>there is a lot of "<" and ">" chars.

My thinking was not so subtle!  I propose updating the last sentence to:

  In doing this, take care to ensure that the purpose of 
  encryption is not compromised  (e.g. encryption might be 
  intended to conceal the fact that a particular 
  application data format is being used, which fact might 
  be disclosed by an injudiciously applied Content-features 
  header).

#g

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