Hi Tamama!

> Without the 3rd step in connecting to a server additional
> requests are very hard [...] to do.

Hmm, really? You can just repeat the first steps again and again (if you really need it, 4 steps, 6 steps, 8 steps...). So we are flexible here. In most cases two steps will be fine, I guess. The transition from connect-sequence (HTTP-headers) to binary messages (Gnutella descriptors) could be easily detected: If there is no further string "GNUTELLA/", the binary data stream starts and will run until disconnection of that peer. (Revised, see rev 1 posting below)

> However what would a server do if it would get a bad [...] header?
> Right!, usually they disconnect.

They ignore it as far as I understood the v0.6 handshaking? Each side tells what it supports or wants (2 sides = two steps), then they start to talk Gnutella. If one side doesn't know a feature of the other side, it ignores it. When both sides supports a feature (e.g. 'Query Routing'), then they can use this feature.
It's similar to what happens when a v0.4 client connects a v0.6 client. The old client will connect with "GNUTELLA CONNECT/0.4<lf><lf>", the modern client will recognize this and not continue with a 0.6 connect sequence, instead use the "common language".

> If one could think of a request that needs to be done outside
> the initial 2 handshake headers, please post them here

Dito

> B needs to 'downgrade' search requests and 'upgrade' searchhits from A to B or C.
> This would be very hard for example chinese to standard ASCII.

Yep, veeeery hard! *g* Therfore I suggested to use only ISO LATIN 1 as a default, no negotiation in the connection header!
But within Query/Queryhits a asian client might want to use Unicode (e.g. chinese characters). All other asian clients will understand and could reply... non asian clients don't understand (they don't have asian files), but can route without problems. This type of communication does perfectly fit into the HUGE proposal. With a unicode standard all world wide servants can communicate and speak the same language. Actually also non asian clients could be part of a world wide swarming, when they understand UNICODE.
I also prefer ISO_LATIN 1 as default, because it is a one byte code per character, while UNICODE is a multibyte code! UNICODE as default would unnecessarily increase the allready high broadcast traffic.

> Some non-yahoo group (emailed) based paper on these GUIDs would be nice indeed.

Hehe, yep. At least the required Yahoo account is very anoying IMHO and doesn't help to attract new developers.

Greets, Moak