Subject: Comments on conneg-content-feature-01

From: Maurizio Codogno <[email-masked]>
Date: Wed, 14 Jul 1999 19:04:54 +0200 (MET DST)

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

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

I have no other comments:the draft seems really fine.

ciao, .mau.

---

From: Graham Klyne <[email-masked]>
Date: Tue, 20 Jul 1999 10:54:14 +0100

>something which is text/html in black and white?

Basically, yes.

>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

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.

>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-masked])

---

From: Maurizio Codogno <[email-masked]>
Date: Tue, 20 Jul 1999 19:08:27 +0200 (MET DST)

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