[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dcp] Features
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
dcp@ietf.org
https://www1.ietf.org/mailman/listinfo/dcp