[Resending because I appear to have sent only a partial message]
At 12:22 AM 08/06/01 -0700, Roy T. Fielding wrote:
Please note, however, that I published the first draft of HTTP/1.1 in
August of 1995. 1.0 was expected to be a Proposed Standard up until that
point. RFC 1945 consisted of the interoperable subset of over 100
independent implementations claiming to use HTTP/1.0.
I do remember. We have been publishing iCAP as an ID for at least the
existence of the WREC WG. The implementation problem is something we also
share though in iCAP's case, it is due (mostly) to 1) the changes we made
to the protocol as we developed (e.g. chunking) and 2) mistakes in the
document. That is exactly why we are proposing to publish it as
"Informational" now. Our proposal is not to declare iCAP the definite
content vectoring protocol. It is simply to fix the (known) bugs in the
document and publish it.
Having experienced this detour personally, I don't recommend it unless
you have an objective definition of what must be in iCAP 1.0.
I think you miss my point (?)
I am saying that iCAP 1.0 has been around for long wnough, the bugs are
well-enough known and understood that now is the time to draw a line under
it. At the same time, it is clear that iCAP 1.0 is not and will never be
suitable in its current form for streaming protocols, for example. [icap
was only ever intended to be a simple http vectoring protocol. In fact, its
original name was SHVP...]
The problem with iCAP as it stands right now is that the specification does
not match anyone's implementation, let alone multiple independent ones.It
will take some work to determine which of the various implementations got
it right, and yet more work before the written description matches what has
been implemented.
The specification is indeed broken - that's why we're trying to fix it. We
are incorporating comments and changes from those who've implemented it.
I didn't see that getting done any more effectively in
the iCAP forum than it did in the IETF pre-group discussions.
There is never any real work done at very large meetings. This is precisely
why the IETF mandates that "real work" is done by email. iCAP was developed
by a small group of people, working mostly by email but also having regular
conf calls over the period of about a year (for the most intensive part).
The public presentations - I attended most of them - were exactly that,
"presentations".
Over the last 6 months or so, we have managed to reach convergence -
amongst both the implementors and the wider IETF community - on what is
needed fixing in v1.0. We are now simply documenting that.
As such, I don't think iCAP is ready for publication as any sort of RFC.
The problem isn't the standards process being slow. The specification
simply doesn't exist in a form that can be standardized, and won't until
the editors make their implementations public and focus effort on matching
the descriptions to actual (not imagined) examples. That is how the IETF
specification process is supposed to work.
With respect, I think you are mixing two different things. I am not
proposing that iCAP become proposed standard. I am proposing that iCAP is
documented as informational. The two are very different.
The standards process being slow is not something I consider an issue.
Being able to work on iCAP v2.0 is.
John
---------------------------------------------------------------
Network Appliance Direct / Voicemail: +31 23 567 9615
Scorpius 2 Fax: +31 23 567 9699
NL-2132 LR Hoofddorp Main Office: +31 23 567 9600
---------------------------------------------------------------