Automatically merged updates to draft EIP(s) 721

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-721.md

@@ -85,7 +85,7 @@ interface ERC721 /* is ERC165 */ {
     ///  `_tokenId` is not a valid NFT. When transfer is complete, this function
     ///  checks if `_to` is a smart contract (code size > 0). If so, it calls
     ///  `onERC721Received` on `_to` and throws if the return value is not
-    ///  `bytes4(keccak256("onERC721Received(address,uint256,bytes)"))`.
+    ///  `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`.
     /// @param _from The current owner of the NFT
     /// @param _to The new owner
     /// @param _tokenId The NFT to transfer
@@ -155,22 +155,21 @@ interface ERC165 {
 A wallet/broker/auction application MUST implement the **wallet interface** if it will accept safe transfers.
 
 ```solidity
-/// @dev Note: the ERC-165 identifier for this interface is 0xf0b9e5ba.
-///  Note: the application will get the prior owner of the token
-///  via _from parameter -- but it will NOT see who called safeTransferFrom.
+/// @dev Note: the ERC-165 identifier for this interface is 0x150b7a02.
 interface ERC721TokenReceiver {
     /// @notice Handle the receipt of an NFT
     /// @dev The ERC721 smart contract calls this function on the recipient
     ///  after a `transfer`. This function MAY throw to revert and reject the
     ///  transfer. Return of other than the magic value MUST result in the
     ///  transaction being reverted.
     ///  Note: the contract address is always the message sender.
+    /// @param _operator The address which called `safeTransferFrom` function
     /// @param _from The address which previously owned the token
-    /// @param _tokenId The NFT identifier which is being transfered
-    /// @param data Additional data with no specified format
-    /// @return `bytes4(keccak256("onERC721Received(address,uint256,bytes)"))`
+    /// @param _tokenId The NFT identifier which is being transferred
+    /// @param _data Additional data with no specified format
+    /// @return `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`
     ///  unless throwing
-    function onERC721Received(address _from, uint256 _tokenId, bytes data) external returns(bytes4);
+    function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes _data) external returns(bytes4);
 }
 ```
 
@@ -297,7 +296,7 @@ Failed transactions will throw, a best practice identified in ERC-223, ERC-677,
 
 Creating of NFTs ("minting") and destruction NFTs ("burning") is not included in the specification. Your contract may implement these by other means. Please see the `event` documentation for your responsibilities when creating or destroying NFTs.
 
-We considered adding an operator parameter to `onERC721Received`. This would allow you be to approved for a token and then send it to a wallet/broken/auction application, then that application could recognize you as the one that sent it. Instead, we opted to not add an operator parameter. If you want to take a token from somebody else and send it to these applications on your behalf then you should use two transactions. People writing wallet/broken/auction should recognize that the from address they receive is the previous token owner from the perspective of the ERC-721 contract. Those applications may have a different concept of ownership (beneficial ownership) that they need to consider.
+We questioned if the `operator` parameter on `onERC721Received` was necessary. In all cases we could imagine, if the operator was important then that operator could transfer the token to themself and then send it -- then they would be the `from` address. This seems contrived because we consider the operator to be a temporary owner of the token (and transferring to themself is redundant). When the operator sends the token, it is the operator acting on their own accord, NOT the operator acting on behalf of the token holder. This is why the operator and the previous token owner are both significant to the token recipient.
 
 *Alternatives considered: only allow two-step ERC-20 style transaction, require that transfer functions never throw, require all functions to return a boolean indicating the success of the operation.*