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

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jan 2014 12:04:40 +0000

Hi,

I have now read the draft. In general I am ok with it. There is text which is not wrong, but which I think could be simplified, but I will not focus on that.

Some comments below.

Q1:
-----

Remove the references from the Abstract.

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.

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.

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.

Q5:
-----

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

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.

Q7:
----

Section 1.1 says:

"The URI is most commonly the HTTP URL to the audio file."

s/"the audio file"/"an audio file"

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

Q9:
-----

Section 4 defines the ABNF for the URN, but the 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 sceme value is "urn". I think it would be good to indicate that.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 7 Jan 2014 16:31:26 -0500 (EST)

> From: Christer Holmberg <[email-masked]>

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

> E.g. "180 (Ringing)" vs "180 Ringing"

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.

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jan 2014 18:02:46 -0500

>    signaling a specific tone."

I don't think that quite gets it either, because it implies that the 
semantics need to be indicated using a tone. Part of the point is that 
the indication might use other modalities.

How about:

  "There is no method to signal the semantic intention of the alert
   and allowing the recipient UA form of alert indication (such as
   a particular tone, vibration, or visual display) 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)."

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Jan 2014 08:44:49 +0000

Hi Dale,

Comments inline.

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

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Jan 2014 08:46:28 +0000

Hi,

The text suggested by Paul looks ok to me.

Regards,

Christer

