Re: Last Call: <draft-yevstifeyev-http-headers-not-recognized-08.txt> ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC

SM <sm@resistor.net> Sat, 18 December 2010 21:57 UTC

Return-Path: <sm@resistor.net>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C164B3A6BF8 for <ietf@core3.amsl.com>; Sat, 18 Dec 2010 13:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.523
X-Spam-Level:
X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 H+RhUMnGov1R for <ietf@core3.amsl.com>; Sat, 18 Dec 2010 13:57:38 -0800 (PST)
Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 58F903A6BF6 for <ietf@ietf.org>; Sat, 18 Dec 2010 13:57:38 -0800 (PST)
Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id oBILwRvs027428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Dec 2010 13:59:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1292709563; x=1292795963; bh=anJPiIloaqs42vFQ7Fic1FOds8XfF8+84IjLkT1WIu4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=B8fYQwtxmbCyXjl8dyOrIUu55+k2Cd+9LDydvOf/D7H4Q9jApYJoeyMEBVP7u99tI ta4sniVfvVkT9RdqBC9cFJH+DetEV/GQIvpypUldZBR225EHVS89HA/n0UptCiz9Eg E3aAGveiy20MmrJr/dZJHFxXNFbPkdXXNE+aCh4Q=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1292709563; x=1292795963; bh=anJPiIloaqs42vFQ7Fic1FOds8XfF8+84IjLkT1WIu4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=NLqt2gZVffR+O3GXIA+cK5DsR+c2XFZ1hnq47F0sjgntV+fbf2y2WZme3l5qPu4Qw f/6nx+4fCiCETVQulwH0TTnb5S5S8V1n4CeR2KCSuNWp299ho8X8mYqw68ccVPbsFt dZ8MSsheBIgWaEkNuGGkGSX5teLzERkWUw6fiNJ4=
DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=KAkKPYGcUGYJl9pgi105JDhG6xD45GUDg1nt8fgD61hbTwOGYV+MCqkQ632PMO4+h YFaMRj6SuFWTugifNYjvanjFwhX0CXNuVAtVCPl7bjBbjBEf8tP5GLgwZw8AWvL8R3x dVa6m+BSdB924kFLUUhF/ntN0KDhZi8xP5XGbKc=
Message-Id: <6.2.5.6.2.20101218074702.09f0fa80@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 18 Dec 2010 13:51:44 -0800
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
From: SM <sm@resistor.net>
Subject: Re: Last Call: <draft-yevstifeyev-http-headers-not-recognized-08.txt> ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC
In-Reply-To: <4D0B6B6D.7040001@gmail.com>
References: <20101213132808.2379.30041.idtracker@localhost> <6.2.5.6.2.20101217021213.0c3125b0@resistor.net> <4D0B6B6D.7040001@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Dec 2010 21:57:39 -0000

Hi Mykyta,
At 05:53 17-12-10, Mykyta Yevstifeyev wrote:
>I find 'processed' more acceptable for this case. However to mind it 
>would be better to mention 'not supported'

You could use "not supported" if you find that better.

>What do you mean? Packets have nothing to do with headers, there is 
>nothing about this in paragraph above. Maybe you meant middle-boxes?

Daniel Stenberg already commented on this [1].  The term 
"middle-boxes", as used in the document, lumps everything in the 
middle together even if the "hosts" operate at different layers.  As 
the proposal uses a "MUST" in the third paragraph of Section 2.1, the 
compliance is dependent upon "hosts" which are generally not part of 
HTTP infrastructure.

>I'll let you know as soon new version of the draft will be available 
>(maybe that will be at the end of Last Call).

You can ask the sponsoring Area Director if you need guidance.  It is 
assumed that you will have done some research first before asking for 
help.  That includes learning how the IETF process works.

If people argue for a change, that doesn't mean that the author of a 
draft must make the change.  The author should keep in mind that the 
strong discontent in such a case can hamper the publication of the draft.

It is also good to take into account whether you want the draft 
published as a RFC or whether you would like widespread 
implementation of the proposal.  The latter requires that you 
convince implementors about the merits of the proposal.  Obviously, 
they would not be convinced if their comments are ignored.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg64887.html