The mnemonic “JMPN” appears just once in table A-6 in section A.4.2 of Intel’s Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2 (2A & 2B): Instruction Set Reference, A-Z (ISA), physical page 1486 and native page A-21. The entry maps the beginning of the instruction to function as follows:
11111111 xx100xxx → “JMPNf64 Ev”. I have come to expect that the meanings of instructions expressed in binary can be found by consultant the tables is appendix A to find a mnemonic, and then consulting of the alphabetical Instructions Set Reference. I read the text of the lengthy section on Jcc mnemonics. I looked in the preference of the Instructions Set Reference for common suffixes such as ‘N’ but found nothing. I consulted the introduction to appendix A and found nothing. I searched the web and found many maps between FF 25 to and JMPN, but no semantics. I found one piece of mysterious C code that seemed to consider it a nop. It is the first instruction of the memcpy routine in Apple’s Darwin environment. I wish I knew what it did.
Is JMPN a ‘Near JMP’ as in phi page 625 of ISA? “JMPF” also appears just once in ISA. Looking thru the ops with mnemonic JMP leads me to suspect that one of them corresponds to JMPN, but it will take more work for me to be sure. Users who have programmed x86 for many decades would have guessed this immediately I suppose. By process of elimination there is just one entry under the ‘alternatives of the ISA action for JMP: FF /4 with 64 bit offset.

I have not yet found a definitive rule in the manual for the presence of an SIB byte in an instruction.

A footnote to Appendix A mentioning JMPF and JMPN would have saved me a few hours.

The 6th item in the table titled “JMP—Jump” on page 624 lays claim, I suppose, to all instructions beginning 111111111, xx100xxx. Now we must decipher “JMP r/m64” and “Jump near, absolute indirect, RIP = 64-Bit offset from register or memory”. Op encoding = “ModRM:r/m (r)” as operand 1.

Pages 73 thru 93 describe the format of the descriptions of individual instructions. I see on page 79: “r/m64 — A quadword general purpose register or memory operand used for instructions whose operand-size attribute is 64 bits when using REX.W.”. I would expect near by a description of how this alternative is settled.

Other notes: 

Instruction Operand Encoding
Page 56 2.3.6 is part of 2.3 (vectors) which is not relevant here.
Page 81 3.1.1.4 is part of 3.1.1 (page 73) "Instruction Format"
Page 616 Jcc
Page 624 JMP
FF /4  JMP r/m64  [ModRM:r/m (r)] <- Instruction Operand Encoding
ModRM = ModR/M?
Page 38 sec 2.1.3: ModRM determines whether there is an SIB byte.
Table 2-1 tells encoding.
When ModRM = 25 then operand is [DI] (contents of register DI, I suppose)

Section 2.1.3 says: "Certain encodings of the ModR/M byte require a second addressing byte (the SIB byte).".
Which encodings?
It goes on: "See Section 2.1.5 for the encodings of the ModR/M and SIB bytes.".
The answer down not jump out of section 2.1.5 (Page 38).
Appendix B (Page 1498)

I see in Table 2-2 (Page 41) a footnote:
  1. The [--][--] nomenclature means a SIB follows the ModR/M byte.
Perhaps this is necessary and sufficient.
This happens when R/M = 100 and Mod ≠ 11.
I shall program under that assumption.

JMP at p. 624 N.S.

Decoding algorithm:
  decode first byte via table A-2 (page 1475)
  If entry includes "Grp" go to table A.4.2 (page 1486)
    and use group number is entry.
  Consult main body of doc alphabetically for such a mnemonic.

Decoding FF 25.
Table A-2 page 1476
FF -> INC/DEC Grp 5 1A
Table A-1 page 1473
1A -> Bits 5:3 of ModRM are sub op in A.4 (p 1485)
ModRM = 25 = 0010 0101 = 00 100 101; bits 5:3 = 100
Table A-6 (p 1486) 
FF 100 -> JMPN f64 Ev
f64 -> op size=64
ModRM = 00xxxxxx -> op in memory
Page 38 sec 2.1.3: ModRM determines whether there is an SIB byte.
Table 2-2 (p 41) shows encoding.
Evidently no SIB in 64 bit mode.
Lore of JMPN leads to JMP table (p 624) Jump near, absolute indirect,
The B in column 3 leads to end table indicating "ModRM:r/m (r)" of "Instruction Operand Encoding" which is explained ??
See note about "N.S." notation in sec 3.1.1.5 (p 82)

Considering the above I feel that the Intel instruction set has no published definitive description. I suppose that the oral tradition plus experiments suffice to write code. I would love to know how the BOCHS project found the information that instructs their design. This is not suitable for gaining confidence about code. I do not suspect obfuscation but the result is nearly the same. I wonder how many lurking F00F bugs remain. I think that the architecture is far more complex now in the same direction that hid the F00F bug, than in 1997.