[
Lists Home |
Date Index |
Thread Index
]
Simon St.Laurent wrote:
> robin.berjon@expway.fr (Robin Berjon) writes:
>>>I'm not entirely sure what you're looking for - and Len's reply
>>>makes me even less certain - but Content-Type header fields
>>>definitely take parameters:
>>
>>Content-Type, yes, Content-Encoding/Accept-Encoding (aka content
>>codings), no:
>>
>>http://www.w3.org/Protocols/rfc2068/rfc2068
>
> Thanks - that makes it clear. Seems like an odd omission.
It is indeed. But there is no work that I know of going on around HTTP so I'm
unsure how much can be done.
> Has anyone taken this particular challenge up with the IETF?
I've talked with IANA people about the registration of new content codings
(since they're in charge of it), and asked if adding parameters would be ok.
They kindly answered that they had to dig up a very old form from some random
location and that they had no idea. Something in the kind tone suggested that
they might as well have been communicating with a perfect alien. Either way, a
new content coding needs to be a RFC -- which is where the issue would likely be
banged on -- so I had no chance to look further into it.
No one I could find seems to know why parameters are not allowed there.
> (I worry that other people will read it the way I did and start hacking
> encoding parameters into Content-Type rather than use Content-Encoding.
But then we can point fingers and laugh at their bad taste.
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway http://expway.fr/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
