Subject: [dcp] Features

From: Sara Karlberg <[email-masked]>
Date: Tue, 16 Apr 2002 08:12:03 +0200

Hi,
I have a little example;
-Imagine that you want to use CCID 2 hence you start to negotiate the
use of Ack Vector with the DCP-Response packet.
-Instead of using CCID 2 you settle on using CCID 3 after negotiating
with the other end.
-Then you will have to reopen the Ack Vector negotiation if you only
want the Ack Vector option to be used in combination with CCID 2 not
with CCID3.
Consider a large number of such dependencies where the use of one
feature depends on another feature being used. It could take several
rounds before you have achieved the desired settings making it difficult
to know how to properly handle data.

One way to remove some negotiations would be to make it unnecessary to
establish the value of features which are mandatory for a particular
CCID through negotiation, let them be determined by the CCID instead.
Such an example would be the Ack Vector for CCID2. When you have opted
for CCID2, the Ack Vector could be included automatically.

A related question is which end-point should have the most influence on
the decision taken (mainly CCID)? The sender knows more about the data
to be sent (probably only after the application request though).
However, the receiver might be asked to hold a lot of state, send data
and it sees the final result ... so it needs to have some saying. When
studying the drafts I get a feeling that
it is possible to manipulate the negotiation to get it where you want
depending on the implementation. Are you planning on enforcing a certain
behavior
so that one end-point has more influence?

I have another issue which I would only like confirmed; at connection
set-up is it enough to agree on the CCID to start sending data, the rest

of the negotiations can be concluded while sending data?

Please correct me if I am wrong about something.
Thank you,
Sara

_______________________________________________
dcp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dcp

---

From: Eddie Kohler <[email-masked]>
Date: Tue, 16 Apr 2002 09:44:01 -0700

> for CCID2, the Ack Vector could be included automatically.

You are right that several negotiations might be required, although they
could be largely overlapped, but I bet this won't happen very often. For
instance, the usual sequence for a server S choosing CCID 2 would look like
this:

      C->S: Ask CC 2
      S->C: Answer CC 2; Ask Use Ack Vector 1
      C->S: Answer Use Ack Vector 1

Note that Use Ack Vector isn't negotiated until the end. S asks the client
C to use the Ack Vector, so that request can piggyback on the Answer.

We negotiate the features independently from CCID to facilitate
extensibility. This way, a new CCID can be deployed without upgrading every
DCP implementation in the world; it'll request the features it needs.

Your solution would certainly help if long negotiations became a problem in
practice.

> Are you planning on enforcing a certain
> behavior

We weren't planning on it. CCID negotiation is a negotiation among equal
parties.

> of the negotiations can be concluded while sending data?

You're right. To clarify, though: The draft says you cannot send data when
you don't have a valid CCID. An implementation, or a particular CCID, might
further hold off until some additional features are negotiated. That would
depend on the implementation and the features. For example, CCID 2 might
refuse to send data (or more than an initial window of data) until the
receiver agrees to Use Ack Vector.

Eddie