Re: [salud] Christer's review of draft-ietf-salud-alert-info-urns-09

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

> From: Christer Holmberg <[e-mail]>

> Q1:
> -----
> 
> Remove the references from the Abstract.

Yeah, the I-D guidelines (http://www.ietf.org/id-info/guidelines.html)
say that Abstracts should not contain references.

> Q2:
> -----
> 
> There are a number of editorial inconsistences that needs to be fixed.
> 
> E.g. "Alert-Info header field" vs "SIP Alert-Info header field" vs "Alert-Info"
> 
> E.g. "180 (Ringing)" vs "180 Ringing"
> 
> Etc.

I think we want to say consistently "180 (Ringing) response" since
"Ringing" isn't a defining part of the respose code.

> Q3:
> -----
> 
> As the draft updates RFC 3261, I would like to have a section named
> "Update to RFC 3261". Now there are only a few places in the
> introduction talking about the update.

As far as I can find, there are only 10 RFCs that have sections with
this pattern of name.  Most of them invove textual amendments to
previous RFCs.

It seems to me that it is clear to the reader that we are altering
behavior specified in RFC 3261, given that the first sentence of 1.2
is "This specification 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)."

Certainly, you can't implement this draft by amending a device's
behavior only as specified in section 1.2.

> Q4:
> -----
> 
> I am not sure the text in section 1.2 belongs to the
> Introduction. It is basically the "Update to RFC 3261" section I
> mentioned in Q3.

The information in 1.2 is duplicated in the later sections, so it does
follow the rule that the introduction is summarized from the rest of
the text.

> Q5:
> -----
> 
> I am not sure the text in section 1.3 belongs to the
> Introduction. We normally have a separate section.

Roughly 463 RFCs have a "terminology" section.  Of them, about 144
have a terminology section that is a subsection of section 1.  Given
how short our terminology section is, it seems OK to me.

> Q6:
> -----
> 
> Section 1.1 says:
> 
> "In [RFC3261] this is done by including a URI in the Alert-Info
> header field, that specifies the tone."
> 
> Should the text say that the header field includes a REFERENCE to a
> tone? Later in the paragraph, you DO talk about the referenced tone.

It depends on whether we think that all URIs that were envisioned in
RFC 3261 were considered to be themselves "references".  RFC 3261 is
very vague about this.

> Q7:
> ----
> 
> Section 1.1 says:
> 
> "The URI is most commonly the HTTP URL to the audio file."
> 
> s/"the audio file"/"an audio file"

Either form is usable, but I think the second form is better.

> Q8:
> -----
> 
> Section 1.1. says:
> 
> "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."
> 
> The sentence is very confusing. Why not simply say something like:
> 
>  "It is not possible to define semantics associated with a given tone."

The sentence is confusing, but you haven't captured the meaning we
want (perhaps because we confused you!).  What we are concerned about
the "specifier" can't state what the semantics of the tone are and let
the renderer choose the appropriate tone.

How about:

 "There is no method to signal the semantic intention of the tone
  (without signaling a specific tone) and allowing the recipient UA
  to decide what tone to use to signal the intention.  Similarly,
  there is no method to signal particular rendering features (such as
  short duration, delay, or country-specific conventions) without
  signaling a specific tone."

> Q9:
> -----
> 
> Section 4 defines the ABNF for the URN, but [there] is no text on how to
> "map" it into the Alert-Info header field ABNF:
> 
> For example, I assume that the URN is encoded using the opaque-part
> format of the absoluteURI, and that the scheme value is "urn". I
> think it would be good to indicate that.

Actually, we're depending on the fact (unstated in RFC 3261) that any
"absolute" URI (per RFC 3986) is allowed as a header field value in
Alert-Info, and that the URNs we are defining conform to the absolute
URI syntax.  If the syntax for <absoluteURI> in RFC 3261 didn't allow
all absolute URIs, we'd have to amend RFC 3261.

Dale