[salud] Review of draft-ietf-salud-alert-info-urns-09

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

(as an individual)

I think the following uses of "must" should be turned into "MUST":

- 4.  URN Specification for the "alert"  namespace identifier

   Process for identifier resolution:  The process of identifier
      resolution is the process by which a rendering device chooses a
      rendering to represent a sequence of "alert" URNs.  The device is
      allowed great leeway in making this choice, but the process must
------------------------------------------------------------------^^^^
      obey the rules of Section 8.1.  The device is expected to
      provide

I think this requirement is sufficiently important we should impress
implementors that it is a requirement.

      Future standardization may allow <alert-label>s
      that are A-labels, and so interpreters of "alert" URNs must
-------------------------------------------------------------^^^^
      operate correctly when given such URNs as input.

Similarly, I think we want to use "MUST" here.

The remaining items are editorial.

- Requirements Language

We may want to put this section further down in the document than it
is now.  Current RFCs seem to always make "Requirements Language" be a
numbered section.

- Table of Contents

Capitalization of section names is not consistent.  E.g.,

     3.2.  Service Tones  . . . . . . . . . . . . . . . . . . . . . . 10
     3.3.  Country-specific ringback tone indications for the
           public telephone network . . . . . . . . . . . . . . . . . 11
   4.  URN Specification for the "alert"  namespace identifier  . . . 12
   5.  "Alert" URN Values Definitions . . . . . . . . . . . . . . . . 18

Current usage seems to be "capitalize all important words" (as in the
above entries for sections 3.2 and 5).  I expect that the RFC Editor
can/will make this change, so we don't have to go through the effort
to edit our draft for it.

     3.1.  PBX Ring Tones . . . . . . . . . . . . . . . . . . . . . . 9
       3.1.1.  normal . . . . . . . . . . . . . . . . . . . . . . . . 9
       3.1.2.  external . . . . . . . . . . . . . . . . . . . . . . . 10
       3.1.3.  internal . . . . . . . . . . . . . . . . . . . . . . . 10

Since "normal", "external", etc. are not (at this point in the text)
keywords, I think they should be capitalized as normal English titles.

   5.  "Alert" URN Values Definitions . . . . . . . . . . . . . . . . 18
     5.1.  <Alert-category> Values Definitions  . . . . . . . . . . . 18
     5.2.  <Alert-indication>  Values Definitions . . . . . . . . . . 18

It is not clear to me whether "Alert" should be capitalized in these
titles or not (as they are to some degree keywords and not English
text).  We should ask the RFC Editor about this.

- 1.1.  Motivation

   There are currently interoperability issues around the use of the
   Alert-Info header field when not using an external ring file.

A better introductory sentence would start the paragraph by explaining
that it deals with artificial URIs:

   The issues with URLs that reference audio files can be avoided by
   using fixed URLs with specific meanings.  However this approach has
   its own interoperability issues.


   As a result, Alert-Info currently
   only works when the same vendor provides PBX and UA, as only then if
--------------------------------------------------------^^
"as" should be "and"
   the same "fake" proprietary URI convention used.


   Another limitation of the current solution is that the referenced
   tones are tied to particular rendering.  It is not possible to
   provide semantic indications or names for rendering characteristics
   that signals the intent and allows the recipient UA to decide how
   to
   render the received information in an appropriate way.

This paragraph does not make much sense in the context of the
paragraph immediately before it (that is, the use of fake URLs that
have semantic meanings).  Instead, it should be moved upward one
paragraph, and the first sentence adjusted:

   Another limitation of using URLs of audio files is that the
   referenced tones are tied to particular renderings. ...

- 1.2.  Alert-Info Header Field Usage Change

   devices should not malfunction upon receiving multiple Alert-Info
   alert-params

I suppose we should add <...>:

   devices should not malfunction upon receiving multiple Alert-Info
   <alert-param>s

- 2.  Requirements

   REQ-21: The mechanism must provide a simple way to combine two
   alerting indications to produce an alerting indication that
   requests

I think we mean "two *or more* alerting indications" here:

   REQ-21: The mechanism must provide a simple way to combine two or
   more
   alerting indications to produce an alerting indication that
   requests

- 3.2.1.  call-waiting

   As call-waiting information may be subject to the callee's
   privacy concerns, the exposure of this information shall be done only
-------------------^
   if explicitly required by the callee.

The "," should be ";", because the two parts that it separates are
each a complete sentence.

- 3.2.3.  transfer-recall

   This service tone is used to distinguish this INVITE from any other
   normal incoming call.

I believe this should be "from a normal incoming call", since the use
of "any other normal incoming call" suggests that the transfer-recall
call is itself a "normal incoming call", which it is not (in the
context of this paragraph).

- 3.2.4.  auto-callback

   When the user is available,
   the server calls back the user and utilizes this service tone to
   distinguish this from any other normal incoming call.

Similarly, I believe this should be "from a normal incoming call".

- 3.2.5.  hold-recall

   This service
   tone is used to distinguish this case from any other normal incoming
   call.

