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

[Christer Holmberg <[e-mail]>]

Thanks! 😊

Regards,

Christer


Sent from Windows Mail

From: [e-mail]<mailto:[e-mail]>
Sent: ‎Thursday‎, ‎January‎ ‎23‎, ‎2014 ‎9‎:‎20‎ ‎PM
To: Hans-Christer Holmberg<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>

Christer,

Thank you. I will do so.

Laura



2014/1/23 Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Hi Laura,

I think the update section should come AFTER the ‘Requirements Language’ and ‘Terminology’ sections. Otherwise it looks good.

Regards,

Christer

Sent from Windows Mail

From: [e-mail]<mailto:[e-mail]>
Sent: ‎Thursday‎, ‎January‎ ‎23‎, ‎2014 ‎1‎:‎42‎ ‎PM

To: Hans-Christer Holmberg<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>

Hi Christer,

please find below the new text which incorporates, for my understanding the changes around your comments Q1 to Q5. I also attached the intermediary version of the draft incorporating these comments so you can use the rfcdiff tool.

I had a look at the draft recently approved by the IESG (status "publication required") and it seems to me that there are no requirements concerning the structure.

Please let me know if this is OK for you or not.

Thank you
Laura


1.  Introduction

   The Session Initiation Protocol (SIP) [RFC3261] includes a means to
   suggest to a user agent (UA) a particular ringback tone or ring tone
   to be used during session establishment.  In [RFC3261] this is done
   by including a URI in the Alert-Info header field, that specifies the
   tone.  The URI is most commonly the HTTP URL to the audio file.  On
   the receipt of the Alert-Info header field the user agent may fetch
   the referenced ringback tone or ring tone and play it to the user.

   This mechanism hinders interoperability when there is no common
   understanding of the meaning of the referenced tone, which might be
   country- or vendor-specific.  It can lead to problems for the user
   trying to interpret the tone and for the UA wanting to substitute its
   own tone (e.g., in accordance with user preferences) or provide an
   alternative alerting mode (e.g., for hearing-impaired users).  If
   caller and callee are from different countries, the understanding of
   the tones may vary significantly.  Hearing impaired users may not
   sense the specific tone if it is provided as an audio file.  The tone
   per se is also not useful for automata.

   Another limitation of using URLs of audio files is that the
   referenced tones are tied to particular renderings.  It is not
   possible to provide semantic indications or names for rendering
   characteristics that signal the intent and allow the recipient UA to
   decide how to render the received information in an appropriate way.

   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.  For example, consider the PBX
   special ring tone for an external (to the PBX) caller.  Different
   vendors use different approaches such as: Alert-Info:
   <file://ring.pcm>;alert=normal where ring.pcm is a dummy file or:
   Alert-Info: <file://normal.ring.pcm> or: Alert-Info:
   <sip:[e-mail]<mailto:[e-mail]>>.  As a result, the Alert-Info
   header field currently only works when the same vendor provides PBX
   and UA, and only then if the same "fake" proprietary URI convention
   used.

   To solve the described issues, this specification defines the new URN
   namespace "alert" for the Alert-Info header field that allows for
   programmatic user interface adaptation and for conversion of
   equivalent alerting tones in the Public Switched Telephone Network
   (PSTN) when the client is a gateway.  The work to standardize an
   "alert" URN will increase SIP interoperability for this header field
   by replacing proprietary conventions used today.

   Using the "alert" namespace provides syntax for several different



Liess, et al.             Expires July 27, 2014                 [Page 5]


Internet-Draft                 Alert URNs                   January 2014


   application spaces, e. g.:

   o  Names for service indications, such as call waiting or automatic
      callback, not tied to any particular rendering.
   o  Names for common ring tones generated by PBX phones for cases such
      as an internal enterprise caller, external caller, ringback tone
      after a transfer failure or expiration of a hold timer, etc.
   o  Names for country-specific ringback tones.
   o  Names for things with specific renderings that aren't purely
      audio.  They might be static icons, video sequences, text, etc.

   Some advantages of a URN rather than a URL of a downloadable
   resource:

   o  Do not need to download it or deal with security issues associated
      with dereferencing.
   o  No formatting or compatibility issues.
   o  No security risk of rendering something unexpected and
      undesirable.
   o  The tone can be stored locally in whatever format and at whatever
      quality level is appropriate, because it is specified "by name"
      rather than "by value".
   o  It is easier to make policy decisions about whether to use it or
      not.
   o  It facilitates translation for the hearing impaired.

   The downside is that if the recipient does not understand the URN
   then it will only be able to render a default ringback tone or ring
   tone.

   This document creates a new URN namespace and registry for alert
   indications and registers some initial values.

   In practice, this specification extends the usage of the Alert-Info
   header field 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 header field <alert-param>s (which was syntactically
   permitted before, but rarely used).


2.  Update to RFC 3261

2.1.  General

   This specification changes the usage of the Alert-Info header field
   defined in the [RFC3261] by additionally allowing its use in all



Liess, et al.             Expires July 27, 2014                 [Page 6]


