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

Mykyta Yevstifeyev <> Sat, 08 January 2011 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8059228C104; Sat, 8 Jan 2011 07:55:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.966
X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NOyLv07la4OR; Sat, 8 Jan 2011 07:55:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7E2F628C102; Sat, 8 Jan 2011 07:55:53 -0800 (PST)
Received: by bwz12 with SMTP id 12so17986280bwz.31 for <multiple recipients>; Sat, 08 Jan 2011 07:58:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=WW6Tf2aYO2x0f2qWEQ+6gJf79zetI1SlR3nIaUY8zno=; b=NmH9kLy/y+LoKv1mq3a3zFq0kOeiFU0S76yK1c4fd4BxDOSXlv5H3l2GXJor/0si3F NDy4iAvc5swJ+wx2JLIQ/Yw2aV5rKV/SEdCpdqmYYVXDtMSvEetVfA+3DPVlB8gB2zJB uZCEIpUjnr29rxk2yDnkUHWf5DKDeOUTvQ6eY=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=Pr4h537uu0hyKc5Qys62PBA4GwoVaCtKNVxRhDF7bMwmE7nDdGScztfguZPj/WJDaT uqkFILCOElc//pT+hggX3qfoQSY0O8UTtOm6RN3RLKMqXgx+sdvYgE/OPMLy0+jfVmgi r4CVr6gNKmyAOKS+isiIIctsu905I/ow1p7FA=
Received: by with SMTP id o9mr9257287bkj.191.1294502280380; Sat, 08 Jan 2011 07:58:00 -0800 (PST)
Received: from [] ([]) by with ESMTPS id v25sm14773122bkt.18.2011. (version=SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 07:57:59 -0800 (PST)
Message-ID: <>
Date: Sat, 08 Jan 2011 17:58:16 +0200
From: Mykyta Yevstifeyev <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv: Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Julian Reschke <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070004030808040705020602"
Cc:,, IETF Discussion <>, httpbis Group <>
Subject: Re: [Ietf-message-headers] Last Call Summary on draft-yevstifeyev-http-headers-not-recognized
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for header fields used in Internet messaging applications." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 08 Jan 2011 15:55:56 -0000

Hello all,

I have revised all the comments I received now and during the Last 
Call.  My previous message was just formal stating statistical data on 
LC.  Here I'd like to mention what I really think of the document and 
its further destiny.

Many LC comments referred to that it would be uninteresting and useless 
to implement this.  Maybe one of them seems the most interesting for me 
- it said about the 'Warning' headers that should be used in this 
occasion.  This, IMO, is one of the most suitable for me and this 
technology.  But if we implement this now using Warning, one problem is 
absence of IANA registry for Warning codes, such as for Status codes.  
As this message is now sent to httpbis WG mailing list, I ask you if 
there is a sense in creating such registry?

As for the initial draft, I think I'm about to withdraw /it /(but not my 
idea).  So result of Last Call seems to be the following: the idea in 
the current implementation as Internet-Draft does not seem to be 
appropriate.  So I'll raise this topic later.

All the best,
Mykyta Yevstifeyev

08.01.2011 13:17, Julian Reschke wrote:
> 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
>>> <>. 
>> 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