[dcc2] Comments

[codemstr at ptdprolog.net]

myndzi <myndzi at gmail.com> said:

> codemastr: It's always an issue - the more lines, the higher your
> flood level. DCCs aren't the only thing going on on your connection,
> and remember that mIRC accompanies its DCC CTCPs with a notice as
> well. Just because none of them are likely to put you over the burst
> threshold doesn't mean that effort should not be made to reduce the
> "footprint" so to speak. Otherwise you're just taking a "good enough"
> attitude, which isn't really desirable.

I agree. I'm just saying, redesigning everything for a scenario that will 
likely never occur also doesn't seem desirable. Yeah mIRC sends a notice. So, 
if a client decides to send 50 notices when you initiate a DCC, we should 
take that into account to? As I said with regard to CTCP, you might get a 
VERSION reply that consists of 10 NOTICEs. It seems each script you load just 
tacks on another VERSION reply. That's not a specification detail, that's an 
implementation detail. I do agree that the size of the message and so forth 
should be addressed, I've already brought that up. If it were up to me, a 
request would be as small and as bandwidth friendly as possible. But, it 
seems as though people also want the protocol to be human readable and so 
they are not willing to sacrifice readability for simplicity.

> Also, now that it appears my messages go through, a brief comment on
> the discussion about DCC Chat -- all that crap is beyond the scope
> here. The 'application tokens' are meant to be passed on to whatever
> does something once the connection is established. I am of the opinion
> that DCC Chat should be left as-is, and if someone wants to create a
> Partyline protocol, go for it. But it should be separate. And on that
> note, maybe it'd be a good idea to "extract" the specifics pertaining
> to send and chat from the DCC2 protocol and arrange it so that they
> are separate documents?

I believe that is the goal. You'll notice that the DCC Send replacement is 
already a seperate draft. As far as I know, chat is supposed to be a seperate 
draft as well. So if someone wanted to make a partyline draft for their own 
protocol, they sure can. The DCC Chat stuff, to my understanding, is not 
going to be part of the negotiation draft. It will be seperate, so I'm not 
quite sure what you are inferring. If you mean the negotiation draft 
shouldn't mention things like "file=," perhaps, but that has very little 
relevance to DCC chat.

But otherwise, I'd like to point out something. "DCC Chat should be left as-
is." Why? Above you yelled at me for having a "good enough" mentality, that's 
what you're using here. The purpose of DCC2 is to standardize DCC. You can't 
leave something "as-is" when it "is not." When one mentions DCC Chat, there 
are numerous different implementations. Some implement DCC Chat as encrypted, 
some do not. Some support IPv6, some do not. Same goes for CTCP in general. 
Some implement the IRCii escapes, some do not. So you can't leave it "as-is" 
because there is no single protocol that can hold the name "DCC Chat." 
Someone needs to document it, and that is what the DCC Chat draft serves to 
do. But as I said, why leave it "as-is," (referring to existing de facto 
standards) why settle for "good enough"? I'm sure many people would like the 
ability to initiate a CTCP VERSION over DCC Chat, just because current 
clients don't implement this means we should leave it out? I disagree. That 
most certainly is saying make it good enough and simply stop there.

> Re: CTCPs to "do things" in "enhanced" chats; you're better off
> designing a protocol for that than tacking things onto the basic one
> that exists. Perhaps one similar to IRC... but then where is the line
> here? What's the purpose? DCC Chat is essentially a direct query;
> beefing it out into a full service IRCD is rather pointless.

Only one CTCP was suggested that "does something" and that was a CTCP NICK. 
So I really don't see how you can make the jump from changing one's nickname 
to implementing an IRCd over DCC. Yes it's a direct query, and, as such, 
shouldn't it offer the same features that a query has? In a query, if I 
change my nickname, the query window of the client reflects that. The DCC 
Chat window of the client does not. All I'm asking for is better emulation of 
the query experience. I agree though CTCP may not be the best method. When I 
came up with the idea I had forgotten the infinite loop issue. I personally 
think the idea of using "\1 at the end = request, no \1 = reply" is a hack 
and is a bad idea. I do agree it should be handled differently, I just 
haven't heard anyone suggest anything that is better, and I've yet to come up 
with a better solution myself. We can't simply use a "NICK" command because 
then it means we need to use a "PRIVMSG" command for all regular text. After 
all, text could start with NICK. And then I'd agree, we are moving towards 
IRC over DCC, and not to mention wasting bandwidth since we have to 
send "PRIVMSG " before everything. The problem is, if we don't use CTCP, then 
it requires the client to implement something completely new rather than 
simply using an existing practice and adopting it to a new medium.

-- codemastr