Notes:

• Please update ERC references to be links
• 0xffffffff is not a valid ERC-165 interface, please check for that
• For ERC820_ACCEPT_MAGIC please consider the value bytes4(keccak256("onNFTReceived(address,uint256,bytes)")), justification is at EIP-721 Non-Fungible Token Standard #841 and https://gitter.im/ETH-NFT/Lobby, I think we can be consistent on this mechanism
• "You can see the string a at the end." please document this better since this is a new concept
• Remove periods from end of headings
• Use backticks: getInterfaceImplementer()
• Typo: ERC777TokensReceicver
• Typo: 28bytes
• Typo: EI165

I can contribute a PR if you consider these issues valid.

@fulldecent , just updated the EIP-820. With all the typos, links, and a better explanation of Nick's deployment method.

Regarding the other 2 issues, I have 2 questions:
1.- ERC820_ACCEPT_MAGIC you propose to use one that contains the word NFT (Non fungible token) for the calculation. I don't really see the point and the logic for what you are proposing. In any case, this is just a nonsense random number that warranties that a function is implemented specifically for that intention.
2.- 0xFFFFFFFF interface it will always return invalid, because it is checked here: https://github.com/jbaylina/eip820/blob/master/contracts/ERC820Registry.sol#L115 So I don't think it's any need to add any extra check.
The remaining comments are fixed!.

For magic, perhaps you can use:

bytes4(keccak256("canImplementInterfaceForAddress(address,bytes32)"))

It is an arbitrary choice. But someone reviewing our ERC-721 said that we should reuse ERC-165 style naming because we already have a way to turn a function into a bytes4.

Second item 2 Looks good to me!

Last item: EIP-X format is to use email addresses in the byline at the top.

@fulldecent In the current implementation, the Magic number is a full word (bytes32) and not a bytes4. The porpoise of this magic number has nothing to do with EIP165. It makes no sense for me to follow that pattern. Making it so similar may bring to confusion.

No worries. Thanks for the discussion.

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

• Frontmatter is now contained between lines with only a triple dash ('---')
• Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---

Please advise if you'd like this merged as a draft in its current state.