I can go with HTTP/2 and that might even solve more of our problems and help us look slightly more progressive without the scary factor. So as of right now we have two options for a protocol...
HTTP/1.1 HTTP/2
Thanks,
Bret Bret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
I think HTTP/2.0 should be on the short list as well, as it also meets all the requirements, and enables various additional capabilities.
- Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
<graycol.gif>"Davidson II, Mark S" ---2015/08/25 02:57:00 PM---All, As I mentioned in a previous email, not having a protocol to work with has ended up slowing dow
From: "Davidson II, Mark S" <mdavidson@mitre.org> To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org> Date: 2015/08/25 02:57 PM Subject: [cti-taxii] Protocol Shortlist - Add HTTP Sent by: <cti-taxii@lists.oasis-open.org>
All, As I mentioned in a previous email, not having a protocol to work with has ended up slowing down prototype work. IMO, a shortlist of protocols needs to be picked for prototyping efforts, and I’d like to start that by proposing HTTP be added to the shortlist. That will unblock me so I can write some code that does something. I think HTTP meets our requirements and also works well with Sergey’s idea of incremental change. Here’s my take on how HTTP stacks up to the protocol requirements we’ve written down so far [1]: > 1. Minimal changes to existing firewall deploymentsAFAIK, just about every FW everywhere let’s HTTP and HTTPS through, so I think this one is met. > 2. Robust ecosystem of TAXII Server platformsThere are lots of platforms (Web Servers, Messaging Products, etc) that support HTTP or have HTTP interfaces. I’d go as far as to say that I don’t think choosing HTTP would preclude any technology stack that I’ve been exposed to. > 3. Ubiquitous, well supported client libraries.HTTP has libraries in every language on just about every platform that I know about. > 4. Well understood by the software development communityHTTP is IMO the best understood protocol by the development community. > 5. Supportable in cloud infrastructuresHTTP is used widely in cloud infrastructures > 6. Integration within existing vendor communication channelsI can’t really speak to this one – somebody else will have to chime in. > 7. Ability to push information from a server to a clientThis is where native HTTP doesn’t work great. Though perhaps a workaround like long polling could be sufficient. > 8. Protocol efficiency / minimal verbosityI don’t have any experience or information to make an assessment here. Please note that this does not represent a group consensus, merely that HTTP is being explored further. Absent dissenting opinions, I’ll work on an HTTP-based prototype and share something about it before too long. Are there other protocols that should be added to the shortlist? Thank you.-Mark [1] https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-2.0-Requirements#protocol-requirements
|