Subject: [salud] Review comments on draft-ietf-salud-alert-info-urns-13

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Sep 2014 08:00:33 +0000

Hi,

I have reviewed the latest version of the alert-urn draft. In general it looks ok, but I have a few comments (of which one is pure editorial) that I request the authors to address.

General:
-----------

<QG_1>

As it is now allowed to use the Alert-Info header field in any non-100 provisional response, I assume the value could actually change from one
response to another.

Eventhough RFC3261 does not explicitly forbid it, perhaps it would be good to explicitly mention that in this draft, because I assume there could be use cases where
e.g. one value is received in a 181, and another value in a subsequent 180.

</QG_1>

Section 4.1:
---------------

<Q4-1_1>

                This is pure editorial, but for alignment purpose I suggest to change "in all provisional responses..." to "in any non-100 provisional response..."

</Q4-1_1>

Section 4.2:
---------------

<Q4-2_1>

This section is below the "Updates to RFC 3261" section, but it is unclear exactly what is updated.

The first paragraph of section 20.4/RFC 3261 already says that a proxy can insert a A-I header. If you want to explicitly say
that a proxy can also modify an existing header, shouldn't that be text that you add to e.g. the same paragraph?

</Q4-2_1>

Regards,

Christer

---

From: Laura Liess <[email-masked]>
Date: Tue, 9 Sep 2014 15:23:24 +0200

Hi Christer,

Thank you very much for the comments.

Please find below the text changes according to your comments Q4-1_1
and Q4-2_1.
Is the text OK for you?

I am not sure what we should do concerning the comment QG_1.  IMO, usually
RFCs do not mention all possible scenarios or use cases which may occur.
The content of an Alert-Info applies just to the message, there is no text
saying in any way that the content of the Alert-Info applies to a dialog or
transaction.
Additionaly, if we add text and mention these use cases, I think people
will ask for concrete examples, then for message flows and so on, so that
finishing the draft will take another year...
There is also nothing we can do here for a UA receiving different
Alert-Info in two non-100 provisional reasponses, we have no rules on how
the UA has to handle them, this is implementation dependent anyway.
So, my personal opinion is to leave this out.

Thank you
Laura

>
> General:
>
> -----------
>
>
>
> <QG_1>
>
>
>
> As it is now allowed to use the Alert-Info header field in any non-100
> provisional response, I assume the value could actually change from one
>
> response to another.
>
>
>
> Eventhough RFC3261 does not explicitly forbid it, perhaps it would be good
> to explicitly mention that in this draft, because I assume there could be
> use cases where
>

>
>
> Section 4.1:
>
> ---------------
>
>
>
> <Q4-1_1>
>
>
>
>                 This is pure editorial, but for alignment purpose I
> suggest to change "in all provisional responses..." to "in any non-100
> provisional response..."
>
>
>
> </Q4-1_1>
>
>
>
>
>
> Section 4.2:
>
> ---------------
>
>
>
> <Q4-2_1>
>
>
>
> The first paragraph of section 20.4/RFC 3261 already says that a proxy can
> insert a A-I header. If you want to explicitly say
>
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Sep 2014 17:44:50 +0000

Hi Laura,

>Please find below the text changes according to your comments Q4-1_1  and Q4-2_1.  Is the text OK for you?

I don't find any text :)

> I am not sure what we should do concerning the comment QG_1.  IMO, usually RFCs do not mention all possible scenarios or use cases which may occur. The content of an Alert-Info
> applies just to the message, there is no text saying in any way that the content of the Alert-Info applies to a dialog or transaction.
> Additionaly, if we add text and mention these use cases, I think people will ask for concrete examples, then for message flows and so on, so that finishing the draft will take another year...
> There is also nothing we can do here for a UA receiving different Alert-Info in two non-100 provisional reasponses, we have no rules on how the UA has to handle them, this is implementation dependent anyway.

