I'd suggest using _must_ and _must not_ or another way of signifying
these requirements, distinct from IETF RFC standards-track language.
As you note in another mail:
$ Even worse, there are probably vendors, etc,
$ out there who, seeing the Internet Draft, will say "Aha!
$ The Requirements Standard!!" We _know_ that people do this,
$ so why cater to their lack of intellectual capacity?
On Thu, 7 Mar 2002, Kastenholz, Frank wrote:
> There was some question about what we intended with
> respect to mobility. This seems to be an artifact
> of the way I write these sort of specifications...
>
> If, from a requirements perspective, the architecture
> must do/support/provide/etc some feature, FOO, then the
> spec will say "The architecture MUST do FOO". That means
> that FOO has to be done.
>
> If, from a requirements perspective, the architecture
> is forbidden to do FOO then we say "The architecture
> MUST NOT do FOO"
>
> If we really do not care whether the architecture does
> something or not then either we don't mention it at all
> or say "The architecture MAY do FOO". Obviously we can
> not list all the things that we don't care whether the
> architecture does or does not do... The list would indeed
> be very very long...
<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT