[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-cybox] IP Address Notation (or: I Love CIDR When It's Talking About More Than One IP Address)
On 22.01.2016 09:08:14, Jason Keirstead wrote: > These are two different problems. > > The way grammar is defined in an RFC or other spec and the way a > library validates that grammar are aligned pretty much never. Do > standard libraries use ABNF to validate the format of IPs? No they > do not... > Hi, Jason - You assert that standard libraries don't use ABNF for input validation. While that is surely true in a large number of cases [0], there are plenty of standard libraries that do input processing via parsers generated from ABNF (a la lex/yacc). But setting aside that little nit, the real question is what do we as a TC want to do in terms of specifying field-level validation? Ivan already pointed out that ABNF isn't going to work with JSON Schema. Looking to the "IDs should be UUIDs" proposal John Wunder shared yesterday, I see both ABNF and JSON Schema (PCRE subset) definitions for CTI Object IDs. There are fields where we *should* provide this level of specificity in the standards. But which fields? All? If not, what's a useful heuristic in making that determination? My strong preference would be that where we choose to provide this level of specificity, that we do it in JSON Schema. We already have enough of a problem keeping UML models in sync with JSON Schema without adding to it the challenge of keeping ABNF and regex field restrictions in sync. Thoughts? [0]: If I had a dollar for every parser out there in the wild that naively attempts to parse context-sensitive input formats via regex, I could retire today. :-P -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra | An FS-ISAC & DTCC Company www.soltra.com -- "It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it." --RFC 1925
Attachment:
signature.asc
Description: PGP signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]