I think a simple note, saying that depending on the use-case/service, subsequent non-100 provisional responses might contain different values. Otherwise I am pretty sure that people, sooner or later, will argue whether it is allowed or not...

Regards,

Christer

General:
-----------

<QG_1>

</QG_1>

Section 4.1:
---------------

<Q4-1_1>

                This is pure editorial, but for alignment purpose I suggest to change “in all provisional responses…” to “in any non-100 provisional response…”

</Q4-1_1>

Section 4.2:
---------------

<Q4-2_1>

This section is below the “Updates to RFC 3261” section, but it is unclear exactly what is updated.

The first paragraph of section 20.4/RFC 3261 already says that a proxy can insert a A-I header. If you want to explicitly say
that a proxy can also modify an existing header, shouldn’t that be text that you add to e.g. the same paragraph?

</Q4-2_1>

Regards,

Christer

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

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 9 Sep 2014 16:32:38 -0400

Many thanks for your review!

My apologies for not tending to this earlier.

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

> <QG_1>
> 
> As it is now allowed to use the Alert-Info header field in any
> non-100 provisional response, I assume the value could actually
> change from one response to another.
> 
> Even though RFC3261 does not explicitly forbid it, perhaps it would
> be good to explicitly mention that in this draft, because I assume
> there could be use cases where e.g. one value is received in a 181,
> and another value in a subsequent 180.

I can easily see use cases where different values are received in
different provisional responses, even when they come from (or on
behalf of) the same UAS.  For instance, a 181 (Ringing) with one alert
signal may be followed by 181 (Call Is Being Forwarded) with an alert
signal specifying call forwarding.

As you say, this is allowed already.  But since Alert-Info hasn't been
*used* before, people might overlook this possibility.

It seems to me that the best place to insert this would be at the end
of section 13, where we are stating the rules for UAs regarding
rendering Alert-Info.  We could add a paragraph at the end:

    Different provisional responses (even within one early dialog) may
    have different Alert-Info header field values.  Each Alert-Info header
    field value specifies a rendering independently of all other
    provisional responses.  The User Agent must choose among or combine
    these renderings.  It SHOULD prefer renderings derived from
    provisional responses that are received later in time over those that
    are received earlier.

> Section 4.1:
> ---------------
> 
> <Q4-1_1>
> 
> This is pure editorial, but for alignment purpose I suggest to
> change "in all provisional responses..." to "in any non-100
> provisional response..."

I believe the text you are referring to is:

   It changes the usage of the Alert-Info header field defined in RFC
   3261 by additionally allowing its use in all provisional responses
   to INVITE (except the 100 response).

I think you mean to revise it to:

   It changes the usage of the Alert-Info header field defined in RFC
   3261 by additionally allowing its use in all non-100 provisional
   responses to INVITE.

I agree that the latter reads better.

> The first paragraph of section 20.4/RFC 3261 already says that a
> proxy can insert a A-I header. If you want to explicitly say that a
> proxy can also modify an existing header, shouldn't that be text
> that you add to e.g. the same paragraph?

The problem is that it is actually a modification to the rules
governing proxies, forwarding requests (section 16.6 item 1) and
forwarding responses (section 16.7 item 9), both of which forbid
*removing* header field values (except Via in responses).

The text of 20.4 allows a proxy to *insert* Alert-Info.  That can be
done already in requests but needs special permission in responses.
But removing header fields is specifically forbidden in 16.6 and 16.7.
So we're being more aggressive than what 20.4 already is doing.

Given how long and complicated those sections are, it's rather awkward
to edit the change into those sections textually.

But I can see the value of pointing out what specifically is changed.
Perhaps this would suffice?  (I am also including the wording change
you suggest in the second item, because it seems to apply to this item
as well.)

   4.2.  Proxies May Alter Alert-Info Header Fields

   Sections 16.6 and 16.7 are modified so that when forwarding a SIP
   request or a non-100 provisional 1xx response, a SIP proxy MAY add
   or remove header field values in an Alert-Info header field.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Sep 2014 21:33:29 +0000

