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
|