I'm not sure what you're referring to, the versioning is simply a way to differentiate the document itself. It's not, as I wrote earlier, a way to indicate a version on the NMDC protocol itself.
I know, what i mean was that 1.0 don't have too much incorrect things.
Did NMDC do that type of escaping even outside of the Key/Lock? I'll change the note if NMDC indeed did use something else for other messages.
I don't really know. Afaik not in version 1. I remeber that long time ago i'm added support for that CZDC++ because it was used by DCTC and VerliBot (both added it before dc++ introduced html escapes).
Should the key and lock management be an extension? I mean, it wasn't in the original version of the protocol but something that came in later versions.
Depend on what you count as original version. For me it is NMDC hub 1.0.25 and NMDC client 1.0 Preview Build 9.1. Lock/Key is in both of them.
what should be sent in the $Supports?
In supports is ADCGet :
I have changed this and noted different implementations.
It is always not correct.
Flag is one byte, we can work with that as uint8_t.
Wrong way how to work with that is:
if(Flag == 1) // normal status
if(Flag == 2 || Flag == 3) // away
if(Flag == 4 || Flag == 5) // server
That is not how it is working in original NMDC. It is based on Bits, not value of whole byte.
Correct way is:
if(Flag & 0x2) // second bit is enabled -> away
if(Flag & 0x4) // third bit is enabled -> server
if(Flag & 0x8) // 4 bit is enabled -> fireball
if(Flag & 0x40) // 7 bit is enabled -> IPv4
if(Flag & 0x80) // 8 bit is enabled -> IPv6
In that link, you reference IP64, TLS and TLS1. Do you have any documentation of those?
IP64 is in PtokaX Wiki http://wiki.ptokax.org/doku.php?id=dcprotocol:hub_client:ipv6:ip64
with it's sister IPv4 http://wiki.ptokax.org/doku.php?id=dcprotocol:hub_client:ipv6:ipv4
TLS is documented on strongdc++ forum http://strongdc.sourceforge.net/forum/viewtopic.php?f=11&t=5528
. BigMuscle used my idea that was posted long time ago on nighthawk forum and first implemented in flowlib http://www.czdc.org/flowlib-TLS-PPK.png
and added TLS to supports so ho claim it as his extension ;D
TLS1 don't have public documentation, it is not implemented in any public software yet.
I have added a note about this; in what version did DC++ start doing this?
In 0.17 for client connections and in 0.300 for hub connection. It is dc++ extension, it is documented without space in Extensions.txt file that is distributed with dc++ source. But implemented with space.
I used the Teamfair wiki for this. Do you mean that $UserIP2 is required to have multiple nicks/IPs?
In UserIP version 1 (don't have anything in supports) client sending request $UserIP nick| and hub reply with $UserIP nick ip|, it is behave as getinfo -> myinfo in original nmdc. In UserIP version 2 (UserIP2 in supports) is no request and hub can send userip with single user $UserIP nick ip| or multiple users $UserIP nick1 ip1$$nick2 ip2$$|, this is like nicklist in original nmdc.
How do you mean violate? What does it do (in)correctly? Any suggestions on what to add to the documentation to make it clear?
Document state (and it was like this documented in original Extensions.txt what is distributed with dc++ source) "$UGetBlock must be implemented if XmlBZList is advertised". In DC++ was $UGetBlock supported from 0.307 to 0.695 and in 0.696 it was removed. XmlBZList is supported from 0.307 and in Extensions.txt was info related to $UGetBlock changed with 0.696.
And now what i'm noticed in version 1.2
It is listed in normal commands, but it is extension.
That is not extension but it is in original protocol, it was part of original hub linking.