Internet-Draft                 Alert URNs                   January 2014


   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 the Alert-Info header field allows the telephony
   practice to be implemented in SIP.

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


3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


4.  Terminology

   This specification uses a number of terms to refer to the roles
   involved in the use of alerting indications in SIP.  A "specifier"
   sends an "alerting indication" (one or more URNs in an Alert-Info
   header field) to a "renderer" which then "renders" a "signal" or
   "rendering" based on the indication to a human user.  A "category" is
   a characteristic whose "values" can be used to classify indications.

   This specification uses the terms "ring tone" and "ringback tone".  A
   "ring tone" or "calling signal" (terminology used in [E182]) is a
   signal generated by the callee's end device, advising the callee
   about an incoming call.  A "ringback tone" or "ringing tone"
   (terminology used in [E182]) is a signal advising the caller that a
   connection has been made and that a ring tone is being rendered to
   the callee.





2014/1/23 Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Hi Laura,

Could you please put the text in an e-mail, how it would look?

Regards,

Christer

Sent from Windows Mail

From: [e-mail]<mailto:[e-mail]>
Sent: ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎3‎:‎39‎ ‎PM

To: Hans-Christer Holmberg<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>




2014/1/21 Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Hi,

In my opinion, the normative update (no matter how is done), should not be in section 1, which is introduction.

It shall of course be mentioned there, but I still think there should be a dedicated “Update to RFC 3261” section.
That is what I intend to do. New Section 2  "Update to RFC 3261", exactly as you proposed with the subsections 2.1 "General"  and 2.2 "New text replacing ....".
My question is about the content of the subsection 2.1 "General". The current section  1.2 contains three paragraphs. I propose to put into 2.1 only the first two paragraphs from the current 1.2 and to move the third paragraph to section 1.1 because this paragraph does not describe an update of the 3261.  Would you agree with this change?

Thank you
Laura


Regards,

Christer

Sent from Windows Mail

From: [e-mail]<mailto:[e-mail]>
Sent: ‎Tuesday‎, ‎January‎ ‎21‎, ‎2014 ‎3‎:‎30‎ ‎PM
To: Hans-Christer Holmberg<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>

Hi Christer,

thank you. What about moving the third paragraph to subsection 1.1?  Could this work for you?

Laura


2014/1/21 Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Hi Laura,

SIPCORE some time ago decided not to use/maintain the header field tables anymore, so that is why I didn't include it in my change suggestion.

But, if you want to also change the table, I won’t object 😊

Regards,

Christer

Sent from Windows Mail

From: [e-mail]<mailto:[e-mail]>
Sent: ‎Tuesday‎, ‎January‎ ‎21‎, ‎2014 ‎12‎:‎54‎ ‎PM
To: Hans-Christer Holmberg<mailto:[e-mail]>
Cc: Dale R. Worley<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>

Christer, Dale,

IMO, the  draft updates the RFC 3261 because it allows the usage of the Alert-Info header field in all provisional responses 1xx except the 100 response. This is described in the first two paragraphs of Section 1.2.  This paragraphs are OK in this section.
The third  paragraph is usefull (it explains what the draft does) but, as Christer remarked,  it does not describe the update of the RFC3261 and so it does not belong to this section.  I would move this paragraph at the end of Section 1.1. What do you think?

Concerning the structure if the Section 1.2,   I will put the text from section 1.2 into a new main Section 2 and structure it as Christer proposes in http://www.ietf.org/mail-archive/web/salud/current/msg00454.html.
But  I think there are two places where we should update the 3261 text:
1) Section 20.4 as proposed by Christer and

2) Table 2: Summary of header fields, A--O on page 161, the " 180" in the row


 Alert-Info             180     ar    -   -   -   o   -   -

   should be changed in "1xx (excepting 100)"

so we probably need two subsections "New text repalcing the text.........of RFC 3261" .
Opinions?

Thank you
Laura



2014/1/20 Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Hi,

>> 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?
>
> The idea is that, while 3261 syntactically and semantically *allows* non-HTTP URIs in Alert-Info, nobody ever used non-HTTP URIs in Alert-Info, and nobody implemented an interpretation of those URIs.
> Thus, even though we are not changing what is officially permitted, implementers will have to change their code because the new *practice* will be an extension of the old practice.  (And both the new practice and the old practice are a small subset of what is permitted by 3261.)

Well, then you should use different wording. Because, the draft does not extend Alert-Info, it simply describes the usage of a new URN in the header field.


>>>> 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.
>
> I guess my point is that the 3261 ABNF already allows all alert URNs to appear in Alert-Info, and there is no need to specify exactly how alert URNs are compatible with the 3261 ABNF.  Anyone who cares exactly how this draft is directly compatible with the ABNF can see that by looking at the ABNF.
>
> Have there been other situations where this sort of syntax explication has been provided?

I don't know - I am just commenting on how I think the draft could from my perspective be improved :)

Regards,

Christer
_______________________________________________
salud mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/salud


_______________________________________________
salud mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/salud