- 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