Hi,

>    provisional responses that are received later in time over those that

I was actually assuming that, when you receive a new Alert-Info, you would "disable" whatever rendering the previous triggered.

For example, if I receive a 181 with a call-forwarding-urn, and later a 180 with a called-party-alerting-urn, why would I keep rendering the call-fowarding-urn?

If you say "choose among or combine", how do you know that the UA will behave as you expect? We would need to define how different urns interact with each other, and I don't think we want to go down that path...

>   3261 by additionally allowing its use in all non-100 provisional

Correct.

> *removing* header field values (except Via in responses).

I hear what you are saying.

However, I think we have already broken those rules in the past. For example, RFC 3325 specifies that a proxy can remove a P-Preferred-Identity header field, and that RFC does not update RFC 3261.

Also, RFC 3329 specifies that a proxy can remove the Require and Proxy-Require header field, after it has removed the security option-tags, and there are no option-tags left.

So, while the fact that we have done something in the past doesn't automatically justify us to do it again, I just wonder whether it would be the end of the world?

>   or remove header field values in an Alert-Info header field.

Don't you mean "add or remove an Alert-Info header field"?

Also, I think you could remove "1xx", and say "non-100 provisional response".

I don't have any strong preference, as long as it is clear what we update. But, perhaps we should ask the SIPCORE folks (that's mostly us :) whether we really would need to go down the path and update sections 16.6 and 16.7, or whether we e.g. in section 20.4 could simply say that a proxy can remove the header field.

Regards,

Christer

---

From: Laura Liess <[email-masked]>
Date: Wed, 10 Sep 2014 15:00:30 +0200

Hi Christer,

      > I don't find any text :)

Sorry for that. I just forgot to insert the text I put into the next draft
version.

For Q4-1_1:

New text for the first paragraph of section 4.1:

"This specification changes the usage of the Alert-Info header field    defined
in [RFC3261] by additionally allowing its use in any non-100    provisional
response to INVITE."

For Q4-2_1:

New text for the first paragraph of section 4.1:

"Following text is added after the first paragraph of section 20.4
[RFC3261]:

A SIP proxy MAY add or remove header field values in an Alert-Info    header
field in a SIP request or in any non-100 provisional response."

Thank you

Laura

2014-09-09 19:44 GMT+02:00 Christer Holmberg <[email-masked]
>:

>  > I am not sure what we should do concerning the comment QG_1.  IMO,
> usually RFCs do not mention all possible scenarios or use cases which may
> occur. The content of an Alert-Info
>  > applies just to the message, there is no text saying in any way that
> the content of the Alert-Info applies to a dialog or transaction.
> I think a simple note, saying that depending on the
> use-case/service, subsequent non-100 provisional responses might contain
> different values. Otherwise I am pretty sure that people, sooner or later,
> will argue whether it is allowed or not...
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>>
>> General:
>>
>> -----------
>>
>>
>>
>> <QG_1>
>>
>>
>>
>> Eventhough RFC3261 does not explicitly forbid it, perhaps it would be
>> good to explicitly mention that in this draft, because I assume there could
>> be use cases where
>>
>> The first paragraph of section 20.4/RFC 3261 already says that a proxy
>> can insert a A-I header. If you want to explicitly say
>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Sep 2014 14:05:28 +0000

Hi Laura,

Regarding Q4-2_1, we need to say that proxies can remove the whole header field, not only header field values.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Laura Liess<mailto:[email-masked]>
Sent: ‎10/‎09/‎2014 16:00
To: Christer Holmberg<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13

Hi Christer,

      > I don't find any text :)

Sorry for that. I just forgot to insert the text I put into the next draft version.
For Q4-1_1:

"This specification changes the usage of the Alert-Info header field    defined in [RFC3261] by additionally allowing its use in any non-100    provisional response to INVITE."

For Q4-2_1:

