I'd say that INF SU should contain supports that matter for client-client functionality. Those exclude the ones that are only related to transferring files, except the supports that may be required to initiate the C-C connections (IP protocol, encryption, NATT).
I understand this view. I am simply trying to clear up the original intention of the difference. I'd have to ponder the implications of specifying what you're saying - F-type could today be used for C-H messages, too, but that'd be impossible in that scheme.
By the way, TIGR (well, any hash reference) is an exception to PseudonypH's and FarCry's view: it should be signaled in the SUP but it isn't about how communication is done (well, I can argue that 'hash algorithm to use in the communication of the connection" but I don't think most people view the hash as such).
The current specification is slightly ambiguous about it, so I'm all for clarifying it, either way things go.
This also reminds me of the mess with the supports:
- Clients signal BLO0 while the specs has "BLOM"
- Clients signal ADC0 while the spec shas "ADCS"
- Clients signal SUDP in INF SU with SUD1 and/or SUDP
- TYPE, FEED, DFAV and SUDP require the support to be signaled in INF and SUP (why both?)
- The specs define that PFSR should be signaled in SUP but I'm not aware of any client doing this (the support isn't signaled at all)
- DC++ signals BZIP in C-C SUP but this isn't mentioned in the specs
- DC++ signals UCM0 in SUP that is sent to the hub but this isn't mentioned in the specs
Telling clients to signal something in SUP is also rather inaccurate; SUP is sent in C-C connections but also when joining a hub (and the supports aren't identical in both contexts).
Ah, great. I was aware that there were problems with this, and I'm glad someone took the time to compile such a list.
There are two actions we can take (on each individual item); either change the spec or change implementations. The former is easy IFF all implementations use e.g. "BLO0" but more troublesome if some use "BLOM" as well. The obvious problem with modifying the implementations is that there needs to be an transition period where implementations all send the old form but accept the new ('proper') form, and then we remove the old form (i.e., phasing out 'bad' announcements). Modifying implementations means that they will properly match the spec, as it was agreed upon earlier - meaning a new implementation need only to follow the spec.
My guess is that many people will opt for the first suggestion (change the spec) and I have no problem with that: again, if and only if all implementations use the same. BLO0, SUD1/SUDP, UCM0 and ADC0 should be of these sorts. The following should probably be announced in SUP (if not already): SUD1/SUDP, ADC0/ADCS. The following should probably be announced in INF SU (if not already): BLOM/BLO0, UCM0/UCMD, FEED, DFAV, PFSR.
BZIP is an announcement that I feel we have a relatively low amount of versions implementing so I'd like to avoid changing the spec. (Especially since there is a distinction between the full vs get version of ZLIB.)
PFSR is something I feel should be announced in general, so it'd be my hope that implementations actually start signalling this. However, as per earlier, it should probably be signaled in INF SU. (F-type broadcast is nice in that regard.)