Re: [cti-taxii] Restrictions on resource names

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

I think it would be overly limiting to not allow people to create collection names with non-latin1 characters. People will want to create collection names in their own language.

-
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


"Bret Jordan (CS)" ---10/10/2016 01:58:42 PM---I updated the restrictions in TAXII to be current with what we do in STIX and fixed the inconsistenc

From: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
To: Dave Cridland <dave.cridland@surevine.com>
Cc: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 10/10/2016 01:58 PM
Subject: Re: [cti-taxii] Restrictions on resource names
Sent by: <cti-taxii@lists.oasis-open.org>

---

I updated the restrictions in TAXII to be current with what we do in STIX and fixed the inconsistencies between the API-bases and Resources. 

Bret

---

From: Dave Cridland <dave.cridland@surevine.com>
Sent: Monday, October 10, 2016 3:56:59 AM
To: Bret Jordan (CS)
Cc: cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Restrictions on resource names 
 
Scrap them all. 

HTTP and the URI specs all have detailed syntax restrictions on the form of a URI. Trying to introduce new ones seems to have little benefit, and these probably don't mean what you think they mean.

An API Base cannot now span multiple path segments in a URI. I have no idea what this restriction is intended to serve.

It's reasonable to assume that this would allow a client to use a fixed-length buffer to store a URI string - handy if we're writing TAXII clients in assembly - but this presupposes that the client has checked the lengths of all URI-related parameters given by the server, and a key issue about introducing rules such as these is that one needs to define the error behaviour. Does the client now give up, or - more likely - does it just carry on anyway?

Having "SHOULD" <=30 and "MUST" <=256 means people will assume they can ignore the SHOULD - and they can. These rules are written from the point of view of a producer - rewrite them as a consumer and you'll see:

* Consumers MUST reject any resource name containing any characters other than lowercase ASCII letters and the underscore character.
* Consumers MUST reject any resource name containing fewer than 3 characters.
* Consumers MUST reject any resource name containing more than 256 characters.

How does one rewrite the SHOULD rule in the terms of a consumer? What must a consumer do when faced with a resource name between 31 and 256 characters long? If it MAY reject them, then that implies the producer MUST NOT generate them. Or can it truncate over-long resource names - can it choose when to truncate anywhere between 30 and 256 characters?

Incidentally, I have removed the restriction on ASCII because URIs are always in ASCII. By eliminating "%" and numbers, you've blocked the percent-encoded UTF-8 anyway.

On 8 October 2016 at 16:00, Bret Jordan (CS) <Bret_Jordan@symantec.com> wrote:

All,

Previously in the TAXII SC we had talked about and agreed to have some restrictions to the names and lengths of API-Bases and Resource names like "channel names" and "collection names".

In STIX we do not have restrictions for the contents of a "string" property. However, we do have very tight restrictions for property names and custom properties / custom objects.

The current restrictions we have in place and nearly a copy-n-paste from what we do in STIX today, they are:

* An API Base MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and dash (-).
* An API Base SHOULD be no longer than 30 ASCII characters in length.
* An API Base MUST have a minimum length of three ASCII characters.
* An API Base MUST be no longer than 256 ASCII characters in length.

* Resource names MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and underscore (_).
* Resource names SHOULD be no longer than 30 ASCII characters in length.
* Resource names MUST have a minimum length of three ASCII characters.
* Resource names MUST be no longer than 256 ASCII characters in length.

Personally I really like this approach, I believe there to be value in restricting these. I am, however, curious to know if the SC still feels this is the best way to go.

Bret

-- 
Dave Cridland

phone +448454681066
email dave.cridland@surevine.com
skype dave.cridland.surevine

Participate | Collaborate | Innovate

Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND
If you think you have received this message in error, please notify us.