Re: LC comments on draft-yevstifeyev-http-headers-not-recognized-08.txt

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? 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. 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.
> It's also under-specified; e.g, I haven't seen any analysis on the interaction of this mechanism with hop-by-hop headers, nor with content negotiation, nor with caching.
The points you raised are important, so I'll try to add some description 
in the next versions.
>
>
> Furthermore, the draft enables implementation of an anti-pattern for HTTP, by offering an alternative to the 'must ignore' pattern. I understand that the intent of the header is to enable debugging, but if it gains deployment, it will be very tempting for developers to build on top of it.
>
> Therefore, I recommend that this draft NOT be published as an RFC (of any kind).
> Regards,
>
>
I think the following issue seems to be discussed by this document too - 
if not only the server, but the client does not recognize on of the 
header in received packet. I wonder this problem wasn't raised so I'll 
try to make the corresponding changes in the draft ASAP.

I'll let you know when the new version of the draft will be available.

All the best,
Mykyta Yevstifeyev

> Begin forwarded message:
>
>> From: The IESG<iesg-secretary@ietf.org>
>> Date: 14 December 2010 12:28:08 AM AEDT
>> To: IETF-Announce<ietf-announce@ietf.org>
>> Subject: Last Call:<draft-yevstifeyev-http-headers-not-recognized-08.txt>  ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC
>>
>>
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - ''Headers-Not-Recognized' HTTP Header Field'
>>   <draft-yevstifeyev-http-headers-not-recognized-08.txt>  as an
>> Experimental RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2011-01-14. Exceptionally, comments may be
>> sent to iesg@ietf.org instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/
>>
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>> _______________________________________________
>> IETF-Announce mailing list
>> IETF-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>

Received on Tuesday, 14 December 2010 16:53:41 UTC