Re: 203 Non-Authoritative Information: deprecate?

This now makes an interesting case, today. If ISPs enforce maximum data 
limits per month (not just bandwidth), then what part is their 
responsibility to use protocols that make effective use of the given 
bitstreams? I think ISPs would want to implement 203 in order to opt-out 
of any cause that increases header size or opt-out of causes that would 
otherwise not keep the header data immutable as possible.

That opens the debate where there are any imposed data limits and the 
203 occurs such that the excess 'non-authoritative information' falls 
into liabilities. Do people pay for authoritative usage? Are there any 
specific ISP directive that deems "only allow authoritative 
information", especially if the end-user is being held liable for such 
usage by the ISP.

The 200 could indicate the header usage is idempotent, yet anything 
added after the origin server would need to reply with 203 (except maybe 
hops through DNSSEC). I chose this way to speak-up about this rather 
then the details of many of possible liabilities (like when the response 
should be 203 instead of 200), especially in consideration of power 
consumption, efficiency, sustainability, and emergency response.

That is only some of the reasons why I pointed out the earlier method of 
header tokenization. (Now, if there is some clear idempotent way to 
reuse that header token such that parses well with extra authoritative 
information like alignment in media fragment headers...)

On 05/28/2011 12:55 PM, Dzonatas Sol wrote:
> I'm glad you put "max-conns" in 
> http://www.ietf.org/id/draft-nottingham-http-browser-hints-01.txt so 
> we can pre-set the Connection-UUIDs  with a POST context to the UA.
>


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

Received on Sunday, 29 May 2011 16:09:10 UTC