At 13:06 6/5/2001 -0400, Markus Hofmann wrote:
Martin,
> I do indeed want to see iCAP further developed and yes,I agree that an IETF
> working group is the appropriate place for this to happen.
Glad to see that we agree on this important issue. So let's all pull
together to help making OPES, which has iCAP on its charter, official.
Hang on a second. There's a difference in what the two of you are suggesting.
John is suggesting that the *current* implementation is documented right
now, with no further feature-creep or delay.
John is *also* suggesting that this step will give everyone something
tangible to code to, to experiment with, and to think about so that a
future protocol (I'm not going to fall into the trap of calling it iCAP)
can be developed if necessary.
I could be wrong but you appear to be suggesting that the group somehow
"does something with" iCAP other than publishing it right now.
The proposed charter includes a last call on iCAP, sure, but if
current-iCAP is already published (or sitting in the rfc-editor queue) I
don't see that as a problem. Further, the charter also clearly states:
"The working group will evaluate the iCAP protocol as one candidate for
HTTP-encapsulated application data. It may decide to extend the iCAP
protocol without being obliged to retain any level of compatibility
with the current iCAP proposal."
That reads "we'll look at it, but we might do something else". Why can't
you look at something that's an RFC?
iCAP exists. It needs to be documented. An IETF Informational RFC is a
good place to do that.
If OPES comes up with something else iCAP still needs to have been documented.
If OPES decides to come up with features that fix things identified after
experience with iCAP then iCAP definitely needs to have been documented.
There's a tremendous interest in the OPES work (just look at the
attendee list of this week's workshop),
% chmod o+r
and your comments also
underline the importance to get OPES official. This would ensure that
iCAP properly integrates into the overall protocol framework.
No.
There's some interesting confusion about what OPES is saying about iCAP
because it's using the same name for something-that-is and
something-that-might-be.
Having OPES as an IETF working group should have no bearing on the
documentation of what-iCAP-is-now. If/Once formed OPES *should* consider
iCAP and either work on iCAPv2 or "something else". In fact, that's what
the proposed charter says.
> I don't disagree with you but I suspect that the IESG will want to make
> that decision.
Sure, absolutely, I never meant to say something different. And we can
help by quickly reacting to comments/suggestions/questions from the
IESG, by continuing the great work that has already been done in the
group and by staying focused without gettig disrupted.
The fact that iCAPv1 is on the current charter (as something to be
*evaluated*) should be immaterial to the decision on whether to form the
group. OPES is more than iCAPv1 (I thought).
If OPES can't form without iCAPv1 as a work item for itself (that with the
proposed timeline would go through little more than a group-rubber-stamp)
then there's something very wrong with what the working group is proposing
to do within the IETF.
> I do not want to tie iCAP to a group that doesn't exist; on
> the other hand, I am pretty happy if iCAP can be further developed within a
> group that does exist.
I agree. So make this position loud and clear, let people know that
you'd like to see an official WG like OPES working on these issues,
including iCAP.
The charter already says that.
That's exactly what we all want - and WE means quite a
lot of folks (just look at the enormous interest in OPES).
I'm probably going to get flamed for writing this email, so I may as well
say this too:
Just because there are a lot of folks interested in this area does not mean
that the work has to be done within the IETF.
> I don't believe this will happen. The version submitted to ECMA will be the
> version that is published by the RFC editor. In my opinion, the former
> takes precedence. If ECMA produces an incompatible spec - which I'm sure it
> wont - then that is no longer "iCAP 1.0" but something else. We (NetApp)
> will work very hard to ensure that doesn't happen.
So, why to submit to two different standards bodies at all? I might
miss the point, but if the goal is to have two identical standards,
why to submit to two different organizations?
I'm sure there are organizations and businesses that don't recognize the
IETF as an official standards body. After all, it's really just a bunch of
geeks working on stuff together (he says facetiously).