Subject: Last Call Summary on draft-yevstifeyev-http-headers-not-recognized

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 08 Jan 2011 08:21:38 +0200

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.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 08 Jan 2011 09:34:18 +0100

> Last Call 3 new versions appeared. The latest one is -11, submitted on 8

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?

> ...
> ...

Why?

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 08 Jan 2011 12:19:46 +0200

> <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.
> 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.
>>       of the name of the header.
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.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 08 Jan 2011 12:17:53 +0100

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

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

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

> separators = "(" | ")" | "<" |">" | "@"

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: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 08 Jan 2011 17:58:16 +0200

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:
> last-called. For instance, by publishing the current edits on a 
> private web page.
>
> 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).
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 08 Jan 2011 18:24:25 +0100

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

> 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

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 09 Jan 2011 08:22:53 +0200

08.01.2011 19:24, Julian Reschke wrote:
> 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 
At the moment no any, and I want to define a new one.  In spite of this 
there is no any registry (see below).  I ask the WG for opinion on 
should we create it or not?
> We might create a registry when/if when there are actually requests 
> for new Warning values.
However no one can actually do this since there is no such registry.  So 
I think there should be the appropriate registry.  Will the WG agree 
with me?

---

From: Julian Reschke <[email-masked]>
Date: Sun, 09 Jan 2011 11:20:13 +0100

> At the moment no any, and I want to define a new one. In spite of this

I meant the warning header field in general, not specific values.

> there is no any registry (see below). I ask the WG for opinion on should
> we create it or not?

I can only speak for me, and I already said that I don't think that the 
use of Warning would enhance your proposal.

> I think there should be the appropriate registry. Will the WG agree with
> me?

See above: no, *I* don't think we should create a registry at this point.

Best regards, Julian

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 9 Jan 2011 11:03:31 +0000

> See above: no, *I* don't think we should create a registry at this point.

Agreed, we don't need to create a registry until we have something to put in it.

If someone writes an I-D that creates additional Warning codes, that same I-D can:
1) Note that a registry needs to be created, or
2) Suggest creating the registry and contain the relevant IANA guidelines etc.

In the case of (1) what I would expect is *if* the I-D progresses then at some point in the future before it is sent to IESG, either
a) a separate I-D is produced & progressed in parallel to create the registry and IANA guidelines
b) the IANA guidelines etc are put in the original I-D (essentially the same as (2) above but the original I-D author does not expend time writing IANA guidelines before receiving feedback on their actual proposal).

Ben

---

From: Julian Reschke <[email-masked]>
Date: Sun, 09 Jan 2011 13:03:17 +0100

On 09.01.2011 12:03, Ben Niven-Jenkins wrote:
> a) a separate I-D is produced&  progressed in parallel to create the registry and IANA guidelines

As a matter of fact, HTTPbis currently defines (at least) three new 
registries (method names, cache control codes, auth schemes). The 
absence of these registries hasn't caused these extension codes to be 
used before.

Summarizing: I'm reluctant to add new registries unless we *know* we 
need them. In the past 11 years, apparently nobody has asked for a new 
Warning code before. That might tell us something.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 10 Jan 2011 09:42:49 +0200

Hello all,

First of all, how could anubody applied for warning code if there was
no popssibility to do that? RFC2616 mentiined no ways to do that. I
propose to create such regsitry since I have some ideas as for new
Warning codes.

I do not share the opinion of those who say we have nothing to place
there. RFC2616 mentioned nearly 5 Warning codes that should be put in
such regsitry.

I am strongly cpncerned we should create such registry.  And please
find anoter comment below.

2011/1/9, Julian Reschke <[email-masked]>:
>> In the case of (1) what I would expect is *if* the I-D progresses then at
>> some point in the future before it is sent to IESG, either
I afree with this case. Moreover, how will we name the draft that
creates the registry and defined a number of values.

Mykyta Yevstifeyev

>> b) the IANA guidelines etc are put in the original I-D (essentially the
>> same as (2) above but the original I-D author does not expend time writing
>> IANA guidelines before receiving feedback on their actual proposal).
>>
>> Ben
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Jan 2011 11:25:16 +0100

> no popssibility to do that? RFC2616 mentiined no ways to do that. I

You write an Internet Draft, and as part of the draft you note that 
there's currently no registry, and that somebody needs to deal with that 
(maybe yourself by defining it, by using the RFC "updates" relation, or 
by asking the IESG or the Working Group for feedback).

But the first step should be to actually show that a new Warning code is 
needed. Could you please do that first?

> there. RFC2616 mentioned nearly 5 Warning codes that should be put in

RFC2616 defines Warning Codes. But that doesn't necessarily mean a 
registry is needed.

Best regards, Julian