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
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.