Having read a few specifications, my impression is that the majority
have adopted the nomenclature described in RFC 2119.  This RFC defines
the words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" (and some
similar adjective and phrases).  These words give the reader a pretty
good idea how conforming software will behave.

To me, the language in SRM v2.2 specification is too vague.  Terms
(that describe the stringency with which conforming software must
adhear to described behaviour) are used apparently without any precise
definition and some of the definitions to be vague or ambiguous.  For
example:

* The term "may" is used (in my opinion) far too frequently.  If this
  term has the same meaning as in RFC2119 then all such behaviour is
  purely optional.  An example:

    1.32 "If a TURL has an indefinite lifetime, then negative value,
         -1, may be used."

    Is this behaviour completely optional?  Can conforming software
    return some other value (-42, say) to mean indefinite lifetime?
    Can conforming software return "-1" and it *not* mean "indefinite
    lifetime"?  If both are true, there seems little point mentioning
    the value in the spec.  If neither is not true, then the statement
    is too vague and should be rewritten with more precise language.
    One possible example is:

      The value returned MUST be either -1 or a positive, non-zero
      value.  A TURL MAY have an indefinite lifetime; that is, a lifetime
      governed by the availability of the underlying file.  If a TURL has
      an indefinite lifetime, then -1 SHOULD be used.  If the
      TURL has a well-defined lifetime then its duration SHOULD be used and
      the value -1 MUST NOT be used.


* The behaviour of conforming software is unclear in section one.  The
  spec. states "underlined attributes are REQUIRED."  In what sense is
  an attribute required?  Examples of possible interpretation:

     o   must parse correctly but can completely ignore any
         such requests,

     o   must parse correctly but must give suitable error-
         message if feature is unsupported,

     o   must parse correctly and provide correct behaviour
         for requests involving this type.

  What level of support must conforming software provide for
  non-underlined concepts?


* Section 1.4 states "files may be Online, Nearline or Offline."  This
  section then discounts the Offline state from SRM, thus
  contradicting itself.  However, this is also not true: at least two
  "SRM implementations" do not support Nearline (i.e. tape) storage.
  For these implementations, files may only be Online.  Perhaps a more
  precise statement is:

    Access Latency is a file attribute that is based on the file's
    underlying storage.  It describes the likely delay, during normal
    operation, between requesting a file and that file being available
    from the underlying storage.

    [... description of Online and Nearline here...]

    Membership of a given class is not exclusive.  Files is both
    Online and Nearline if (and only if) the file is available on
    multiple underlying storage with at least one storage having
    Online characteristics and at least one with Nearline.

    An SRM implementation MUST implement at least one of Online and
    Nearline and MAY implement both.

These examples are from near the beginning of the spec.  There are
similar examples throughout the spec.

Whilst I'm sure these concepts and the behaviour of conforming
software is clear to those closely involved, the current version of
the spec. does not convey this information well.

I feel it would greatly benefit the spec if all description of
behavour was refactored, making explicit use of terms from RFC 2119.
Description of the ideas and concepts behind the spec are useful, but
should always be anchored as description of conforming...