Mark, Some notes on what you said: 2010/12/14, Mark Nottingham <mnot@xxxxxxxx>: > > On 15/12/2010, at 2:16 AM, Mykyta Yevstifeyev wrote: > >> Hello all, >> >> Let me explain some issues which were mentioned by Mark. >> >> 14.12.2010 2:09, Mark Nottingham wrote: >>> The use cases for this draft are highly speculative and unproven, even >>> for something aspiring to be Experimental. I haven't seen any >>> implementers express interest in it. >>> >>> The draft does not cover what it means for a server to "recognise" a >>> header, yet it places a MUST level requirement on this; e.g., if a server >>> doesn't actively use the "Via" header, should it list it as not >>> recognised? What about X-Forwarded-For? Deploying this on a server as-is >>> means that a lot of extra bytes will be sent in responses (and not just >>> because the field-name is so long, although that doesn't help). If the >>> client sends a 'Range' header but the server chooses not to sent a >>> partial response, should it be listed? And so on... > >> Firstly, why do we speak about extra bytes to be transferred now, almost >> in 2011? Does it seem to be a great problem? > > I can point you at lots of people who work at Amazon, Yahoo, Google, Akamai > and other large-scale Web development shops who are painfully aware of both > the costs of bandwidth (especially in many non-US markets) and the effect of > adding packets on end-user perceived latency. It matters very much. > > >> And do you really think that there will be *a lot* of such bytes? >> Secondly, 'doesn't actively use' does not mean 'not supports'. The >> examples you list are not appropriate for the situation we are discussing. >> I mean that if the server completely does not support one of headers the >> client sent, it'll form the corresponding response. > > As it sits, it's impossible to say; your draft doesn't contain the word > "supports" "actively use" or anything else to describe how this mechanism > would work in practice, nor are there examples. > Yes, you are right, my draft does not contain these issues. But for this *draft* and *last call* stand for - comments and improvements. So I'll correct it. > >> And when the client receives, it will avoid sending the corresponding >> header(s) - so, using this header will allow to save 'extra bytes', as you >> say, than spend them. The proposal has the opposite effect than you >> describe. > > To achieve that effect, you have to get widespread support in both servers > and clients. Have you had any discussions with vendors of either? > At the moment I didn't. > What are your goals here, overall? From previous discussions, I'd thought it > was to provide a debugging mechanism. Here, you express interest in saving > bytes. I suspect that having both as goals will be pulling you in different > directions... The main goal is debugging - I was only trying to persuade you that that would not make 'extra bytes' sent but would have the opposite meaning. All the best, Mykyta Yevstifeyev > > Regards, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf