ietf-openproxy
[Top] [All Lists]

Re: iCAP, OPES and the IETF

2001-06-05 10:50:45
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).


<Prev in Thread] Current Thread [Next in Thread>