"Following text is added after the first paragraph of section 20.4 [RFC3261]:

A SIP proxy MAY add or remove header field values in an Alert-Info    header field in a SIP request or in any non-100 provisional response."

Thank you

Laura

2014-09-09 19:44 GMT+02:00 Christer Holmberg <[email-masked]<mailto:[email-masked]>>:

Hi Laura,

I don't find any text :)

Regards,

Christer

General:
-----------

<QG_1>

</QG_1>

Section 4.1:
---------------

<Q4-1_1>

</Q4-1_1>

Section 4.2:
---------------

<Q4-2_1>

</Q4-2_1>

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 10 Sep 2014 15:35:49 -0400

> > From: [email-masked] (Dale R. Worley)

> I was actually assuming that, when you receive a new Alert-Info, you
> would "disable" whatever rendering the previous triggered.
> 
> For example, if I receive a 181 with a call-forwarding-urn, and later
> a 180 with a called-party-alerting-urn, why would I keep rendering the
> call-fowarding-urn?

There are interesting complications.  Certainly if you can tell that
the 180 is the successor of the 181 on the same branch of the call,
then performing only the rendering for the 180 makes sense.  And you
may be able to tell that the 180 is the successor of the 181, perhaps
by looking at the tags or the History-Info.

But if the call forks, it could make sense to audio-mix the renderings
for the two 180s that you receive.  That seems to be how situations in
the PSTN work if two destination telephone systems deal with the call
simultaneously.

If you have a visual display, and the renderings are text fragments,
simply listing "forarding" for the 181, followed by "ringing" for the
180, may be useful for the user.

> If you say "choose among or combine", how do you know that the UA will
> behave as you expect? We would need to define how different urns
> interact with each other, and I don't think we want to go down that
> path...

The critical thing is "choose among or combine *these renderings*".
That is, each set of Alert-Infos is turned into a rendering, and then
in a second step, the UA "chooses among or combines" them.  An
Alert-Info URN in one response cannot interact (*as a URN*) with one
in another response.

I suspect that there is room for experimentation and development in
developing good logic for handling multiple responses.  My goal with
that text is to allow freedom for the UA designers.  The only rules
are (1) the URNs in different responses don't interact *as URNs*, but
only by some sort of interaction between the renderings that they
specify, and (2) later information is "prefered" relative to earlier
information.  That second rule is a hint that in many cases, the later
information does supersede the former information.

> From: Laura Liess <[email-masked]>
> > From: [email-masked] (Dale R. Worley)
> "This specification changes the usage of the Alert-Info header field
> defined in [RFC3261] by additionally allowing its use in any non-100
> provisional response to INVITE."

Which is essentially the same as my version, so we're all agreed on that.

> > From: [email-masked] (Dale R. Worley)
> However, I think we have already broken those rules in the past. For
> example, RFC 3325 specifies that a proxy can remove a
> P-Preferred-Identity header field, and that RFC does not update RFC
> 3261.
> 
> Also, RFC 3329 specifies that a proxy can remove the Require and
> Proxy-Require header field, after it has removed the security
> option-tags, and there are no option-tags left.
>
> So, while the fact that we have done something in the past doesn't
> automatically justify us to do it again, I just wonder whether it
> would be the end of the world?

Looking at 3325 and 3329, there are a number of places where they
specify header fields to be removed, and neither of them provides
indication of what parts of 3261 are being amended thereby.

> I don't have any strong preference, as long as it is clear what we
> update. But, perhaps we should ask the SIPCORE folks (that's mostly
> us :) whether we really would need to go down the path and update
> sections 16.6 and 16.7, or whether we e.g. in section 20.4 could
> simply say that a proxy can remove the header field.
> 
> From: Laura Liess <[email-masked]>
> 
> A SIP proxy MAY add or remove header field values in an Alert-Info
> header field in a SIP request or in any non-100 provisional
> response."

