In fact, this issue is now closed. All reference to NSLP versioning has been
removed in the current version (since it's assumed it will be covered in the
NSIS extensibility draft), and the object order is fixed in the ABNF anyway
(section 5.1/5.2.2). People who want an unspecified order should re-open the issue.

[updated to refer to -06]

[updated section ref. for -05 version.]

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).