Automatically merged updates to draft EIP(s) 1155 (#2074)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-1155.md

@@ -44,7 +44,7 @@ pragma solidity ^0.5.8;
 interface ERC1155 /* is ERC165 */ {
     /**
         @dev Either `TransferSingle` or `TransferBatch` MUST emit when tokens are transferred, including zero value transfers as well as minting or burning (see "Safe Transfer Rules" section of the standard).
-        The `_operator` argument MUST be msg.sender.
+        The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).
         The `_from` argument MUST be the address of the holder whose balance is decreased.
         The `_to` argument MUST be the address of the recipient whose balance is increased.
         The `_id` argument MUST be the token type being transferred.
@@ -56,7 +56,7 @@ interface ERC1155 /* is ERC165 */ {
 
     /**
         @dev Either `TransferSingle` or `TransferBatch` MUST emit when tokens are transferred, including zero value transfers as well as minting or burning (see "Safe Transfer Rules" section of the standard).      
-        The `_operator` argument MUST be msg.sender.
+        The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).
         The `_from` argument MUST be the address of the holder whose balance is decreased.
         The `_to` argument MUST be the address of the recipient whose balance is increased.
         The `_ids` argument MUST be the list of tokens being transferred.
@@ -242,7 +242,8 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op
 * Forwarding should be considered acceptance and then initiating a new `safeTransferFrom` or `safeBatchTransferFrom` in a new context.
     - The prescribed keccak256 acceptance value magic for the receiver hook being called MUST be returned after forwarding is successful.
 * The `_data` argument MAY be re-purposed for the new context.
-* If forwarding unexpectedly fails the transaction MUST be reverted.
+* If forwarding fails the transaction MAY be reverted.
+    - If the contract logic wishes to keep the ownership of the token(s) itself in this case it MAY do so.
 
 #### Rules
 
@@ -269,7 +270,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op
 **_TransferSingle and TransferBatch event rules:_**
 * `TransferSingle` SHOULD be used to indicate a single balance transfer has occurred between a `_from` and `_to` pair.
     - It MAY be emitted multiple times to indicate multiple balance changes in the transaction, but note that `TransferBatch` is designed for this to reduce gas consumption.
-    - The `_operator` argument MUST be msg.sender.
+    - The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).
     - The `_from` argument MUST be the address of the holder whose balance is decreased.
     - The `_to` argument MUST be the address of the recipient whose balance is increased.
     - The `_id` argument MUST be the token type being transferred.
@@ -278,7 +279,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op
     - When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address).
 * `TransferBatch` SHOULD be used to indicate multiple balance transfers have occurred between a `_from` and `_to` pair.
     - It MAY be emitted with a single element in the list to indicate a singular balance change in the transaction, but note that `TransferSingle` is designed for this to reduce gas consumption.
-    - The `_operator` argument MUST be msg.sender.
+    - The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).
     - The `_from` argument MUST be the address of the holder whose balance is decreased for each entry pair in `_ids` and `_values`.
     - The `_to` argument MUST be the address of the recipient whose balance is increased for each entry pair in `_ids` and `_values`.
     - The `_ids` array argument MUST contain the ids of the tokens being transferred.
@@ -292,7 +293,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op
     - To make sure event order is correct in the case of valid re-entry (e.g. if a receiver contract forwards tokens on receipt) state balance and events balance MUST match before calling an external contract.
 
 **_onERC1155Received rules:_**
-* The `_operator` argument MUST be the address of the account/contract that initiated the transfer (i.e. msg.sender).
+- The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).
 * The `_from` argument MUST be the address of the holder whose balance is decreased.
     - `_from` MUST be 0x0 for a mint.
 * The `_id` argument MUST be the token type being transferred.
@@ -309,7 +310,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op
     - The set of all calls to `onERC1155Received` and `onERC1155BatchReceived` describes all balance changes that occurred during the transaction in the order submitted.
 
 **_onERC1155BatchReceived rules:_**
-* The `_operator` argument MUST be the address of the account/contract that initiated the transfer (i.e. msg.sender).
+- The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).
 * The `_from` argument MUST be the address of the holder whose balance is decreased.
     - `_from` MUST be 0x0 for a mint.    
 * The `_ids` argument MUST be the list of tokens being transferred.