If the issue is "This section is below the "Updates to RFC 3261"
section, but it is unclear exactly what is updated.", the answer is
"What is being updated is the rules in section 16.6 and 16.7 regarding
how proxies forward requests and responses."  And it would seem to be
to be a proper answer to insert that sentence in section 4.2.

As Christer notes, previous RFCs don't specify "what is updated" at
all.

If the issue is "I want to see the section stated in the form of a
textual amendment to RFC 3261." then Laura's change seems to be a good
one, as any attempt to track down all statements regarding Alert-Info
will find it.  And it does not involve textually editing the words of
sections 16.6 and 16.7, which would be quite unpleasant -- but just as
above, it requires the reader to semantically combine the amendment
with the original rules of 16.6 and 16.7.

Christer, if you think Laura's text works, why don't we go with that?

> Don't you mean "add or remove an Alert-Info header field"?

The assumption has been that an Alert-Info header field is just a way
of carrying Alert-Info header field values, so removing the last value
automatically removes the last header field (as a header field with no
values is not allowed syntactically).  And if there are no Alert-Info
header fields, adding one value will create the header field as well
as creating the header field value.

Ugh, one problem is that our terminology doesn't perfectly match that
of 3261, and 3261 is not completely consistent.  In most of 3261,
there is one, unique Alert-Info "header field", which consists of
"header field rows" (each of which is what is ordinarily called a
"header"), with each row containing one or more values.  The relevant
texts are:

      Header Field: A header field is a component of the SIP message
         header.  A header field can appear as one or more header field
         rows. Header field rows consist of a header field name and zero
         or more header field values. Multiple header field values on a
         given header field row are separated by commas. Some header
         fields can only have a single header field value, and as a
         result, always appear as a single header field row.

   [H4.2] also specifies that multiple header fields of the same field
   name whose value is a comma-separated list can be combined into one
   header field.  [Note this isn't consistent with the above definition!]

   Multiple header field rows with the same field-name MAY be present in
   a message if and only if the entire field-value for that header field
   is defined as a comma-separated list (that is, if follows the grammar
   defined in Section 7.3).  It MUST be possible to combine the multiple
   header field rows into one "field-name: field-value" pair, without
   changing the semantics of the message, by appending each subsequent
   field-value to the first, each separated by a comma.

The texts in the draft that deal with this are as follows.  They are
not completely parallel to each other.

   Abstract

   This document also permits proxies to add and remove header field
   values from the Alert-Info header field.

   A SIP proxy MAY add or remove header field values in an Alert-Info
   header field in a SIP request or a provisional 1xx response
   (excepting a 100 response).

   14.  Proxy Behaviour

   A SIP proxy MAY add an Alert-Info header field if none is present,
   and MAY add or remove header field values of an Alert-Info header
   field in a SIP request or a provisional 1xx response (excepting a 100
   response) when it needs to modify the information about the call or
   about the provided services.

Let me propose that we use this phrase, which I think covers all the
possibilities and works with either definition of "header field":

   a SIP proxy MAY add or remove an Alert-Info header field, and MAY
   add or remove Alert-Info header field values

That would amend the draft to read:

   Abstract

   This document also permits proxies to add or remove an Alert-Info
   header field, and to add or remove Alert-Info header field values.

   A SIP proxy MAY add or remove an Alert-Info header field, and MAY
   add or remove Alert-Info header field values, in a SIP request or a
   non-100 provisional response.

   14.  Proxy Behaviour

   A SIP proxy MAY add or remove an Alert-Info header field, and MAY
   add or remove Alert-Info header field values, in a SIP request or a
   non-100 provisional response when it needs to modify the
   information about the call or about the provided services.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Sep 2014 06:51:24 +0000

Hi,

>>> It seems to me that the best place to insert this would be at the 
>>> end of section 13, where we are stating the rules for UAs regarding 
> There are interesting complications.  Certainly if you can tell that the 180 is the successor of the 181 on the same branch of the call, then performing 
> only the rendering for the 180 makes sense.  And you may be able to tell that the 180 is the successor of the 181, perhaps by looking at the tags or the History-Info.
>
> But if the call forks, it could make sense to audio-mix the renderings for the two 180s that you receive.  That seems to be how situations in the PSTN work if two destination telephone systems deal with the call simultaneously.
>
> If you have a visual display, and the renderings are text fragments, simply listing "forarding" for the 181, followed by "ringing" for the 180, may be useful for the user.
>
> That is, each set of Alert-Infos is turned into a rendering, and then in a second step, the UA "chooses among or combines" them.  An Alert-Info URN in one response cannot interact (*as a URN*) with one in another response.
>
> I suspect that there is room for experimentation and development in developing good logic for handling multiple responses.  My goal with that text is to allow freedom for the UA 
> designers.  The only rules are (1) the URNs in different responses don't interact *as URNs*, but only by some sort of interaction between the renderings that they specify, and (2) later 
> information is "prefered" relative to earlier information.  That second rule is a hint that in many cases, the later information does supersede the former information.

Perhaps we could say that, within a given dialog, a subsequent URN disables the previous.

Then, in the case of forking, we leave it open, and simply say that it is an implementation issue how URNs received on different dialogs are treated, and how/if they interact.

>>>> 4.2:
>>>> proxy can insert a A-I header. If you want to explicitly say that 
>>>> a proxy can also modify an existing header, shouldn't that be text 
>> Looking at 3325 and 3329, there are a number of places where they specify header fields to be removed, and neither of them provides indication of what parts of 3261 are being amended thereby.

That's my point: we could say that a proxy can remove the Alert-Info header field - without saying anything about updating 3261 :)

>>> Given how long and complicated those sections are, it's rather 
>>> awkward to edit the change into those sections textually.
>>> 
>>> you suggest in the second item, because it seems to apply to this 
>>> item as well.)
>>> 
>> update. But, perhaps we should ask the SIPCORE folks (that's mostly us 
>> :) whether we really would need to go down the path and update 
>> header field in a SIP request or in any non-100 provisional response."
>
> section, but it is unclear exactly what is updated.", the answer is "What is being updated is the rules in section 16.6 and 16.7 regarding how proxies 
> forward requests and responses."  And it would seem to be to be a proper answer to insert that sentence in section 4.2.
>
> As Christer notes, previous RFCs don't specify "what is updated" at all.
>
> If the issue is "I want to see the section stated in the form of a textual amendment to RFC 3261." then Laura's change seems to be a good 
> one, as any attempt to track down all statements regarding Alert-Info will find it.  And it does not involve textually editing the words of 
> sections 16.6 and 16.7, which would be quite unpleasant -- but just as above, it requires the reader to semantically combine the amendment 
> The assumption has been that an Alert-Info header field is just a way of carrying Alert-Info header field values, so removing the last value automatically 
> removes the last header field (as a header field with no values is not allowed syntactically).
> And if there are no Alert-Info header fields, adding one value will create the header field as well as creating the header field value.

