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

[Laura Liess <[e-mail]>]

Christer,

Thank you. I will do so.

Laura



2014/1/23 Christer Holmberg <[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]
> *Sent:* ‎Thursday‎, ‎January‎ ‎23‎, ‎2014 ‎1‎:‎42‎ ‎PM
>
> *To:* Hans-Christer Holmberg <[e-mail]>
> *Cc:* [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]>.  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]>
>
>>  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]
>> *Sent:* ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎3‎:‎39‎ ‎PM
>>
>> *To:* Hans-Christer Holmberg <[e-mail]>
>> *Cc:* [e-mail]
>>
>>
>>
>>
>> 2014/1/21 Christer Holmberg <[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]
>>> *Sent:* ‎Tuesday‎, ‎January‎ ‎21‎, ‎2014 ‎3‎:‎30‎ ‎PM
>>> *To:* Hans-Christer Holmberg <[e-mail]>
>>> *Cc:* [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]>
>>>
>>>>  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]
>>>> *Sent:* ‎Tuesday‎, ‎January‎ ‎21‎, ‎2014 ‎12‎:‎54‎ ‎PM
>>>> *To:* Hans-Christer Holmberg <[e-mail]>
>>>> *Cc:* Dale R. Worley <[e-mail]>, [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]>
>>>>
>>>>> 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]
>>>>> https://www.ietf.org/mailman/listinfo/salud
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> salud mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/salud
>>>>
>>>>
>>>
>>
>