Subject: [salud] Editorial suggestions for draft-ietf-salud-alert-info-urns-06

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 7 May 2012 23:10:05 -0400

Some final editorial suggestions for the -06 draft:

- Abstract

   This document normatively updates [RFC3261], the Session Initiation
   Protocol (SIP).  It changes the usage of the SIP Alert-Info header
   field defined in the [RFC3261] by additionally allowing its use in
   all provisional responses to INVITE (except the 100 response).

This would be helped by changing the period into a colon:

   Protocol (SIP):  It changes the usage of the SIP Alert-Info header

That warns the reader that the second sentence explains exactly how
this document updates 3261.

- 1.1.  Motivation

   only works when the same vendor provides PBX and UA, as only then is

The last word should be "if".

- 4.  Namespace Registration Template

      The alert-indications are hierarchical identifiers.  The set of
      allowable characters is the same as that for domain names
      [RFC1123].  Labels are case-insensitive.  Comparisons MUST be
      case-insensitive.  Registered URNs SHOULD be transmitted as
      registered.  A new name MUST NOT be registered if it is equal by
      case-insensitive comparison to an already registered name.

The sentence "Labels are case-insensitive." is hard to understand
here.  It's completely correct, but the term "label" is only defined
below, in the ABNF.  One fix would be to move this paragraph to below
the ABNF, so the reader would know how "label" fits with the
indications.  But I think a better fix is to change "label" to
"letters".  That gives the same information, and allows us to verbally
describe the URNs before giving the ABNF.

The sentence "Registered URNs SHOULD be transmitted as registered." is
correct but we don't tell the reader that the important aspect is the
case of the letters.  Perhaps we could expand this to "Registered URNs
SHOULD be transmitted in the case that is registered."

   Validation mechanism:  Validation determines whether a given string
      is currently a validly-assigned URN [RFC3406].  Static validation
      is performed based on the currently registered Alert-Info URNs at
      IANA.

It might help to add to this paragraph the sentence
"Privately-assigned extension values can be distinguished by the
presence of a private-name.", as that is an aspect of validation, and
it is not directly stated elsewhere in the registration template.

- 5.2.3.  Alert-Info URN Indication Values for the alert-category
        'priority'

Do we want to add a <urn:alert:priority:emergency> so that the URN
priorities match the Priority values (non-urgent, normal, urgent,
emergency) in RFC 3261?  (If we make this change, section 6.2.3 needs
to be changed also.)

- 6.1.  New alert identifiers

      alert-category/      Reference    Description
      alert-identifier
      ---------------------------------------------------------------
      foo                  RFCxyz       Description of the 'foo'
                                        alert-category
      foo:bar              RFCabc       Description of the 'foo:bar'
                                        alert-identifier

I think the second "Description" should be "Description of the 'bar'
alert-identifier in the 'foo' alert-category" in order to match the
terminology in the ABNF and elsewhere.

- 7.2.  Extensions Rules for Independent Organizations

   The "<private-name>" syntax is for proprietary extensions specific to
   independent organizations.  The "<private-name>" is used in the form
   of a "reverse FQDN" of the entity that defines the extension,
   possibly followed by further components.

The second sentence could be made clearer:

   The "<private-name>" is a "reversed FQDN" of the entity that
   defines the extension, that is, the labels of a fully-qualified
   domain name that is owned by that entity, in reverse order,
   separated by periods.  (The domain name need not be the top domain
   name owned by the entity.)

In the example of the next paragraph, there is a typo in these URNs:

   urn:alert:service:call-waiting:abc.org.example.somecompany and
   urn:alert:service:call-waiting:def.org.example.somecompany (which are

The labels "abc" and "def" are incorrectly placed at the beginning of
the private-names, and should be:

   urn:alert:service:call-waiting:org.example.somecompany.abc and
   urn:alert:service:call-waiting:org.example.somecompany.def (which are

- 8.1.  Priority Rules

      c.  In case that after processing all the received URNs, the UA
      can generate more than one signal that are equally effective at
      expressing the URNs (under the preceding rules), one of those
      signals is selected.  When selecting from the set of equally
      effective signals, no signal should be chosen if a less-specific
      signal is also in the set.  (Specificity is to be judged based on
      the defined meanings of the signals to the user.)  (E.g., if each
      signal is considered to express certain alert-indications of
      certain alert-categories, one signal is less-specific than a
      second signal if the first signal's alert-indications are a subset
      or are prefixes of the second signal's alert-indications.)
      However, a more-specific signal may be chosen if the choice is
      based on information derived from the containing SIP message.
      E.g., a signal implying urn:alert-info:priority:high may be chosen
      if the SIP message contains the header "Priority: urgent".

We should ask the editorial staff if there is a way to split this
paragraph without confusion.  This might be a better way to organize
it:

      c.  In case that after processing all the received URNs, the UA
      can generate more than one signal that are equally effective at
      expressing the URNs (under the preceding rules), one of those
      signals is selected.  When selecting from the set of equally
      effective signals, no signal should be chosen if a less-specific
      signal is also in the set.  However, a more-specific signal may
      be chosen if the choice is based on information derived from the
      containing SIP message.  (E.g., a signal implying
      urn:alert-info:priority:high may be chosen if the SIP message
      contains the header "Priority: urgent".)

      Specificity is to be judged based on the defined meanings of the
      signals to the user.  (E.g., if each signal is considered to
      express certain alert-indications of certain alert-categories,
      one signal is less-specific than a second signal if the first
      signal's alert-indications are a subset or are prefixes of the
      second signal's alert-indications.)

- 9.2.  Examples of how the algorithm works

We should ask the editorial staff if there is a way to present these
many examples with less whitespace, since these 5 examples occupy 8
pages!

- 9.2.1.  Example 1

   Signals at source:internal:

      <urn:alert:source:internal>

   Signals at source:

      <urn:alert:priority:low>

      <urn:alert:priority:high>

   default

It would help to add some explanation of this list, and also,
"default" should be indented:

   Signals at source:internal:  (this is, first place)

      <urn:alert:source:internal>

   Signals at source:  (tied for second place)

      <urn:alert:priority:low>

      <urn:alert:priority:high>

      default

- 9.2.5.  Example 5

   Notice that we've used the "default" signal to cover "normal
   priority".  That is so the signal will cover situations where no
   priority URN is present, as well as the ones with
   <urn:alert:priority:normal>.  So we're deliberately failing to
   distinguish "priority:normal" from the default priority.

I think the last sentence should add:

   So we're deliberately failing to distinguish "priority:normal" from
   the default priority, which is the intention of the definition of
   priority:normal in section 5.2.

- 11.  Proxy Behaviour

This section gives a nice example:

   Following example shows both the network audio resource referenced by
   the HTTP URI and the URN indication for the call-waiting service
   transported by the Alert-Info header field in a 180 Ringing
   provisional response.

   SIP/2.0 180 Ringing
   Alert-Info: <http://www.example.com/sound/moo.wav>,
                <urn:alert:service:call-waiting>
   To: Bob <sip:[email-masked]>;tag=a6c85cf
   From: Alice <sip:[email-masked]>;tag=1928301774
   Call-ID: a84b4c76e66710
   Contact: <sip:[email-masked]>
   CSeq: 314159 INVITE
   Via: SIP/2.0/UDP server10.biloxi.example.com;
               branch=z9hG4bK4b43c2ff8.1
   Content-Length: 0

but I don't think the example goes well in this section.  Perhaps move
it to its own section between sections 6 and 7?

Dale