Re: [Ietf-message-headers] Last Call Summary on draft-yevstifeyev-http-headers-not-recognized

Julian Reschke <julian.reschke@gmx.de> Sat, 08 January 2011 11:22 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: ietf-message-headers@core3.amsl.com
Delivered-To: ietf-message-headers@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02E93A69D2 for <ietf-message-headers@core3.amsl.com>; Sat, 8 Jan 2011 03:22:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.155
X-Spam-Level:
X-Spam-Status: No, score=-104.155 tagged_above=-999 required=5 tests=[AWL=-2.156, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKR0W9wsTtNY for <ietf-message-headers@core3.amsl.com>; Sat, 8 Jan 2011 03:22:43 -0800 (PST)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 4DFC03A69C5 for <ietf-message-headers@ietf.org>; Sat, 8 Jan 2011 03:22:42 -0800 (PST)
Received: (qmail invoked by alias); 08 Jan 2011 11:18:08 -0000
Received: from p508FD294.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.210.148] by mail.gmx.net (mp005) with SMTP; 08 Jan 2011 12:18:08 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+DHRo7j0SD6a8ivqtXRklqaF/7wzorxLC/8GaLXi ecmc82BxbUUBAI
Message-ID: <4D2847E1.9090004@gmx.de>
Date: Sat, 08 Jan 2011 12:17:53 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
References: <4D280272.6090402@gmail.com> <4D28218A.2020406@gmx.de> <4D283A42.3080303@gmail.com>
In-Reply-To: <4D283A42.3080303@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: iesg@ietf.org, ietf-message-headers@ietf.org, IETF Discussion <ietf@ietf.org>, httpbis Group <ietf-http-wg@w3.org>
Subject: Re: [Ietf-message-headers] Last Call Summary on draft-yevstifeyev-http-headers-not-recognized
X-BeenThere: ietf-message-headers@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for header fields used in Internet messaging applications." <ietf-message-headers.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-message-headers>
List-Post: <mailto:ietf-message-headers@ietf.org>
List-Help: <mailto:ietf-message-headers-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Jan 2011 11:22:44 -0000

On 08.01.2011 11:19, Mykyta Yevstifeyev wrote:
>> 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?

Because people assume stability during LC, and are unlikely to review 
the spec multiple times during the same LC.

Of course that does not mean that you can't start addressing issues 
during LC. Just do so in a way that it doesn't change what's being 
last-called. For instance, by publishing the current edits on a private 
web page.

If you have non-editorial changes, the AD will have to decide whether 
they require a new 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

There was no stability *because* of these updates.

> stable one to reflect all the comments I received during the LC. And -11
> was prepared as final for IESG review.

My recommendation to the IESG is to wait for a stable spec, and then 
restart the LC.

> 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.

How so? If a servlet does support it, but the servlet container does 
not, there's no way to generate a correct header field value.

>>> ...
>>> * 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.

That didn't answer my question. Why did you change something that was 
ok? It also shows why you'll need a new LC.

In this particular case the change wasn't only not necessary, but also 
changes the syntax significantly. VCHAR allows significantly more 
characters than HTTP's token, namely the comma that you already need as 
delimiter.

Well, assuming you mean the VCHAR definition from RFC 5234, because your 
spec doesn't clearly say where it comes from (you could import specific 
productions or all of them from 5234, but you should say that).

Speaking of which: you can't have a "_" character in a rule name.

Best regards, Julian