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

[Christer Holmberg <[e-mail]>]

Hi Dale,

Comments inline.

>> 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)."

Having that sentence in the Introduction (and the Abstract) is fine.

But, in my opinion the draft shall explicitly update the first paragraph in section 20.4 of RFC 3261 (see below):

"X. Update to RFC 3261

X.2.  General

   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).

   Previously, the Alert-Info header field was only permitted in 180
   (Ringing) responses.  But in telephony, other situations indicated by
   SIP provisional responses, such as 181 (Call Is Being Forwarded) and
   182 (Call Is Being Queued), are often indicated by tones.  Extending
   the applicability of Alert-Info allows the telephony practice to be
   implemented in SIP.

   In practice, this specification extends Alert-Info in that it will
   cause the use of a new class of URIs and the use of multiple URIs.

   Backward compatibility issues are not expected, as devices that do
   not understand an "alert" URN should ignore it, and devices should
   not malfunction upon receiving multiple Alert-Info alert-params
   (which was syntactically permitted before, but rarely used).

X.2.  New text replacing the text of the 1st paragraph of section 20.4 of
      RFC 3261

   When present in an INVITE request, the Alert-Info header field
   specifies an alternative ring tone to the UAS.  When present in a non-100 provisional 
   response, the Alert-Info header field specifies an alternative ringback tone to 
   the UAC.  A typical usage is for a proxy to insert this header field to provide a 
   distinctive ring feature."


The structure above is exactly how I am updating a section in another RFC, in a draft which is currently in IESG review :)

BTW, the following sentence is unclear to me:

   "In practice, this specification extends Alert-Info in that it will
   cause the use of a new class of URIs and the use of multiple URIs."

What does it mean? 






>> 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.

If you are going to count RFCs, you should also look when they have been published. We live and learn, and hopefully our RFC get more clear and readable by time :)

Anyway, I will not spend time arguing about it. It was only an editorial comment :)




>> 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.

I am looking for consistency, as "referenced tone" is used in other places of the section. 

If we do NOT consider them to be "references", we need to modify the section.




>> Q8:
>> -----

I will provide my input as a reply to Paul's e-mail.


>> 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.

There are two different "structures" for absolute URI, and the URNs only fit into the opaque-part structure.

In addition, as the URI requires a scheme value, I think we should explicitly say what it is.


Regards,

Christer