Renamed SRTO_STRICTENC to ...ENFORCEDENCRYPTION. Fixed documentation

[ethouris]

closes #755

[ethouris]

As per #755

[stevomatthews]

• [SET] - This option forces both connection parties to have the
  same passphrase set, including empty (that is, with no encryption).
  Otherwise, the connection is rejected.

When this option is set to FALSE on both connection parties, a
connection is allowed even if the passphrase differs on both parties,
or it was set only on one party. Note that a payload sent by
the party that has set a passphrase can be sent over the network,
but won't be decrypted and delivered.

This option can be used when the user knows both parties in a connection,
so that there is no possible intrusion by a rogue sender. It can also be useful
in situations where it is important to know whether a connection is possible.
The inability to decrypt an incoming transmission can then be reported
more accurately.

[ethouris]

@stevomatthews :

[...]
Note that a payload sent by
the party that has set a passphrase can be sent over the network,

I'd still rather say that the payload will be sent over the network.

The actual situation is that if an application, where SRT socket is set passphrase, tries to send a payload over this connection, it is allowed to do it anyway, provided that the connection is established. And when it does it, it will be, in the end, sent over the network and received by the peer receiver. Just the receiving party will not be able to decrypt this payload and it will drop it without delivering to the receiver application.

I don't know how to describe it shorter and cleaner :) Maybe something like:

Note that the party that has set a passphrase is still allowed to send data, and it will be also sent over the network, however the receiver will not be able to decrypt it and it will drop it without delivering to the application.

And, not sure if this needs extra clarification, but maybe it can be also worth mentioning that the party that has set no passphrase can send data that will be successfully received by the receiving peer.

[stevomatthews]

@ethouris

I'd still rather say that the payload will be sent over the network.
Oh, the subtleties of the English language ;-) . . . not necessary to use "will" in this case, just to be clear about the consequences "when". Having said that . . .

Note that the party that has set a passphrase is still allowed to send data, and it will be also sent over the network, however the receiver will not be able to decrypt it and it will drop it without delivering to the application.

And, not sure if this needs extra clarification, but maybe it can be also worth mentioning that the party that has set no passphrase can send data that will be successfully received by the receiving peer.

I found an error in my own formulation. Fixing that, and taking your above comments into consideration, I propose the following:

--BEGIN--
Note that the party that has set a passphrase is still allowed to send data over the network. However, the receiver will not be able to decrypt that data and will not deliver it to the application. The party that has set no passphrase can send (unencrypted) data that will be successfully received by its peer.
--END--

^^ replaces the following sentence: "Note that a payload sent by the party that has set a passphrase can be sent over the network, but won't be decrypted and delivered."

[ethouris]

@stevomatthews Works perfectly for me. I'll paste this text as is in the update.

[maxsharabayko]

Might be worth adding this matrix to API.md?
non blocking mode, caller-receiver, listener-sender.

[maxsharabayko]

Blocking mode

[ethouris]

Good idea, but later. Now we are running out of time for 1.4.0.