in particular the "should start with" being weaker (a suggestion) than "may contain only" (a requirement).
Usually when a decision is optional, that is made quite explicit. I take it the same way as a statement of what the right situation is. For example (from the Fink packaging docs):
The revision is a counter that is increased when the package description changes. It starts at 1 and should be reset to 1 when the upstream version changes
you can use curly-braces to denote exactly what character(s) should be considered for a percent expansion
The build directory is the current directory when scripts are executed; you should use relative path names in commands
It should be less than 45 chars and must be less than 60
but parentheses, commas, braces, and percent signs should not be used
A boolean value which indicates that no other packages should Depend on this one
In all these cases, 'should' means 'must' or 'will'. In a few cases, usually where it's more clear that something is optional but good, we use 'should' the other way. But I think it's very reasonable, and certainly prudent, to follow (and enforce!) the restrictions Debian says 'should' be followed for fields.
Dave
PGP.sig
Description: This is a digitally signed message part
