NSIS message formats are defined as a set of objects (see Appendix C.1).  Some
aspects are left open:

Ordering: Traditionally, Internet protocols require a node to be able to process
a message with objects in any order.  However, this has some costs in parser
complexity, testing interoperability, ease of compression; there is a special
issue with GIMPS that for efficiency, the NSLP-Data object (which may be large)
should come last.  Should object order be fixed or unspecified?

NSLP Versioning: The current working assumption is that if an NSLP for a
particular signaling application is changed so radically that it is no longer
backwards compatible, an entirely new NSLPID will be allocated.  However, this
leads to a problem when a node supporting both variants needs to discover its
downstream peer. If it probes for the 'early' NSLPID it will not detect the case
where the downstream peer supports the later one; if it probes for the 'later'
NSLPID, a downstream peer supporting only the early variant will bypass the
message altogether.  The implication is that a single NSLPID should be used even
in this case, with demultiplexing based on a separate version number (which
could be carried in the common header, or within the NSLP payload).