In TCP-Social the ideal is to not implement or support official standard of any kind. Instead there will be an effort to use practices. If you need a way to do something that a specified protocol would support it is preferred that you ignore the standard. This is especially true of network standards. That means that we are not going to support http or ftp, or ask that anyone else does in order to participate. It is better to recommend a practice then define a standard. If something approaching a standard is required then it is preferable that it can be described in less than 4096 characters, or even better 1024, and that it isn't something recognized by ISO, RFC, IEEE or W3C or others. The only standards we will recognize are TCP/IP. To some extent we recognize SSL, so encryption can be supported. But this is because SSL becomes the medium carrying TCP-Social. It's the difference between SSL + TCP-Social vs TCP-Social + SSL The top one is OK. We will not support SSL, but SSL might support us.