True. But, at least RFC 3329 explicitly says that, if the last header field value (in the case of 3329, option-tags in Require/Proxy-Require) is removed, then the header field itself is also removed. I don't think it would hurt to explicitly say that also in this draft - at least as a note. 

> Ugh, one problem is that our terminology doesn't perfectly match that of 3261, and 3261 is not completely consistent.  In most of 3261, there is one, unique 
> Alert-Info "header field", which consists of "header field rows" (each of which is what is ordinarily called a "header"), with each row containing one or more values.  The relevant texts are:
>
> The texts in the draft that deal with this are as follows.  They are not completely parallel to each other.
>
>   Abstract
>
> Let me propose that we use this phrase, which I think covers all the possibilities and works with either definition of "header field":
>

I still don't think we need 4.2, as there is no similar text in other RFCs allowing the removal of header field/header field values (perhaps SIPCORE should make a generic update of 3261, and allow specifications of individual header fields ti define whether a header field can be removed by proxies.)

BUT, if I am the only one having that opinion, I will rest my case in order not to delay the draft :)

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 12 Sep 2014 15:43:45 -0400

> That's my point: we could say that a proxy can remove the Alert-Info
> header field - without saying anything about updating 3261 :)

It seems to me that if we're going to have a section which describes
the normative changes to 3261, it should list every normative change
we make to 3261, even if it isn't the sort of change that has in the
past been done by declaring a textual amendment to 3261.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Sep 2014 08:28:52 +0000

