Re: Comments on conneg-content-feature-01

" >- 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 am not really sure that this is reallyuseful... I personally would 
add some words to the extent that such behavior is allowed, but that
it is preferred to put the Content-features: header just in each part
of the message. Otherwise, I think that a NOTE explaining why this
duplication could be useful will be greatly appreciated!


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

I have no problem with the concept. But if I would have devised the
protocol, I would have written in the global headers something like 

     Mime-Version: 1.0
     Content-Type: multipart/alternative; bounday="break"
     Content-features: (_internal_)

or whichever word you liked to warn the reader that (a) there are 
indeed Content-features: headers, (b) but since they are not the same
even for the same Content-Type, they are written on each part of this
multipart message.

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

Yup, but you are anyway required to parse at least the MIME headers for
those parts, in order to know which features they need. Ok, maybe to
have a pseudofeature to reference the file with exactly those features 
is not such a great idea: I agree it does not give a lot of 
further information. But I still doubt that having the complete set
of (unrelated) features for the parts in the global headers is useful
in the general case.


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

It's fine to me.

ciao, .mau.