search

TAXIIProject / TAXII-Specifications

A repository for development of the TAXII Specifications. For official releases, please see http://taxiiproject.github.io/releases/
http://taxiiproject.github.io/releases/
40 stars 5 forks source link

Discussion: Format Changes/Additions #62

Open MarkDavidson opened 9 years ago

MarkDavidson commented 9 years ago

The discussion around this issue might get interesting, but I think for any future revision of TAXII we should consider a format change for TAXII. Currently, XML is the only defined binding specification. Here are some other ideas:

terrymacdonald commented 9 years ago

Binary of some kind. Thrifty, Capn proto or protobuf2. Not really fussed on which one we go with, but it needs to be chosen based on speed, compression and most importantly extensibility (especially at this stage of the TAXII lifecycle). On Mar 27, 2015 1:51 AM, "MarkDavidson" notifications@github.com wrote:

The discussion around this issue might get interesting, but I think for any future revision of TAXII we should consider a format change for TAXII. Currently, XML is the only defined binding specification. Here are some other ideas:

  • JSON (As has been brought up multiple times by multiple people)
  • (Here's my own wacky idea): encode TAXII Request Messages as multipart/form-data and/or application/x-www-form-urlencoded. multipart/form-data would have the benefit of not having to encode binary files.
  • Others?

— Reply to this email directly or view it on GitHub https://github.com/TAXIIProject/TAXII-Specifications/issues/62.

jordan2175 commented 9 years ago

I really like the idea of doing a binary version, or a quasi binary version where we can get away from doing string compares to simple numerical matches. To me it seems like for small STIX messages, the TAXII overhead can be significant.