On Tue, Jun 12, 2001 at 10:16:18AM +0200, John Martin wrote:
* For the record, here are the facts I can determine from my mail archives.
That sounds about right, but you are forgetting that the "iCAP forum"
mailing list was not populated with everyone who was nominally in the
iCAP forum, let alone the general public. Thus, a great deal of stuff that
was mailed to the iCAP participants was only delivered to the iCAP authors.
But that isn't really relevant now.
For the rest, yes, iCAP was originally designed to be HTTP encapsulated
over HTTP but implementation showed this to be impractical and unperformant
- particularly for large objects where only partial objects needed
vectoring (e.g. in virus scanning). So, after a lot of discussion, the
decision was made to remove the requirement for HTTP compatibility but
retain the header-body syntax a la HTTP (and MIME).
Yes, you are unlikely to see an implementation of the current spec because,
as I've said before, it is a superset of all the changes made by all those
who've implemented iCAP v0.9 and fixed bugs and inconsistencies along the
way. So, it is indeed a documentation of "iCAP-as-implemented" in that it
is a record of what people have coded.
That aside, we are planning to release reference code for both the client
and the server for iCAP v1.0.
But that doesn't answer my question. Are you planning on submitting
draft-elson-opes-icap-01.txt to the RFC editor as a representation of
the iCAP protocol? If you are, then please identify what versions of
what software have been implemented according to that specification, because
the last time I checked it was impossible for that specification to be
implemented as written.
What I am saying is: fix the specification first. I don't want you to
include all the wild ideas, just the fixes that make it possible for
independent interoperable implementations to exist based on the specification
and not based on reverse-engineering the behavior of your software.
....Roy