TODO

- dissector callbacks for invalid/abnormal segment series
  - needs h_parse_start__p() with extra data (void *)!!
  - discarded partial sequence (unexpected seqno, missing fin flag)
  - duplicate frames?
    - duplicates inside a series
    - duplicate start frames (with fir flag)?
  - extra frames outside a series (before the fir flag)?
- credits
- license

design/protocol questions:
- correct to ignore FCB on secondary frames?
- should response syntax be dependent on the associated request function?
- perform size sanity checks (see AN2013-004b) somehow at appropriate places?
- set the 'online' flag in the representation of variations without flags?!
- set the 'unit' field to ms in the representation of g52 (time + interval)?!
- are empty select requests valid?
- stricter rules for PCB/PCM in responses? (see app.c)
- is it valid to have many pcb-pcm blocks in the same request? to mix pcbs and crobs?
- should only certain IIN indexes be allowed with WRITE?!
- is single (qc=07,range=1) correct for group 51 (CTO)?
- is single (qc=07,range=1) correct for group 52 (delays)?
- are address ranges really allowed with all types of objects or only where the
  spec actually says so (g102, g110)?
- is there a minimum number of bytes in the transport payload?
- is it correct to fail the parse of an app. fragment on invalid flag combinations?
- should a CONFIRM message with unexpected (i.e. any) objects yield OBJ_UNKNOWN?
- is an empty READ request valid?
- is an empty WRITE request valid?
- is it correct to silently discard unsolicited responses without the CON (confirm) flag?
- should the relative time variants generate a PARAM_ERROR unless they are preceded by a
  Common Time-of-Occurance (CTO, group 50) object in the same message?
- is qc=17 (index prefixes) valid for bit-packed variations? which encoding is correct?
- is it valid to include multiple time (g50v1/3/4) blocks in a WRITE request?
- is it a good idea to return corrupted link-layer frames with payload=NULL?
- should a non-zero status byte in analog output (g40) requests be ignored or rejected?
  (i.e. use dnp3_p_anaout_oblock or dnp3_p_anaout_sblock)

missing features:
- device attributes
- authentication
- files
- bcd numbers
- octet strings
- other object groups > 80

implementation details:
- revisit the ugly DNP3_Object structure
  - move the 'state' field out of the DNP3_Flags struct?
- clean up header guards and includes
- make sure the note about error handling in src/app.c is still accurate
- is our use of TT_ERR+i as "error token types" actually okay?
- determine what of src/hammer.[ch] should move into hammer and do it
- is dropping the const okay when returning the input token from an action unchanged?
- act_float/double assumes compatible endianness for casting from uint64_t
- move auth object parsers into src/obj/
- should dnp3_p_binout_wblock exist or should it be just dnp3_p_g10v1_binout_packed?
- support output of arbitrary application identifier strings in format.c
- ensure we call parser-allocating functions only once during init
- move some static parser definitions out of dnp3_p_objchoice so they don't get created anew each call


spec issues:
- AN2013-004b tables
  - RESPONSE can also include g120v1 (authentication challenge)
  - CONFIRM can include g120v3,g120v9 (cf. IEEE 1815-2012 7.5.1.4 Figure 7-16)
  - event-generating point types are not listed as allowed with fc 20/21 (ENABLE/DISABLE_UNSOLICITED)
  - can FREEZE_AT_TIME_NR include g30v0 (analog input) - just like FREEZE_AT_TIME?
- parsing pseudocode in AN2013-004b does not work for READ requests, i.e. requests
  that take bare object headers?
- should the status on analog output objects be 8 bits (though 7 bits everywhere else)?
- "as long as the start bytes and CRCs check out, the frame is technically a
  frame and should be skipped as a whole" not clearly stated
  cf. https://github.com/pesco/dnp3/issues/11