OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [cti] Missing MTI - what to do?

I can see this happening a lot.  And the nice thing is most JSON parsers will just silently drop fields it does not understand.  I am thinking it might actually be hard to figure out if there is in fact extra data there that it does not know what to do with.  

The way I see this working is vendors communications in side a closed system (network / eco-system) may use all kinds of extra stuff.  Then at the board TAXII server, it would get stripped out.  



Bret Jordan CISSP
Director 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." 

On Jan 29, 2016, at 07:59, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

As someone who is *extremely likely* to have to make use of both provisional portions of future versions of our specifications and also proprietary enhancements for internal use - I would strongly advocate for option (b) (ignore the field). We need to be able to add fields to the JSON and have them be silently ignored if unsupported by the receiver.

Jason Keirstead
STSM, 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>Eric Burger ---01/29/2016 08:28:38 AM---There are only three choices if one is missing or has an odd MTI field: Fail the transaction / rejec

From: Eric Burger <Eric.Burger@georgetown.edu>
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 01/29/2016 08:28 AM
Subject: [cti] Missing MTI - what to do?
Sent by: <cti@lists.oasis-open.org>

There are only three choices if one is missing or has an odd MTI field:
    • Fail the transaction / reject to document
    • Ignore the field
    • Fix the field if you can

I would offer we say what we mean. There are two places to do that. The first is in the spec itself. For example, if “id” is missing, I think we would say in the spec the serialization is malformed and return an error (or silently go away). The second is to tag the transaction, perhaps at the TAXII level, with what you want to have happen. For example, if I have private extensions, I can tag them as something you can freely ignore or drop. Conversely, if I have extensions or optional fields that you really need to understand to process the message, I can tag them as something that if you do not recognize them, fail the document so I know you do not know.

For an example of this working in email system gateways, see https://tools.ietf.org/html/rfc3459
      On Jan 27, 2016, at 10:57 AM, Paul Patrick <ppatrick@isightpartners.com> wrote:

      As a side note, I’ve not seen a statement about what the appropriate behavior should be when a JSON MTI compliant consumer receives a document with a field it doesn’t understand (maybe due to a typo or somebody tried to make a private extension). But if the specified behavior was to ignore the field rather than fail the processing of the entire document, then under the situation where a JSON-LD language binding document was inadvertently sent to a consumer that only excepts JSON MTI language binding, the behavior would still allow the document to be processed as a compliant JSON MTI document since the @nodes and @fields would be ignored or skipped.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]