[salud] Section 13 (was: Gen-art LC review of draft-ietf-salud-alert-info-urns-12)

[[e-mail] (Dale R. Worley)]

[as an author]

Acting on Ben Campbell's suggestion that we consider revising the
first sentence of section 13 so that it can support a MUST, I've
written a revision:

[In this message, I've separated the three sentences to make
comparisons easier; it is all one paragraph.  I changed "explicitly
instructed" to "instructed" in sentence 3.]

     13.  User Agent Behaviour

     The User Agent (UA) must produce a reasonable rendering
     regardless of the combination of URIs (of any schemes) in the
     Alert-Info header field:

     It MUST produce a rendering based on the URIs that it can
     understand and act on (if any), interpreted as prescribed by
     local policy, and ignore the other URIs.

     In particular, unless the containing message is a request and is
     immediately rejected, the UA SHOULD provide some alert unless it
     is instructed not to (for example, by Alert-Info URIs that it
     understands, the presence of a Replaces or Joins header field,
     local policy, or direction of the user).

What do people think?

I think that sentence 2 is really what we intended by sentence 1.  I
left in sentence 1 to give guidance to the overall idea, while
sentence 2 gives the details.

I included "URIs that it can ... act on", because it's possible that a
UA could receive an http: URI but be unable to fetch its contents, or
be unable to decode the fetched contents.

Of course, sentence 2 allows a lot of latitude for implementations,
because it says "interpreted as prescribed by local policy", but I
think it gives the right effect, because, e.g., I don't think anyone
is willing to say "local policy is that if we can't process a URI, we
will just generate white noise".

In sentence 3, I removed "explicitly" because a number of the listed
factors that "instruct" the UA not to alert aren't really "explicit".

And I found another cause not to alert:  re-INVITEs.  But I didn't add
it to the list, because we already list 5 factors.  Presumably the
implementors will understand that.

However, I think that the fact that we've found another factor shows
that we want this requirement to be a SHOULD.  As it says in RFC 2119:

   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Dale