[dcc2] Comments

[myndzi]

> 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.

We're on different parts of the same page here, I think. I fully agree
with making the protocol legible. Part of my post was just pointing
out that it's simpler and makes more sense to use two total messages,
for these reasons:

1) Fewer opportunities to drop the message / fewer timeout instances required
2) Fewer long messages adds less "lag" than more short messages
3) CTCP is really only a request/reply setup; it doesn't provide well
for more-than-two message negotiations
4) You don't have to worry about giving away IP information, since the
goal is to establish a connection which gives away that information
anyway; if you don't want the other end to know, don't initiate the
connection in the first place
 
> 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.

The DCC2 draft specifically defines the DCC2 Send and Chat methods. I
was referring to those not needing to be there. See section 4.3. I
think the other instances are all examples.

> 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.

I'm not doing any yelling ;) What I meant about "as-is" is that plain
DCC Chat should simply be a client to client connection allowing for
the exchange of text. Tacking on multiple users, nick changes, and all
the rest is rather overkill. The DCC2 protocol itself will provide for
negotiation for encrypted, compressed, IPv6, escape negotiation, etc.
as that is all connection-related, not Chat related. The suggestion
was that the people who want all that extra junk in DCC Chat instead
work on a separate draft for a separate application-type such as
'partyline'. I'll leave discussion of the dubious value for a
partyline that is essentially an IRC server for another time...
 
> 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.

Well, the easiest way to provide that extra functionality is to design
a protocol that doesn't start by assuming every line of text received
is a line of text. Then you start having things that naturally follow,
such as using PRIVMSG to send text, NICK to send a nick change, and
numerics to report errors etc. you're already well on your way. But
the IRCD comment was not directed solely at the CTCPs to provide
commands bit, it was also aimed towards the 'multi-user chat' people
and some of the other suggestions I've read or skimmed. I don't have
anything constructive to say about their conversations since I don't
agree with them, I'm just suggesting that they be separate projects
because not only does it make more sense that way, but then I don't
have to worry that they will be as integral to DCC2 as Send and
"plain" Chat ;)

-myndzi