Hi,

> It seems to me that if we're going to have a section which describes the normative changes to 3261, > it should list every normative change we make to 3261, even if it isn't the sort of change that has in > the past been done by declaring a textual amendment to 3261.

Correct.

So, my suggestion is still that we don't say anything about updating 3261. We simply say that a proxy can remove the Alert-Info header field/header field values, and that's it.

Regards,

Christer

---

From: Laura Liess <[email-masked]>
Date: Fri, 19 Sep 2014 13:15:18 +0200

Christer, Dale,

I put my current understanding of the discussion outcome into the text
modifications below. Please look at it and let me know your opinion.

- Issue 4.1.  New text for Section 4.1 :
"This specification changes the usage of the Alert-Info header field
defined in [RFC3261] by additionally allowing its use in any non-100
provisional response to INVITE."

- Issue 4.2 :
     - New text for Section "Abstract", second paragraph:
"This document normatively updates RFC 3261, which defines the Session
Initiation
Protocol (SIP): It changes the usage of the Alert-Info header field defined
in RFC 3261 by additionally allowing its use in any non-100 provisional
response to INVITE (except the 100 response).This document also permits
proxies to add or remove an Alert-Info  header field, and to add or remove
Alert-Info header field values."

     - It is not clear to me if we completly drop Section 4.2 or if we keep
it with the new text:
"A SIP proxy MAY add or remove an Alert-Info header field, and MAY add or
remove Alert-Info header field values, in a SIP request or a non-100
provisional response."

       - Section  14 "Proxy Behaviour". First paragraph is replaced by:

"A SIP proxy MAY add or remove an Alert-Info header field, and MAY add or
remove Alert-Info header field values, in a SIP request or a  non-100
provisional response when it needs to modify the  information about the
call or about the provided services."

-  Issue "General":  New text at the end of Section 13 "User Agent
Behaviour"

"Subsequent provisional responses, even within the same dialog, may    contain
different Alert-Info header field values.  The Alert-Info header    field
values received within different Provisional responses are treated
independently.  If subsequent provisional responses containing  different
Alert-Info header field values were received within the same dialog, the
User Agent should render at anytime the last received Alert-Info header
field value. The handling of provisional responses containing  different
Alert-Info header field values which were not received within the same
dialog is left as an implementation issue."

Thank you
Laura

2014-09-13 10:28 GMT+02:00 Christer Holmberg <[email-masked]

> > It seems to me that if we're going to have a section which describes the
> normative changes to 3261, > it should list every normative change we make
> to 3261, even if it isn't the sort of change that has in > the past been
> done by declaring a textual amendment to 3261.
>
> Correct.
>
> So, my suggestion is still that we don't say anything about updating 3261.
> We simply say that a proxy can remove the Alert-Info header field/header
> field values, and that's it.
>
> Regards,
>
> Christer
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 19 Sep 2014 16:46:39 -0400

[as an individual]

> modifications below. Please look at it and let me know your opinion.

These changes look very good to me (except for a few nits, which I
have noted below).  I recommend keeping section 4.2 with the wording
you've suggested, as it is a normative change to 3261, and we want to
list it as such.

> response to INVITE (except the 100 response).This document also permits
                     ^-----------------------^
This text is redundant and can be removed.
> values received within different Provisional responses are treated
Put this word in lower case. ------^
> User Agent should render at anytime the last received Alert-Info header
-------------^
I think we want "SHOULD" here.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Sep 2014 08:38:03 +0000

