[dcc2] Final connection negotiation changes (WAS: Is DCC2 Dead?)

[myndzi]

Heh, your tone irritated me for some reason. "Superior in every way"
is not exactly a phrase I take to well, since I don't enjoy dealing
with the sort of elitist assholes that often show up around the IRC
community.

I don't disagree with your points, but understand that not everything
I say is proposed as some sort of end all solution to everything, I am
just trying to get some actual discussion going. Guess it worked ;)

That aside, 'tokens' didn't have to mean the Parameter=Value tokens
used in DCC2, though that is rather what I implied at first. CTCP in
itself is such that the first token (using spaces as a delimiter)
tells the type of request; it simply seems counterintuitive to me to
put the version also in that position. It seems to me the only reason
this draft uses 'dcc2' is because there is no way to hijack 'dcc' for
our own purposes. Indeed, IRC uses a token based approach, separated
by spaces.

>No, the client just needs to be taught to recognize DCCN rather than just
>DCC2. Pseudocode:
>if (substr(ctcp,3) == "DCC" && charAt(3) != '2') send_error("Unsupported DCC
>version");
>That right there would handle the error checking. If it is DCC3, DCC4, etc.
>we don't understand it. If it is DCC2, we do understand it. Would doing
>"DCC2 1.0" be bad? Not really, but I just think that's a bit confusing...
>it's version 1.0 of DCC version 2? That seems confusing to me. Isn't just
>saying "DCC2" clear enough that we mean DCC version 2 and "DCC3" clear
>enough that we mean DCC version 3?

That just seems like so much semantics when the difference is a space,
so really we are talking about something very similar: "DCC3 <stuff>"
or "DCC 3 <stuff>" [or 2.1, or whatever]. And in that context, I like
the second one better because it fits with the feel of both IRC and
CTCP.

-myndzi

>Btw, I don't think"nobody concluding anything" is a good thing. Isn't the
>purpose of this group to reach a conclusion? If we aren't going to reach
>conclusions, how do we ever expect to come to an agreement for an RFC?

I don't think it is either, which is why I was irritated. I know I
sorta dropped in out of the blue and I had a lot of thoughts that
weren't directly in line with what has already been done [i.e. not
minor changes but some of them major ones], but as far as I can tell,
they were essentially ignored as far as influencing the draft in any
way.

On Thu, 6 Jan 2005 11:55:59 -0500, codemastr <codemstr at ptd.net> wrote:
> > Furthermore, I did not mention anything about *how* to supply the
> > version token or anything else. I'm not "assuming the definition of a
> > token" or any such. I'm just brainstorming.
> But my point is, you're suggesting that it should be a token, which in
> itself is a limitation. Who says that DCC version 10.0 is even going to use
> tokens? Who says it is even going to use ASCII characters? Who says it is
> even going to be human readable? All these things are assumptions that will
> need to be made if we create a Version token. That's all I'm trying to say.
> Having it as part of the CTCP name eliminates this problem since we can just
> ignore a CTCP we don't understand, we don't have to begin parsing tokens,
> then realize we have a version we don't support, then back out. Basically,
> it just allows us to detect failure faster.
> 
> > instead of the client knowing it's a DCC request that it can't handle and
> > responding appropriately, it doesn't know anything at all if you change
> > the
> > CTCP name
> No, the client just needs to be taught to recognize DCCN rather than just
> DCC2. Pseudocode:
> if (substr(ctcp,3) == "DCC" && charAt(3) != '2') send_error("Unsupported DCC
> version");
> That right there would handle the error checking. If it is DCC3, DCC4, etc.
> we don't understand it. If it is DCC2, we do understand it. Would doing
> "DCC2 1.0" be bad? Not really, but I just think that's a bit confusing...
> it's version 1.0 of DCC version 2? That seems confusing to me. Isn't just
> saying "DCC2" clear enough that we mean DCC version 2 and "DCC3" clear
> enough that we mean DCC version 3?
> 
> > Speaking of which, of all the ideas I've posted here, nobody pretty
> > much concluded anything one way or another about them. I'd have to
> > look back over the archives but I nothing really sticks in my mind. If
> > this kind of snotty reply is all I can expect for direct feedback then
> > go ahead and count me out.
> If you think this is a "snotty reply" you misinterpreted what I said. I
> didn't attack you nor your idea, nor did I "jump on you" once, I provided an
> analysis of your idea and offered, in my opinion, a better solution; a
> solution that was inspired by your idea, which would mean I thought your
> idea had merit. I just simply think the implementation of your idea can be
> better, and coming up with the best implementation possible is what a group
> designing an RFC is supposed to do. If I thought your idea was stupid, I
> would have said that I think versioning is a bad idea. I didn't say that
> because I do think your idea is valid; I just think a token is a bad idea.
> And, if I just said, "a token is bad," I would hope the next question
> someone would ask is "why?" so I included my reasons why. I was never
> intending to insult/attack you in any way.
> 
> Btw, I don't think"nobody concluding anything" is a good thing. Isn't the
> purpose of this group to reach a conclusion? If we aren't going to reach
> conclusions, how do we ever expect to come to an agreement for an RFC?
> 
> -- codemastr
> 
> _______________________________________________
> dcc2 mailing list
> dcc2 at dcc2.org
> http://six.pairlist.net/mailman/listinfo/dcc2
>