Last Call on draft-yevstifeyev-http-headers-not-recognized - summarizing first week

Hello all,

This message summarizes the first Last Call week on 
draft-yevstifeyev-http-headers-not-recognized. The document have been 
discussed on IETF Discussion and HTTPBIS WG mailing lists.

I include the most current entity to be discussed:

> 1. Introduction
>
> 1.1. Motivation
>
>    HTTP is one of the most widely-used protocols in the Internet. One of
>    the things which made it so popular is extensibility. One can easily
>    add any header field to the HTTP message. However, all hosts are not
>    able to support all the header fields. Generally, if a it host does
>    not support the header field, it is simply ignored. The another side
>    of exchange is not notified about not processed header fields.
>
>    This document proposes mechanism which allows HTTP hosts to notify
>    another hosts about not recognized headers.
>
>    The proposal is to send a response with definite header field to the
>    host if one or more header fields of request are not supported. This
>    document defines Headers-Not-Recognized HTTP header field to be used
>    in such occasion.

> 2. Technical Overview
>
> 2.1 Model of Work
>
>    If the HTTP host receives HTTP message which contains some header
>    fields which are not supported by it, it is RECOMMENDED for it to
>    include the Headers-Not-Recognized header field in the response to
>    the host that sent not supported header fields. Information about not
>    supported header field is to be put in this header field following
>    the rules of Section 2.2 of this document. The Headers-Not-Recognized
>    header field MUST contain information only about not supported header
>    fields - i.e. header fields which are not able to be processed
>    anyway. It MUST NOT contain information about header fields, which
>    are partly supported, not intended to be used or whose entity cannot
>    be processed while the header field is supported at all etc.
>
>    When HTTP host receives HTTP message with Headers-Not-Recognized
>    header field, it is RECOMMENDED that it avoids sending packets with
>    header fields with mentioned in it names to source (for message with
>    this header) host or tries to change them so that hat host is able to
>    recognize and process them.
>
>    Intermediate systems (also called middle-boxes), such as proxies,
>    tunnels, gateways etc. MUST transfer the messages with Headers-Not-
>    Recognized header field to the destination host without changing the
>    entity of this header field if the not supported header field was
>    present in the initial HTTP request (i. e. request which intermediate
>    system received before transferring it to destination node), but MUST
>    omit it if Headers-Not-Recognized header field's entity concerns only
>    to headers added to initial request by middle-box. If the
>    aforementioned header concerns added header fields partly, middle-box
>    MUST change the entity so that it concerns only initial request
>    header field.
>
> 2.2 Syntax
>
>    'Headers-Not-Recognized' header field has the following format:
>
>    headers_not_recognized = 1#header_name
>    header_name            = 1*VCHAR
This is the fragment of the text which is planned to be posted as a 
draft nearly after 1 January (the half of Last Call period) if no 
*critical* comments will be received.

This text reflects almost all the comments I received during the Last 
Call and found appropriate. However any other suggestion are still welcome.

You may feel free to contact me at evnikita2@gmail.com for further 
information.

All the best,
Mykyta Yevstifeyev