Hi Laura,

- Issue 4.2 :
     - New text for Section "Abstract", second paragraph:
"This document normatively updates RFC 3261, which defines the Session Initiation Protocol (SIP): It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in any non-100 provisional response to INVITE (except the 100 response).This document also permits proxies to add or remove an Alert-Info  header field, and to add or remove Alert-Info header field values."

I suggest you remove "except the 100 response". You already say "non-100 provisional response", so...

Regards,

Christer

     - It is not clear to me if we completly drop Section 4.2 or if we keep it with the new text:
"A SIP proxy MAY add or remove an Alert-Info header field, and MAY add or remove Alert-Info header field values, in a SIP request or a non-100 provisional response."

       - Section  14 "Proxy Behaviour". First paragraph is replaced by:
"A SIP proxy MAY add or remove an Alert-Info header field, and MAY add or remove Alert-Info header field values, in a SIP request or a  non-100 provisional response when it needs to modify the  information about the call or about the provided services."

-  Issue "General":  New text at the end of Section 13 "User Agent Behaviour"
"Subsequent provisional responses, even within the same dialog, may    contain different Alert-Info header field values.  The Alert-Info header    field values received within different Provisional responses are treated  independently.  If subsequent provisional responses containing  different Alert-Info header field values were received within the same dialog, the User Agent should render at anytime the last received Alert-Info header field value. The handling of provisional responses containing  different Alert-Info header field values which were not received within the same dialog is left as an implementation issue."

Thank you
Laura

2014-09-13 10:28 GMT+02:00 Christer Holmberg <[email-masked]<mailto:[email-masked]>>:
Hi,

Correct.

Regards,

Christer

---

From: Laura Liess <[email-masked]>
Date: Sun, 21 Sep 2014 14:01:33 +0200

Dale, Christer,

Thank you.  I hope to be able to publish version 14 by Tuesday.

Kind regards
Laura

2014-09-20 10:38 GMT+02:00 Christer Holmberg <[email-masked]

> Initiation Protocol (SIP): It changes the usage of the Alert-Info header
> field defined in RFC 3261 by additionally allowing its use in any non-100
> provisional response to INVITE (except the 100 response).This document
> also permits proxies to add or remove an Alert-Info  header field, and to
> add or remove Alert-Info header field values."
>
>
>
> "Subsequent provisional responses, even within the same dialog, may
> contain different Alert-Info header field values.  The Alert-Info header
> field values received within different Provisional responses are treated
> 2014-09-13 10:28 GMT+02:00 Christer Holmberg <
> [email-masked]>:
>
> Hi,
>

---

From: Laura Liess <[email-masked]>
Date: Tue, 23 Sep 2014 15:55:17 +0200

Hi,

I promised to publish version 14 today. But it seems now that we still have
an open issue with IANA  so I will wait for this issue to be clarified.

Thank you
Laura

2014-09-21 14:01 GMT+02:00 Laura Liess <[email-masked]>:

> 2014-09-20 10:38 GMT+02:00 Christer Holmberg <
>> field defined in RFC 3261 by additionally allowing its use in any
>> non-100 provisional response to INVITE (except the 100 response).This
>> document also permits proxies to add or remove an Alert-Info  header field,
>> and to add or remove Alert-Info header field values."
>>
>>
>>
>> "A SIP proxy MAY add or remove an Alert-Info header field, and MAY add
>> or remove Alert-Info header field values, in a SIP request or a  non-100
>> the normative changes to 3261, > it should list every normative change we
>> make to 3261, even if it isn't the sort of change that has in > the past
>> been done by declaring a textual amendment to 3261.
>>
>> Correct.
>>
>> So, my suggestion is still that we don't say anything about updating
>> 3261. We simply say that a proxy can remove the Alert-Info header
>> field/header field values, and that's it.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>
>