Why SHOULD and not MUST or MAY (DISCUSS from Fransesca)

[boucadair]

In several places (see below for what I identified as problematic SHOULDs) the
document lacks text about why these are SHOULD and not MUST or MAY. I agree
with John Klensin, who formulated it very clearly: If SHOULD is used, then it
must be accompanied by at least one of: (1) A general description of the
character of the exceptions and/or in what areas exceptions are likely to
arise. Examples are fine but, except in plausible and rare cases, not
enumerated lists. (2) A statement about what should be done, or what the
considerations are, if the "SHOULD" requirement is not met. (3) A statement
about why it is not a MUST. I believe some context around these would be enough
to solve my concern, and give the reader enough context to make an informed
decision. If you believe the context is there, and I just missed it, please do
let me know.

Francesca

Section 6.2:

A server SHOULD NOT use properties that are not included in the request body
to determine the URI of a TIPS view, such as cookies or the client's IP address.

If the TIPS request does not have a "resource-id" field, the error code of
the error message MUST be E_MISSING_FIELD and the "field" field SHOULD be
"resource-id".

The "field" field SHOULD be the full path of the "resource-id" field, and the
"value" field SHOULD be the invalid resource-id.

Section 7.2:

Hence, the server processing logic SHOULD be:

Section 8.5:

If the new value does not, whether there is an update depends on whether the
previous value satisfies the test. If it did not, the updates graph SHOULD NOT
have an update.

[boucadair]

@emiapwil, can you please check this one and report back to Francesca? Thank you.

[emiapwil]

Got it.