RE: Review of Content-Encoding: value token [exi]

Roy,

Thanks for this clarification. Putting content-coding and transfer-coding
value tokens in the same namespace as a way to ensure the tokens have the
same meaning when used in different contexts makes a lot of sense. I'm glad
to hear it doesn't mean that any transfer-coding can be used as a
content-coding or vice-versa. 

I'm assuming when the registries are merged there will still be some way to
identify which tokens are valid for which contexts, right? (e.g., so it is
clear that "chunked" is not a valid content-coding). 

	Thanks,

	John


> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@gbiv.com] 
> Sent: Wednesday, August 26, 2009 9:15 AM
> To: Mark Nottingham
> Cc: Henrik Nordstrom; John Schneider; HTTP Working Group; 
> Julian F. F. Reschke
> Subject: Re: Review of Content-Encoding: value token [exi]
> 
> On Aug 26, 2009, at 2:36 AM, Mark Nottingham wrote:
> > On 26/08/2009, at 5:28 PM, Henrik Nordstrom wrote:
> >> ons 2009-08-26 klockan 10:56 +1000 skrev Mark Nottingham:
> >>
> >>> That said, it would be good if what you do is done with an eye 
> >>> towards the new regime, to reduce the amount of problems 
> we see down 
> >>> the road.
> >>> In particular, it looks like the content-coding and 
> transfer-coding 
> >>> registry will be one and the same, so it would help if you could 
> >>> design your registration with that in mind.
> >>
> >> They can not be entirely the same
> >>
> >> transfer-encoding must by definition be lossless or it 
> will fail HTTP 
> >> operations, while content-encoding don't.
> 
> Being in the same registry just means they share the same 
> namespace, not that they can all be used equally.  chunked is 
> not a content- encoding but it is still a way of encoding 
> content, and we certainly don't want to allow someone to 
> register a different coding with the name "chunked"
> for use as a content-encoding.
> 
> ....Roy
>

Received on Wednesday, 26 August 2009 19:47:07 UTC