- From: Mykyta Yevstifeyev <evnikita2@gmail.com>
- Date: Sat, 08 Jan 2011 12:19:46 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: IETF Discussion <ietf@ietf.org>, httpbis Group <ietf-http-wg@w3.org>, ietf-message-headers@ietf.org, iesg@ietf.org
08.01.2011 10:34, Julian Reschke wrote:
> On 08.01.2011 07:21, Mykyta Yevstifeyev wrote:
>> Hello all,
>>
>> This document summarizes the Last Call for
>> draft-yevstifeyev-http-headers-not-recognized.
>>
>> The Last Call was requested on 11 December, 2010 by Alexey Melnikov and
>> was announced on 13 November, 2010. The period of 32 days has been
>> assigned for this Last Call, that ends on 14 January, 2011.
>>
>> The Last call has been requested for version -08. However during the
>> Last Call 3 new versions appeared. The latest one is -11, submitted on 8
>> January, 2011
>
> If a draft changes three times during LC, there may be a problem. I
> encourage you to go back to the drawing board, and think hard(er about
> the feedback you got, in particular
> <http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0645.html>.
Why do you think that the draft shouldn't be changed during LC?
Moreover, I had some reasons for doing that. firstly, version -09 added
the section that was not present in -08 and if I added it now, there
would not be a possibility to discuss it. Version -10 presented the
most stable one to reflect all the comments I received during the LC.
And -11 was prepared as final for IESG review.
I have fully answered all the question form the message you refer to.
>
> I also mentioned at least once that in many frameworks this is
> essentially un-implementable, as different types of header fields are
> processed by different, independent layers in the code, and thus
> there's no way some part of the code will ever *know* which headers
> have been "processed". Do you think that this is not a problem?
That is the issues that would be decided by the implementators.
Moreover, one code layer may support this technology while others may not.
>
>> ...
>> * Syntax: Changed. Now is not /token**/but /1*VCAHR /for definition
>> of the name of the header.
>> ...
>
> Why?
RFC2616 gives the following definition of token:
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" |">" | "@"
| "," | ";" | ":" | "\" |<">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
And non-visible chars are not allowed in headers. So only VCHARs.
>
> Best regards, Julian
>
Received on Saturday, 8 January 2011 10:19:57 UTC