[dcc2] comments on latest draft

[Dave Johnson]

Hi all,

I just read through both the negotiation (April 23) and file (Feb 10)
drafts.  Looks good so far, but I did have some comments and found one
potential problem.


Default token values
--------------------

Should the draft specify default token values?  The samples don't
include a Transport token in publication messages for example.  Is the
client supposed to assume TCP?  This should be specified.


Unknown tokens
--------------

What should a client do if a DCC2 message includes an unknown token?
I'd guess either ignore it or include it in an ErrorTokens message
back to the sender.  I didn't see this mentioned anywhere.


Partial transfers
-----------------

The offset token can be used to specify a starting transfer point for
a file transfer, but it may also be useful to include an optional
ending point byte count token (instead of end of file).  This could be
used to build a distributed client that retrieves portions of a file
from multiple sources.

The client could always just close the connection after receiving the
needed portion, but this would be undesirable and couldn't be done in
multi-file transfer mode without loosing the connection entirely.


Tokens available only in multi-mode
-----------------------------------

Can we add additional optional tokens to the ircfile transfer tokens
(sec 4.3) to better match the tokens available in the multi-file XML
file?  Specifically it would be nice to use desc or crc32 directly in
the publication message in a single-file mode instead of having
these only available to multi-file mode.


Strict checking of tokens in accept messages
--------------------------------------------

Should the offering client strictly check values that the receiving
client bounces back to it (such as filename and size) in the accept
message?

Consider the following exchange (based on the example #3 in 5.2.3.2):

 offering client sent:
 DCC2 Application=IRCFile Network=IPv4 NAT Filename="somefile.txt" Size=3423 SID=1

 receiving client will accept the transfer and open a listening connection:
 DCC2 Accept IPv4=192.168.23.342 PORT=8732 Filename="somefile.txt" Size=4423 SID=1

In this case the receiving client sent back a different (larger) size
than the publication message had.

Should the offering client error on this case or ignore it?  I'd
rather see the client not bounce back tokens that are unchangeable
(such as filename, size, and multi).

It would be useful if the draft specified a list of required,
optional, and forbidden tokens for each message type.


Using values as tokens in accept messages
-----------------------------------------

When the receiving client responds to the offering client with it's
chosen values, it does so by listing the value without a token in the
response.  Such as (from 5.2.3.1 #1):

 offering client sent:
 DCC2 Application=IRCChat Network=IPv4,IPv6 TransportSecurity+=SSL3,TLS1 SID=1

 receiving client would like to use IPv6 and TLS1 encryption sends:
 DCC2 Accept IPv6 TLS1 SID=1

In the accept message IPv6 and TLS1 are used bare without the
"Network=" and "TransportSecurity=" prefix.  From an implementation
standpoint this makes things more difficult as now every possible
value is a valid token. This would also prevent values with the same
name from being used in different tokens (not the case now, but it
could be in the future).

I'd rather see a response such as:

 receiving client would like to use IPv6 and TLS1 encryption sends:
 DCC2 Accept Network=IPv6 TransportSecurity=TLS1 SID=1


Timeouts
--------

Has thought to specifying or recommending timeouts for DCC2 operations
occurred?

It may be useful to specify an additional command:

DCC2 Timeout TimeoutMessage="No Accept message received" SID=1

This would allow better cleanup on both sides as an implementation
could clear publications, pending connections, etc...


Disconnect/Cancel
-----------------

Similar to timeout, should there be an explicit disconnect message if
either side wants to disconnect.  This would be cleaner than simply
closing a TCP connection and letting the other side wonder why.


SID collisions and use of 'Accept'
----------------------------------

As a SID is only unique within a client instance, this makes
processing of messages difficult as the client will first need to
determine if the received DCC2 message uses a SID that it originated
or it's peer originated.

Consider the following race condition:

Two users, A and B.  A cannot accept inbound connections, but B can.

 - User A initiates a DCC2 file transfer to user B: (call this transfer X)

   DCC2 Application=IRCFile Network=IPv4 Filename="file.txt" Size=3423 NAT SID=1

 - User B initiates a DCC2 file transfer to user A before receiving
   publication for transfer X: (call this transfer Y, also using SID=1)

   DCC2 Application=IRCFile Network=IPv4 Filename="file.txt" Size=3423 SID=1

 - User A receives request for transfer Y, and responds with an accept
   message (but doesn't open a listening socket because user B can do
   that):

   DCC2 Accept IPv4 Filename="file.txt" Size=3423 SID=1

 - User B receives request for transfer X, opens a listening socket
   (because user A is behind NAT) and responds with an accept message:

   DCC2 Accept IPv4=192.168.0.100 PORT=2001 Filename="file.txt" Size=3423 SID=1

 - User B receives the accept for transfer Y, opens a listening socket
   (because user A is behind NAT) and responds with another accept
   message:

   DCC2 Accept IPv4=192.168.0.100 PORT=2002 Filename="file.txt" Size=3423 SID=1

Now comes the problem:

 - User A receives 2 accept responses from User B:

   DCC2 Accept IPv4=192.168.0.100 PORT=2001 Filename="file.txt" Size=3423 SID=1
   DCC2 Accept IPv4=192.168.0.100 PORT=2002 Filename="file.txt" Size=3423 SID=1

There is no way for user A to differentiate which accept message is
for transfer X and which is for transfer Y because it does not know
which namespace each SID belongs to (namespace for user A or user B)

Using 'Accept' for both offerer->receiver and receiver->offerer will
mix SID namespace.  I'd suggest we change the SID token to specify a
'your' or 'mine' such as:

MYSID=1
YOURSID=1

This will make an implementation easier because each client can
directly determine the namespace of a SID instead of having to derive
it from other information.


-- 
Dave