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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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


Subject: Re: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area


Altitude matters but likely building floor matters more especially for intelligence related to a multi-floor building typical in large cities or enterprise environments where the need to identify a specific floor is required.

 

So floor level or altitude could be considered a way of solving that specific use case.

 

Allan Thomson

CTO

+1-408-331-6646

LookingGlass Cyber Solutions

 

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Date: Monday, July 24, 2017 at 12:28 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area

 

Sorry, I should have sent this to cti-stix, as this is really a conversation specifically about STIX.

 

From: <cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date: Monday, July 24, 2017 at 3:27 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Location - precision, altitude, and administrative area

 

All,

 

Now that the discussion on location precision has subsided, it seems like the closest thing we have to consensus is that the precision field should be optional and, if it’s not present, the precision is unspecified (i.e. no default). A consuming tool can then provide its own defaults and treat it how it thinks best. I realize this isn’t what everyone wanted, but it did seem like the most common either first or second-best option.

 

We do have two other questions to resolve:

 

1. Are there any use cases for an altitude property?

Altitude has been suggested once but we discussed it on a working call and there didn’t seem to be anything clear. Given that you can currently represent an address (including floor/etc) and lat/lng, are there any use cases that require an altitude specifically?

 

2. Should we use ISO-3166-2 for administrative area?

This was suggested on a TC call…we currently have said we’ll use ISO-3166-1 for country code, but 3166 also includes a set of values for administrative area (state, province, etc.). For example, an ISO 3166-1 alpha-2 country code is “us”, while an ISO 3166-2 area code would be “US-NY”.

 

There are some pros and cons to doing ISO-3166-2. The pros are obviously that it’s an international standard and provides a good set of values to use. That said, it isn’t in as much common use as ISO-3166-1 (country codes) is and so people will need to figure out how to find and use it.

 

 

My points of view on these:

 

  1. I can’t think of any use cases for altitude…address provides the best way to describe people on a certain floor/room in a building.
  2. We shouldn’t use ISO-3166-2 for administrative area, it’s not commonly used enough and I don’t think the value of having defined properties for that field outweighs the downside of people doing it wrong or having to figure out what it is.

 

John

 



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