-----Original Message-----
From: salud [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 8. tammikuuta 2014 1:03
To: [email-masked]
Subject: Re: [salud] Christer's review of draft-ietf-salud-alert-info-urns-09

>    signaling a specific tone."

I don't think that quite gets it either, because it implies that the semantics need to be indicated using a tone. Part of the point is that the indication might use other modalities.

How about:

	Thanks,
	Paul

_______________________________________________
salud mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/salud

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Jan 2014 10:43:11 -0500

> The text suggested by Paul looks ok to me.

I'm looking at my own text again, and thinking it needs a little more 

>     rendering features (such as short duration, delay, or country-

Another try:

   "There is no method to signal the semantic intention of the alert
    while enabling the recipient UA to choose the specific alert
    indication (such as a particular tone, vibration, or visual display)
    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)."

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 16 Jan 2014 16:07:10 -0500 (EST)

[as an individual]

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

Different people have different opinions.  I dislike the "textual
edit" method of updating an RFC; I find it harder to understand the
significance of change that is expressed textually than an update that
states the update in "semantic" terms.

>    cause the use of a new class of URIs and the use of multiple URIs."

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

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

It's a valid point, and fortunately, I can revise my statistics
easily:  In the RFCs 6001 (2010 Oct) to 6998 (2013 Aug), 114 RFCs have
a "terminology" section, and of them, 42 have the section in section
1.  Of a randomly selected subset of 9 RFCs with a terminology section
in section 1, in roughly half (4) the only terminology defined was the
RFC 2119 keywords.  So we can crudely estimate that 18% of "recent"
RFCs have non-trivial terminology sections as subsections of section
1.

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

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?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jan 2014 18:24:45 -0500

ISTM the main thing is that 3261 allows URNs in Alert-Info 
*syntactically*, but does not specify any semantics for them.
This draft defines semantics for a certain subset of URNs.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Jan 2014 07:19:55 +0000

Hi,

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

---

From: Laura Liess <[email-masked]>
Date: Tue, 21 Jan 2014 11:54:32 +0100

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 <[email-masked]>

> non-HTTP URIs in Alert-Info, nobody ever used non-HTTP URIs in Alert-Info,
> and nobody implemented an interpretation of those URIs.
> 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:
> >>>> -----
> >>>>
> > 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.
> >

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Jan 2014 11:29:12 +0000

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: [email-masked]<mailto:[email-masked]>
Sent: ‎Tuesday‎, ‎January‎ ‎21‎, ‎2014 ‎12‎:‎54‎ ‎PM
To: Hans-Christer Holmberg<mailto:[email-masked]>
Cc: Dale R. Worley<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

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

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

Thank you
Laura

2014/1/20 Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Hi,

Regards,

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

---

From: Laura Liess <[email-masked]>
Date: Tue, 21 Jan 2014 14:30:17 +0100

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 <[email-masked]>

>  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.
>
>   *From:* [email-masked]
> *Sent:* ‎Tuesday‎, ‎January‎ ‎21‎, ‎2014 ‎12‎:‎54‎ ‎PM
> *To:* Hans-Christer Holmberg <[email-masked]>
> *Cc:* Dale R. Worley <[email-masked]>, [email-masked]
>
>   Christer, Dale,
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Jan 2014 14:12:19 +0000

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.

Regards,

Christer

Sent from Windows Mail

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

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 <[email-masked]<mailto:[email-masked]>>
Hi Laura,

Regards,

Christer

Sent from Windows Mail

Christer, Dale,

Thank you
Laura

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 21 Jan 2014 14:13:39 +0000

The agreement we made is that we should not use the tables, but also that the main text should accurately specify the requirements for which methods are allowed to include header fields or not, preferably in a generic way that accommodates new methods. So text that states "all requests", "all requests initiating a new dialog" and so on.

Even on an update, it may be preferable to specify it this way.

regards

Keith

________________________________
From: salud [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 21 January 2014 11:29
To: [email-masked]
Cc: [email-masked]
Subject: Re: [salud] Christer's review of draft-ietf-salud-alert-info-urns-09

Hi Laura,

Regards,

Christer

Sent from Windows Mail

Christer, Dale,

Thank you
Laura

Regards,

Christer

---

From: Laura Liess <[email-masked]>
Date: Wed, 22 Jan 2014 14:39:36 +0100

>  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,
> *Sent:* ‎Tuesday‎, ‎January‎ ‎21‎, ‎2014 ‎3‎:‎30‎ ‎PM
> *Cc:* [email-masked]
>>>  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:
>>> >>>> -----
>>> >>>>
>>> to appear in Alert-Info, and there is no need to specify exactly how alert

---

From: Laura Liess <[email-masked]>
Date: Wed, 22 Jan 2014 15:06:41 +0100

Keith,

Christer proposed the folowing text:
   " 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."

I am fine with it but it seems to me that it does not meet your
requirements. Would you like some modification to it and if yes could you
make a proposal how to modify it?

Thank you
Laura

2014/1/21 DRAGE, Keith (Keith) <[email-masked]>

>  The agreement we made is that we should not use the tables, but also
> that the main text should accurately specify the requirements for which
> methods are allowed to include header fields or not, preferably in a
> generic way that accommodates new methods. So text that states "all
> requests", "all requests initiating a new dialog" and so on.
>
>  ------------------------------
> *From:* salud [mailto:[email-masked]] * On Behalf Of *Christer
> Holmberg
> *Sent:* 21 January 2014 11:29
> *To:* [email-masked]
> *Cc:* [email-masked]
>
> *Subject:* Re: [salud] Christer's review of
> draft-ietf-salud-alert-info-urns-09
>
>   Hi Laura,
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Jan 2014 02:06:01 +0000

Hi Laura,

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

Regards,

Christer

Sent from Windows Mail

From: [email-masked]<mailto:[email-masked]>
Sent: ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎3‎:‎39‎ ‎PM
To: Hans-Christer Holmberg<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

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

Hi Christer,

Laura

Regards,

Christer

Sent from Windows Mail

Christer, Dale,

Thank you
Laura

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 22 Jan 2014 21:31:29 -0500 (EST)

> > 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.)
> 
> not extend Alert-Info, it simply describes the usage of a new URN in
> the header field.

That's what the phrase "in practice" is indicates -- although using
such a URN was allowed in Alert-Info in principle, the meaning of such
usae was not defined, and no device actually used such a URN.  With
this RFC, the situation is changed, the usage is extended in practice.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Jan 2014 08:28:22 +0000

Hi,

> this RFC, the situation is changed, the usage is extended in practice.

You can say that, in practice the Alert-Info header field has been used with HTTP URIs, but I don’t like talking about extending the header field, because that is not what you are doing.

Regards,

Christer

---

From: Laura Liess <[email-masked]>
Date: Thu, 23 Jan 2014 15:23:05 +0100

Hi,

Thank you for the comments.
Please find inline the
changes I intend to do in version -11   based on your comments and the
corresponding discussion and also my personal opinion. Please let me know
if I mised something or if for some reason you  don't agree.

> Remove the references from the Abstract.

[LL] Done in  version-10.

> E.g. “Alert-Info header field” vs “SIP Alert-Info header field” vs
> “Alert-Info”
>

[LL]  OK. Change  “SIP Alert-Info header field” and “Alert-Info” to
“Alert-Info header field”

>
>
> E.g. “180 (Ringing)” vs “180 Ringing”
>
[LL] OK. Change  “180 Ringing” to “180 (Ringing)”

> “Update to RFC 3261”. Now there are only a few places in the introduction
> talking about the update.
>

[LL]  See the a separate discussion on this issue.

>
>
>
> 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.
>
>
>
[LL] OK. Separate main section.

> normally have a separate section.
[LL] OK. Separate main section.

>
>
>
>
> 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.
>
>
>
[LL] Would you agree with the text   “In [RFC3261] this is done by
including a URI in the Alert-Info header field, that specifies a Reference
to the tone.”  ?

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

[LL] Agree.

>
>
>
>
> Q8:
>
> -----
>
>
>
> Section 1.1. says:
>
>
>
> “It is not possible to provide semantic indications or names for rendering
> characteristics
>
> information in an appropriate way.”
>
>
>
>                 “It is not possible to define semantics associated with a
> given tone.”
>
>

[LL] OK. I will replace the text with the text provided by Paul in
http://www.ietf.org/mail-archive/web/salud/current/msg00456.html.

>
>
>
> Q9:
>
> -----
>
>
>
> Section 4 defines the ABNF for the URN, but the 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 sceme value is “urn”. I think it would be
> good to indicate that.
>

[LL]  My understanding is that we don't have consensus that  the current
text must be changed. I would leave the text as it is.

Thank you
Laura

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Jan 2014 16:13:56 +0000

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: [email-masked]<mailto:[email-masked]>
Sent: ‎Thursday‎, ‎January‎ ‎23‎, ‎2014 ‎1‎:‎42‎ ‎PM
To: Hans-Christer Holmberg<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

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:[email-masked]<mailto:[email-masked]>>.  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 <[email-masked]<mailto:[email-masked]>>
Hi Laura,

Regards,

Christer

Sent from Windows Mail

Thank you
Laura

Regards,

Christer

Sent from Windows Mail

Hi Christer,

Laura

Regards,

Christer

Sent from Windows Mail

Christer, Dale,

Thank you
Laura

Regards,

Christer

---

From: Laura Liess <[email-masked]>
Date: Thu, 23 Jan 2014 20:20:10 +0100

Christer,

Thank you. I will do so.

Laura

2014/1/23 Christer Holmberg <[email-masked]>

>  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
>
> *Sent:* ‎Thursday‎, ‎January‎ ‎23‎, ‎2014 ‎1‎:‎42‎ ‎PM
>
>  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.
>
>    <sip:[email-masked]>.  As a result, the Alert-Info
> 2014/1/23 Christer Holmberg <[email-masked]>
>
>>  Hi Laura,
>>
>> *Sent:* ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎3‎:‎39‎ ‎PM
>>
>>>  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.
>>>
>>>> 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.
>>>>> value

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Jan 2014 23:30:34 +0000

Thanks! 😊

Regards,

Christer

Sent from Windows Mail

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

Christer,

Thank you. I will do so.

Laura

Regards,

Christer

Sent from Windows Mail

Hi Christer,

Thank you
Laura

1.  Introduction

2.  Update to RFC 3261

2.1.  General

3.  Requirements Language

4.  Terminology

Regards,

Christer

Sent from Windows Mail

Thank you
Laura

Regards,

Christer

Sent from Windows Mail

Hi Christer,

Laura

Regards,

Christer

Sent from Windows Mail

Christer, Dale,

Thank you
Laura

Regards,

Christer

---

From: Laura Liess <[email-masked]>
Date: Fri, 24 Jan 2014 14:08:13 +0100

Hi Christer,

Could you have a loook at my answers to your comments Q6 to Q9?  If you
agree to them, I could publish the version -11 of the draft whch we could
send then to the IESG.

[LL] Agree.

Thank you
Laura

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2014 14:42:56 +0000

Hi Laura,

I am ok with your answers. Go ahead and submit :)

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Laura Liess <[email-masked]> wrote:

Hi Christer,

Could you have a loook at my answers to your comments Q6 to Q9?  If you agree to them, I could publish the version -11 of the draft whch we could send then to the IESG.

Q6:
-----

Section 1.1 says:

“In [RFC3261] this is done by including a URI in the Alert-Info header field, that specifies the tone.”

[LL] Would you agree with the text   “In [RFC3261] this is done by including a URI in the Alert-Info header field, that specifies a Reference to the tone.”  ?

Q7:
----

Section 1.1 says:

[LL] Agree.

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

                “It is not possible to define semantics associated with a given tone.”

[LL] OK. I will replace the text with the text provided by Paul in http://www.ietf.org/mail-archive/web/salud/current/msg00456.html.

Q9:
-----

Section 4 defines the ABNF for the URN, but the 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 sceme value is “urn”. I think it would be good to indicate that.

[LL]  My understanding is that we don't have consensus that  the current text must be changed. I would leave the text as it is.

Thank you
Laura

Regards,

Christer