Similarly, I believe this should be "from a normal incoming call".

- 4.  URN Specification for the "alert"  namespace identifier

      The following <alert-category> identifiers defined in [RFCXXXX]:
------------------------------------------------^

"are" should be inserted here.

      Any "alert" URN defined in this specification is syntactically
      valid for ring and ringback tones and can be used in INVITE
----------------------------------------------------------^
      requests or in provisional 1xx responses excepting the 100
      response.

We should probably insert "SIP" here, or even "Session Initiation
Protocol", because the NID registration does not otherwise tell what
protocol defines the "INVITE request", and the NID registration might
be read outside of the context of the entire RFC.

      <alert-label>s MUST comply with the syntax for Non Reserved LDH-
      labels [RFC5890]. <domain-label>s MUST comply with the syntax for
      Non Reserved LDH-labels or the syntax for A-labels [RFC5890].
      Registered URNs and components thereof MUST be transmitted as
      registered (including case).  A new URN MUST NOT be registered if
      it is equal by the comparison rules to an already registered
      URN.

It may be desirable to move this paragraph below the ABNF, because
<alert-label> and <domain-label> are not referenced previously.  This
paragraph is a set of further restrictions on the ABNF, rather than an
introduction to the ABNF.

I believe that the last sentence, "A new URN MUST NOT..." does not
belong in this paragraph.  It probably should be inserted as a new
second paragraph of "Process of identifier assignment".

      (An <alert-category> considered alone has no meaning.)

I believe that this sentence should end "has no meaning in this
sense." because an <alert-category> does have a meaning (the aspect of
the signal that its values describe), but in this paragraph, we use
the word "meaning" in a very specific way (the selection of a subset
of dialogs is selected from a larger set of dialogs), and it is that
specific meaning that an <alert-category> does not possess.

      Private extensions are "alert" URNs that include <alert-ind-part>s
      that are <private-name>s and <alert-label>s that appear after a
      <private-name>s (either as an <alert-category> or an <alert-
      indication>).  If such an <alert-ind-part> is a <private-name>,
      its meaning is defined by the organization that owns the
      <provider> that appears in the <private-name>.  If the <alert-ind-
      part> is an <alert-label>, its meaning is defined by the
      organization that owns the <provider> that appears in the closest
      private-name> preceeding the <alert-label>.  The rules for
------^
      determining the organization that owns a <provider> are given in
      Section 7.2.

A "<" should be inserted here.

- 5.1.  <Alert-category> Values Definitions

   Following <alert-category> values are defined in this document:
---^

This should be "The following..."

- 6.1.  Registry

   <alert-category> and <alert-identifier> values which contain
   <private-name>s are not managed by IANA.  The process of identifier
---------------------------------------------^^^
   assignement is described in Section 4.

I think we want this sentence to be "The process of assigning these
values is described in Section 4." because we generally don't use the
word "identifier" elsewhere (except as part of <alert-identifier> and
"namespace identifier").

I think we want to add to this section a repetition of the rule "A new
URN MUST NOT be registered if it is equal by the comparison rules to
an already registered URN." because this is the text that the IANA
will probably refer to when processing registrations.  To do so, I
would add as a new third paragraph:

   A new URN MUST NOT be registered if it is equal by the comparison
   rules (viz., case-insensitive string comparison) to an already
   registered URN.

- 7.1.  General Extension Rules

   The process for defining new standard "alert" URNs is described in
   Section 6.1.  Currently, all such definitions require Standards
   Action.  The process for defining new "alert" URNs via the private
   extension mechanism is described in Section 7.2 is Standards
   Action.

The last sentence of this paragraph is syntactically incorrect.  I
believe that the words "is Standards Action" at the very end should be
deleted.

   Creating private extension "alert" URNs is not a standards action
   and
   they are not registered with IANA.

   Adding new categories and adding <alert-indication> values via the
   "private extension" mechanism is not a standards action.

I think that the two sentences are redundant, and we can delete the
second one.

- 9.1.   Algorithm Description

   Each URN excludes some signals from the
   set, and *sorts* the signals that remain in the set according to how
------------^^^^^^^
   well they represent the URN.

I am not sure, but I think we want to say "sorts" rather than
"*sorts*" here.

   This final sort places the least specific signals
   (within their tied groups) *first*.
------------------------------^^^^^^^

Similarly, I think this should be "first".

- 9.2.4.  Example 4

   So we choose the signal "internal".

I think this explanation should be amplified:

   So we choose the signal "internal".  Note that
   <urn:alert:priority:low> could not be given effect because it
   followed <urn:alert:source:internal>.  If the two URNs had appeared
   in the reverse order, the signal "low" would have been chosen,
   because <urn:alert:priority:low> would have been given precedence.

- 12.  Internationalization Considerations

   The URNs <urn:alert:locale:country:<ISO 3166-1 country code>>
   select
--------------------------------------------------------------^^
   renderings that are conventional in the specified country.

There is an extra ">" here.

Dale