From evnikita2@gmail.com  Fri Jan  7 23:21:13 2011
Return-Path: <evnikita2@gmail.com>
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 D505928C0CF; Fri,  7 Jan 2011 23:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.217
X-Spam-Level: 
X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[AWL=0.381,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 2ksmS9v7E75V; Fri,  7 Jan 2011 23:21:11 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 6DE903A698E; Fri,  7 Jan 2011 23:21:07 -0800 (PST)
Received: by bwz12 with SMTP id 12so17809882bwz.31 for <multiple recipients>; Fri, 07 Jan 2011 23:23:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type; bh=+/oqtcoMqAV5vpXjVuK4MaXp6DJyCRd4E17Sr7MD+Tg=; b=L1FrxuBm6XN0Zb1HmxWRlUZRWIlPDCRj/ithdV1vK6IeJ1o/oiX104xNf/GaEPjZZi 8G/KA2Q5BEosWCU6I6DhmLKtRIfuO7VzFB0S34oiTg4j+aB0ZftlkB5IVcx1hY1bx85c dvjzpy8IDSSfubWpbWwADdk5grHH6O/xUtSD0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type; b=P9vcS6a4ObmVLuxK7NyxDUCU09gAlG1MmouPZKci8UIw2SyLr/LaqIvBGGQHRZvusV MNemiYk2W1tid2COdkq5VefN5JDYXx6JF1gNG4KAfJvd+gVKDdiyQnTpvbHfr+4ArT9u aoemqHBUW6G295V8CU2VH+OZzMr+9xiMCcDAI=
Received: by 10.204.67.140 with SMTP id r12mr3954806bki.147.1294467682093; Fri, 07 Jan 2011 22:21:22 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id a17sm14563747bku.23.2011.01.07.22.21.20 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 22:21:21 -0800 (PST)
Message-ID: <4D280272.6090402@gmail.com>
Date: Sat, 08 Jan 2011 08:21:38 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: IETF Discussion <ietf@ietf.org>, httpbis Group <ietf-http-wg@w3.org>,  ietf-message-headers@ietf.org, iesg@ietf.org
Content-Type: multipart/alternative; boundary="------------020108020706000600080603"
Subject: [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 07:21:14 -0000

This is a multi-part message in MIME format.
--------------020108020706000600080603
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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

This message contains the exhaustive analysis of changes made during the 
Last Call.

    * The intended status: Did not change; Experimental.
    * The name of the document: Changed. Was *'Headers-Not-Recognized'
      HTTP Header Field* and now is *HTTP 'Headers-Not-Recognized'
      Header Field. *I ask Alexey to change the Writeup of the document
      in accordance with the current version.
    * Abstract: Changed. Replaced *headers* with *header fields* and
      some other minor changes.
    * Introduction: Changed. Replaced *headers* with *header fields;
      *and*servers *with *hosts; *other minor changes.
    * Conventions: Changed. Added the definition of term host, gateway,
      proxy, tunnel.
    * Model of Work: Changed. Added more detailed description of action
      of different HTTP nodes.
    * Syntax: Changed. Now is not /token**/but /1*VCAHR /for definition
      of the name of the header.
    * IANA Considerations: Added the reference to RFC 3864.

You may also obtain this information from:

https://tools.ietf.org/rfcdiff?url1=draft-yevstifeyev-http-headers-not-recognized-11&difftype=--html&submit=Go!&url2=draft-yevstifeyev-http-headers-not-recognized-08

During the last call the following note from IANA was received:

> IESG:
>
> IANA has reviewed draft-yevstifeyev-http-headers-not-recognized-08.txt,
> which is currently in Last Call, and has the following comments:
>
> IANA understands that, upon approval of this document, there is a single
> IANA Action that needs to be completed.
>
> In the Permanent Message Header Field Names registry located at:
>
> http://www.iana.org/assignments/message-headers/perm-headers.html
>
> a single, new registration is to be added as follows:
>
> Header field name: Headers-Not-Recognized
> Applicable protocol: http
> Status: experimental
> Specification document: [RFC-to-be]
>
> IANA understands that this is the only IANA Action that needs to be
> completed upon approval of this document.
>
> Thanks,
>
> Amanda Baber
> IANA

No changes are intended to be made to the draft during the period up to 
14 January in order to allow IESG to review the document.

Looking forward to the opinion of IESG,
Mykyta Yevstifeyev

P.S. Apologizing if you receive multiple copies of the message. Mykyta.

--------------020108020706000600080603
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <font size="-1"><big>Hello all,<br>
        <br>
        This document summarizes the Last Call for
        draft-yevstifeyev-http-headers-not-recognized.<br>
        <br>
        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.<br>
        <br>
        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<br>
        <br>
        This message contains the exhaustive analysis of changes made
        during the Last Call.<br>
        <br>
      </big></font>
    <ul>
      <li>The intended status: Did not change; Experimental.</li>
      <li>The name of the document: Changed. Was <b>'Headers-Not-Recognized'

          HTTP Header Field</b> and now is <b>HTTP <span
            class="insert">'Headers-Not-Recognized'</span> Header Field.
        </b>I ask Alexey to change the Writeup of the document in
        accordance with the current version.</li>
      <li>Abstract: Changed. Replaced <b>headers</b> with <b>header
          fields</b> and some other minor changes.</li>
      <li>Introduction: Changed. Replaced <b>headers</b> with <b>header
          fields; </b>and<b> servers </b>with <b>hosts; </b>other
        minor changes.</li>
      <li>Conventions: Changed. Added the definition of term host,
        gateway, proxy, tunnel.</li>
      <li>Model of Work: Changed. Added more detailed description of
        action of different HTTP nodes.</li>
      <li>Syntax: Changed. Now is not <i>token<b> </b></i>but <i>1*VCAHR 
        </i>for definition of the name of the header.</li>
      <li>IANA Considerations: Added the reference to RFC 3864.</li>
    </ul>
    You may also obtain this information from:<br>
    <br>
    <a class="moz-txt-link-freetext"
href="https://tools.ietf.org/rfcdiff?url1=draft-yevstifeyev-http-headers-not-recognized-10&amp;difftype=--html&amp;submit=Go%21&amp;url2=draft-yevstifeyev-http-headers-not-recognized-08">https://tools.ietf.org/rfcdiff?url1=draft-yevstifeyev-http-headers-not-recognized-11&amp;difftype=--html&amp;submit=Go!&amp;url2=draft-yevstifeyev-http-headers-not-recognized-08</a><br>
    <br>
    During the last call the following note from IANA was received:<br>
    <br>
    <blockquote type="cite">
      <pre wrap="">IESG:

IANA has reviewed draft-yevstifeyev-http-headers-not-recognized-08.txt,
which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there is a single
IANA Action that needs to be completed.

In the Permanent Message Header Field Names registry located at:

<a class="moz-txt-link-freetext" href="http://www.iana.org/assignments/message-headers/perm-headers.html">http://www.iana.org/assignments/message-headers/perm-headers.html</a>

a single, new registration is to be added as follows:

Header field name: Headers-Not-Recognized
Applicable protocol: http
Status: experimental
Specification document: [RFC-to-be]

IANA understands that this is the only IANA Action that needs to be
completed upon approval of this document.

Thanks,

Amanda Baber
IANA
</pre>
    </blockquote>
    <br>
    No changes are intended to be made to the draft during the period up
    to 14 January in order to allow IESG to review the document.<br>
    <br>
    Looking forward to the opinion of IESG,<br>
    Mykyta Yevstifeyev<br>
    <br>
    P.S. Apologizing if you receive multiple copies of the message.
    Mykyta.<br>
  </body>
</html>

--------------020108020706000600080603--

From julian.reschke@gmx.de  Sat Jan  8 00:39:06 2011
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 7E12A3A699E for <ietf-message-headers@core3.amsl.com>; Sat,  8 Jan 2011 00:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.158
X-Spam-Level: 
X-Spam-Status: No, score=-104.158 tagged_above=-999 required=5 tests=[AWL=-2.159, 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 dZMu6Miyvop4 for <ietf-message-headers@core3.amsl.com>; Sat,  8 Jan 2011 00:39:06 -0800 (PST)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id DC1553A698E for <ietf-message-headers@ietf.org>; Sat,  8 Jan 2011 00:39:05 -0800 (PST)
Received: (qmail invoked by alias); 08 Jan 2011 08:34:31 -0000
Received: from p508FD294.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.210.148] by mail.gmx.net (mp049) with SMTP; 08 Jan 2011 09:34:31 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/JU8RhosvJkz8wecMebLmfNl1PNwEif5xkfrQRMT 3Udu9E0+AzGRFf
Message-ID: <4D28218A.2020406@gmx.de>
Date: Sat, 08 Jan 2011 09:34:18 +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>
In-Reply-To: <4D280272.6090402@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 08:39:06 -0000

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

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?

> ...
>     * Syntax: Changed. Now is not /token**/but /1*VCAHR /for definition
>       of the name of the header.
> ...

Why?

Best regards, Julian

From evnikita2@gmail.com  Sat Jan  8 02:17:24 2011
Return-Path: <evnikita2@gmail.com>
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 5FB013A69BE; Sat,  8 Jan 2011 02:17:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.921
X-Spam-Level: 
X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1]
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 PqqunfUeRTVs; Sat,  8 Jan 2011 02:17:23 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id ADFBF3A6964; Sat,  8 Jan 2011 02:17:22 -0800 (PST)
Received: by bwz12 with SMTP id 12so17859142bwz.31 for <multiple recipients>; Sat, 08 Jan 2011 02:19:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=NSy4Q4ss+NNXUW8WSDrqnjgs3IfA4rGWOPSKVhtyTWg=; b=ntTafH6oixFJe5XABb6uNffF874DxxxwGmTjugfGv9LMzAFVZBbUV5Xnj+3j6O2PE/ PhSKV5jSntMDrIp/IMhgXeh3flDhPdbW612XtTag5LIk+DnaS39DXtzk9yRBMK5aJb/N vaC7EGS6x0SUx/EOLx8ey4vFLS6viM5DbznZ0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ba8eBGlj83qOYoMz3peCPPL41u8LXyzPtFIradfkEfkh9Qu/J64UwlZ52cHqgTudJy 5aADjv8/9ltuFUKO2RxhQ9QeajXZB6vWQvcELxz8sl7ymSR5Yn4PKCntFvm/ftQUMEt/ EWinbKMtKmyHLX8uxSmNnxC/2vqxmDMWF6vEk=
Received: by 10.204.52.134 with SMTP id i6mr19900903bkg.36.1294481969175; Sat, 08 Jan 2011 02:19:29 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id j11sm14640528bka.12.2011.01.08.02.19.27 (version=SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 02:19:28 -0800 (PST)
Message-ID: <4D283A42.3080303@gmail.com>
Date: Sat, 08 Jan 2011 12:19:46 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
References: <4D280272.6090402@gmail.com> <4D28218A.2020406@gmx.de>
In-Reply-To: <4D28218A.2020406@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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 10:17:24 -0000

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
>


From julian.reschke@gmx.de  Sat Jan  8 03:22:43 2011
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



From evnikita2@gmail.com  Sat Jan  8 07:55:56 2011
Return-Path: <evnikita2@gmail.com>
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 8059228C104; Sat,  8 Jan 2011 07:55:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.966
X-Spam-Level: 
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOyLv07la4OR; Sat,  8 Jan 2011 07:55:55 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (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; d=gmail.com; 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; d=gmail.com; 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 10.204.73.9 with SMTP id o9mr9257287bkj.191.1294502280380; Sat, 08 Jan 2011 07:58:00 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id v25sm14773122bkt.18.2011.01.08.07.57.58 (version=SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 07:57:59 -0800 (PST)
Message-ID: <4D288998.9020001@gmail.com>
Date: Sat, 08 Jan 2011 17:58:16 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
References: <4D280272.6090402@gmail.com> <4D28218A.2020406@gmx.de> <4D283A42.3080303@gmail.com> <4D2847E1.9090004@gmx.de>
In-Reply-To: <4D2847E1.9090004@gmx.de>
Content-Type: multipart/alternative; boundary="------------070004030808040705020602"
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 15:55:56 -0000

This is a multi-part message in MIME format.
--------------070004030808040705020602
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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


--------------070004030808040705020602
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Hello all,<br>
    <br>
    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.<br>
    <br>
    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?<br>
    <br>
    As for the initial draft, I think I'm about to withdraw <i>it </i>(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.<br>
    <br>
    All the best,<br>
    Mykyta Yevstifeyev<br>
     <br>
    08.01.2011 13:17, Julian Reschke wrote:
    <blockquote cite="mid:4D2847E1.9090004@gmx.de" type="cite">On
      08.01.2011 11:19, Mykyta Yevstifeyev wrote:
      <br>
      <blockquote type="cite">
        <blockquote type="cite">If a draft changes three times during
          LC, there may be a problem. I
          <br>
          encourage you to go back to the drawing board, and think
          hard(er about
          <br>
          the feedback you got, in particular
          <br>
<a class="moz-txt-link-rfc2396E" href="http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0645.html">&lt;http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0645.html&gt;</a>.
          <br>
        </blockquote>
        Why do you think that the draft shouldn't be changed during LC?
        <br>
      </blockquote>
      <br>
      Because people assume stability during LC, and are unlikely to
      review the spec multiple times during the same LC.
      <br>
      <br>
      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.
      <br>
      <br>
      If you have non-editorial changes, the AD will have to decide
      whether they require a new LC.
      <br>
      <br>
      <blockquote type="cite">Moreover, I had some reasons for doing
        that. firstly, version -09 added
        <br>
        the section that was not present in -08 and if I added it now,
        there
        <br>
        would not be a possibility to discuss it. Version -10 presented
        the most
        <br>
      </blockquote>
      <br>
      There was no stability *because* of these updates.
      <br>
      <br>
      <blockquote type="cite">stable one to reflect all the comments I
        received during the LC. And -11
        <br>
        was prepared as final for IESG review.
        <br>
      </blockquote>
      <br>
      My recommendation to the IESG is to wait for a stable spec, and
      then restart the LC.
      <br>
      <br>
      <blockquote type="cite">I have fully answered all the question
        form the message you refer to.
        <br>
        <blockquote type="cite">
          <br>
          I also mentioned at least once that in many frameworks this is
          <br>
          essentially un-implementable, as different types of header
          fields are
          <br>
          processed by different, independent layers in the code, and
          thus
          <br>
          there's no way some part of the code will ever *know* which
          headers
          <br>
          have been "processed". Do you think that this is not a
          problem?
          <br>
        </blockquote>
        That is the issues that would be decided by the implementators.
        <br>
        Moreover, one code layer may support this technology while
        others may not.
        <br>
      </blockquote>
      <br>
      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.
      <br>
      <br>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">...
            <br>
            * Syntax: Changed. Now is not /token**/but /1*VCAHR /for
            definition
            <br>
            of the name of the header.
            <br>
            ...
            <br>
          </blockquote>
          <br>
          Why?
          <br>
        </blockquote>
        RFC2616 gives the following definition of token:
        <br>
        <br>
        token = 1*&lt;any CHAR except CTLs or separators&gt;
        <br>
        separators = "(" | ")" | "&lt;" |"&gt;" | "@"
        <br>
        | "," | ";" | ":" | "\" |&lt;"&gt;
        <br>
        | "/" | "[" | "]" | "?" | "="
        <br>
        | "{" | "}" | SP | HT
        <br>
        <br>
        <br>
        <br>
        And non-visible chars are not allowed in headers. So only
        VCHARs.
        <br>
      </blockquote>
      <br>
      That didn't answer my question. Why did you change something that
      was ok? It also shows why you'll need a new LC.
      <br>
      <br>
      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.
      <br>
      <br>
      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).
      <br>
      <br>
      Speaking of which: you can't have a "_" character in a rule name.
      <br>
      <br>
      Best regards, Julian
      <br>
      <br>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------070004030808040705020602--

From julian.reschke@gmx.de  Sat Jan  8 09:22:36 2011
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 B65AD28C13B for <ietf-message-headers@core3.amsl.com>; Sat,  8 Jan 2011 09:22:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.433
X-Spam-Level: 
X-Spam-Status: No, score=-104.433 tagged_above=-999 required=5 tests=[AWL=-1.834, BAYES_00=-2.599, 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 IW-tEBZJsQCG for <ietf-message-headers@core3.amsl.com>; Sat,  8 Jan 2011 09:22:35 -0800 (PST)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id F16603A67AD for <ietf-message-headers@ietf.org>; Sat,  8 Jan 2011 09:22:31 -0800 (PST)
Received: (qmail invoked by alias); 08 Jan 2011 17:24:38 -0000
Received: from p508FA2EB.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.162.235] by mail.gmx.net (mp013) with SMTP; 08 Jan 2011 18:24:38 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18ijmc+LegiGv5KI+eQCUTEorMi+I3mKW5T9I2Ss6 Nsufxqq4niug4g
Message-ID: <4D289DC9.70208@gmx.de>
Date: Sat, 08 Jan 2011 18:24:25 +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> <4D2847E1.9090004@gmx.de> <4D288998.9020001@gmail.com>
In-Reply-To: <4D288998.9020001@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 17:22:36 -0000

On 08.01.2011 16:58, Mykyta Yevstifeyev wrote:
> ...
> 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
 > ...

I don't see how (a) using HTTP warnings would resolve the problems other 
people see, (b) how the use of warnings makes this proposal any better, 
nor (c) that warnings are actually applicable here (see 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p6-cache-12.html#rfc.section.3.6>).

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

We might create a registry when/if when there are actually requests for 
new Warning values.

> ...

Best regards, Julian