New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update JSON Reference #43
Comments
@varnerac What do we need to do, besides update the reference? Is there specific text around UTF-8 that we need to clarify or change? |
@jordan2175 Currently, TAXII 2.0 only mentions UTF once, around the The closer we adhere to the JSON standard, the easier it is to implement (adoption) using standard JSON libraries. It could be clarified with:
matching the RFC 8529 recommendation for non-closed systems. There are indications that the encoding of JSON character sets are murky, like oasis-open/cti-taxii-client#10 Additionally, the IANA media type for JSON specifically omits parameters, which would include character set. It'd be nice to address/clarify before solving #29 |
We discussed this on the working call on 2018-02-20 with the following 15 TC members (Bret Jordan, Trey Darley, Chris Ricard, Christian Hunt, Dan Dye, Dave Lemire, Drew Varner, Efrain Ortiz, Gary Katz, Jane Ginn, John-Mark Gurney, John Wunder, Nicholas Hayden, Paul Patrick, Rich Piazza). The consensus on the call was to do this and mandate that JSON based encoding must use UTF-8. We recognized that we need to verify this will not break things for our members from APAC and I will do that. |
Hi, this is Ryu, a guy from APAC. I do not think making UTF-8 mandatory does not break things. Actually making sure that it is always UTF-8 (even when it consists of only Latin-1) what you receive is better and simpler, and break less things. |
Agree, mandate UTF-8. |
How about adding it at the end of "1.4.7 Content Negotiation"? Old text:
New text:
|
Added a section 1.5.7 on serialization to address this. The text now reads:
|
TAXII 2.0 references RFC 7159 for JSON. It was obsoleted by RFC 8259
TAXII 2.1 should reference RFC 8259. Additionally, RFC 8529 changes course on Character Encoding, moving away from non-UTF-8 payloads.
The text was updated successfully, but these errors were encountered: