From nobody Thu Sep 4 01:00:40 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAA11A6F62 for ; Thu, 4 Sep 2014 01:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eC1JOnTHedl8 for ; Thu, 4 Sep 2014 01:00:36 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2641A6F57 for ; Thu, 4 Sep 2014 01:00:36 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-b4-54081c21614c Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 27.1E.02247.12C18045; Thu, 4 Sep 2014 10:00:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Thu, 4 Sep 2014 10:00:33 +0200 From: Christer Holmberg To: "salud@ietf.org" Thread-Topic: Review comments on draft-ietf-salud-alert-info-urns-13 Thread-Index: Ac/IFf+gMZjC49hSQeiq/vmrqzhpOA== Date: Thu, 4 Sep 2014 08:00:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D439271ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvja6SDEeIwdJ+Vou7HQcYLV6eKHNg 8pi8/yuzx5IlP5kCmKK4bFJSczLLUov07RK4Mt5db2MquGVRMXHmPvYGxn2GXYycHBICJhLn nn1nhbDFJC7cW8/WxcjFISRwlFFi8duNTCAJIYHFjBKHdyh3MXJwsAlYSHT/0wYJiwioSlxf 3c0CYjML2Ems2L+EHcQWFrCXmPZ9CyNEjYvE1Yc3mCFsPYmXd5rBRrIIqEgsm7+NCWQkr4Cv xK+2VJAwI9AJ30+tYYIYKS5x68l8JojTBCSW7DnPDGGLSrx8/I8VpFVCQFFieb8cRHm+xJuW e2DX8AoISpyc+YRlAqPwLCSTZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9i FC1OLS7OTTcy0kstykwuLs7P08tLLdnECIybg1t+W+1gPPjc8RCjAAejEg/vg//sIUKsiWXF lbmHGKU5WJTEeReemxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdFk5YezC69varp/bFKH zfc9az2fPmfcWhDHlW067WWWbsZ+SY9Ql8Nzf6kfWiQt4HLOfJZU2oa4KUE3/NR/XU7q3RqU lKO2le1s+apai5qPponhj7hDl8n9Sc7svfIkdtPpWtYL3xtWWhw92Z+wNPjtKhGd+68Pp/zb 8aB7D/f/fYKrBWv2pP1VYinOSDTUYi4qTgQA/dDCiHwCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/salud/-T6Ir1zfa1Cu0GMmOL2BY6VmixU Subject: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 08:00:38 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D439271ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have reviewed the latest version of the alert-urn draft. In general it lo= oks ok, but I have a few comments (of which one is pure editorial) that I r= equest the authors to address. General: ----------- As it is now allowed to use the Alert-Info header field in any non-100 prov= isional 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 u= se cases where e.g. one value is received in a 181, and another value in a subsequent 180. Section 4.1: --------------- This is pure editorial, but for alignment purpose I suggest= to change "in all provisional responses..." to "in any non-100 provisional= response..." Section 4.2: --------------- 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 tha= t you add to e.g. the same paragraph? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D439271ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 p= ure 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 ass= ume 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 t= hat in this draft, because I assume there could be use cases where

e.g. one value is recei= ved in a 181, and another value in a subsequent 180.

 

</QG_1>

 

 

Section 4.1:

---------------

 

<Q4-1_1>

 

        &nbs= p;       This is pure editorial, but for alig= nment 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 t= he “Updates to RFC 3261” section, but it is unclear exactly wha= t 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 m= odify an existing header, shouldn’t that be text that you add to e.g.= the same paragraph?

 

 

</Q4-2_1>

 

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D439271ESESSMB209erics_-- From nobody Tue Sep 9 06:23:31 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE031A02F1 for ; Tue, 9 Sep 2014 06:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4VtyxbXBP_n for ; Tue, 9 Sep 2014 06:23:27 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C78C1A02ED for ; Tue, 9 Sep 2014 06:23:26 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id hz20so4468421lab.15 for ; Tue, 09 Sep 2014 06:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TVu8/9LO/YqyqweeKhvzgXsDpkZU6GyC37m3NiOI0Mk=; b=MGajrD4+eONDUUOjPgcxzhhm5L++dd4vjLp9TL2/VALGeTlQjDwVjG+lhznUAxSph7 7j+v32wh6vacUq3Rkc3P7hLix9GL3JpyGGHLw8Tmy+c8GEyILdVCEuNVcR6WvzUD7U2b Lldw3JlglAXyVySNocl9KMfWLzIxVAP2xwdaZfPeucsFuY3KicA5B6URiKeoKczy1UR8 lLQPMQ47VkekVQilgNGM/GVMKeXlDa2NmiKTWzdGEca5HMpoVEipELOn/nEgmAEZMSwD YULZ185vO7KxikZOppUUJZmTfe1KRky9K8Y9l9hNQ7Rxv3SUvIEoAV0L/11ilEGAF8Hj sjsw== MIME-Version: 1.0 X-Received: by 10.152.202.135 with SMTP id ki7mr6792562lac.16.1410269004501; Tue, 09 Sep 2014 06:23:24 -0700 (PDT) Received: by 10.114.77.227 with HTTP; Tue, 9 Sep 2014 06:23:24 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> Date: Tue, 9 Sep 2014 15:23:24 +0200 Message-ID: From: Laura Liess To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1135fb420d18510502a1d754 Archived-At: http://mailarchive.ietf.org/arch/msg/salud/eKq5WWdMNQHrNNENlz-SBQX5CU4 Cc: "salud@ietf.org" Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 13:23:29 -0000 --001a1135fb420d18510502a1d754 Content-Type: text/plain; charset=ISO-8859-1 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: > > ----------- > > > > > > > > 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. > > > > > > > > > > Section 4.1: > > --------------- > > > > > > > > This is pure editorial, but for alignment purpose I > suggest to change "in all provisional responses..." to "in any non-100 > provisional response..." > > > > > > > > > > Section 4.2: > > --------------- > > > > > > > > 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? > > > > > > > > > > > > Regards, > > > > Christer > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > > --001a1135fb420d18510502a1d754 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Christer,

Thank you very much for the comments.

Please fin= d 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 c= omment QG_1.  IMO, usual= ly 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 o= r transaction. 
Additionaly, if we add text and mention these use cases, I think people= =20 will ask for concrete examples, then for message flows and so on, so that f= inishing the draft will take another year...
There is also nothing we ca= n do here for a UA receiving different Alert-Info in two non-100 provisiona= l reasponses, we have no rules on how the UA has to handle them, this is im= plementation dependent anyway.  
So, my personal opinion is t= o leave this out. 

Thank you
Laura



 

General:

-----------

 

<QG_1>

 

As it is now allowed to u= se the Alert-Info header field in any non-100 provisional response, I assum= e the value could actually change from one

response to another. <= /u>

 

Eventhough RFC3261 does n= ot explicitly forbid it, perhaps it would be good to explicitly mention tha= t in this draft, because I assume there could be use cases where<= /u>

e.g. one value is receive= d in a 181, and another value in a subsequent 180.

 

</QG_1>

 


&= nbsp;

 

Section 4.1:

---------------

 

<Q4-1_1>

 

        &nbs= p;       This is pure editorial, but for alig= nment purpose I suggest to change “in all provisional responses&helli= p;” 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 se= ction 20.4/RFC 3261 already says that a proxy can insert a A-I header. If y= ou want to explicitly say

that a proxy can also mod= ify an existing header, shouldn’t that be text that you add to e.g. t= he same paragraph?

 

 

</Q4-2_1>

 

 

Regards,=

 

Christer


_______________________________________________
salud mailing list
salud@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/salud


--001a1135fb420d18510502a1d754-- From nobody Tue Sep 9 10:45:09 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CFA1A8757 for ; Tue, 9 Sep 2014 10:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E-A1VNvuuXy for ; Tue, 9 Sep 2014 10:45:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166E71A8737 for ; Tue, 9 Sep 2014 10:44:53 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-39-540f3c93e21d Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EA.DF.24955.39C3F045; Tue, 9 Sep 2014 19:44:52 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Tue, 9 Sep 2014 19:44:51 +0200 From: Christer Holmberg To: Laura Liess Thread-Topic: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 Thread-Index: Ac/IFf+gMZjC49hSQeiq/vmrqzhpOAECnhIAAA0sVGI= Date: Tue, 9 Sep 2014 17:44:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4411D8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3RneKDX+IwYl97BZzrhha3O04wOjA 5PF0wmR2jyVLfjIFMEVx2aSk5mSWpRbp2yVwZbT+fsta8C+hYunxnawNjL+Duxg5OCQETCT2 fmbvYuQEMsUkLtxbz9bFyMUhJHCUUWLJkdvsEM5iRom+x7NYQRrYBCwkuv9pgzSICOhLnOj7 CNbMLKAqsff2EiYQW1jAW2L5/T/MEDU+Ere3v4WyrSR+nL7EBmKzCKhIfPm9ghXE5hXwlejY +48JYtckRolJnyeANXAKBEocurYMrIgR6Lrvp9YwQSwTl7j1ZD4TxNUCEkv2nGeGsEUlXj7+ xwphK0q0P21ghKjPlzj5/CgzxDJBiZMzn7BMYBSdhWTULCRls5CUQcQNJN6fm88MYWtLLFv4 GsrWl9j45SwjsvgCRvZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIHRdnDLb9UdjJffOB5i FOBgVOLhTZzOFyLEmlhWXJl7iFGag0VJnHfhuXnBQgLpiSWp2ampBalF8UWlOanFhxiZODil GhgTcwP3BV8RWVnmLjdpW2Ni5ddpMYXvO0+c0ewxCzL5Jjz54+fnv6UEOEOEsvlyn76RU9Gr lP4/yc19nv2br2b6M9Z+fba+YPL/5hXT42IZm4sPW9WY8llev+Vzae+amlecvKuyFtUpXlaS trR62S9kkL3nsuS/bUpL+Ged85zI+2Hq5996to+UWIozEg21mIuKEwHtMO4GlwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/YcJqZo8NM9C1RpPhnGgCjnd78hM Cc: "salud@ietf.org" Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 17:45:07 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4411D8ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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, usuall= y 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 w= ill ask for concrete examples, then for message flows and so on, so that fi= nishing the draft will take another year... > There is also nothing we can do here for a UA receiving different Alert-I= nfo in two non-100 provisional reasponses, we have no rules on how the UA h= as to handle them, this is implementation dependent anyway. > So, my personal opinion is to leave this out. I think a simple note, saying that depending on the use-case/service, subse= quent non-100 provisional responses might contain different values. Otherwi= se I am pretty sure that people, sooner or later, will argue whether it is = allowed or not... Regards, Christer General: ----------- As it is now allowed to use the Alert-Info header field in any non-100 prov= isional 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 u= se cases where e.g. one value is received in a 181, and another value in a subsequent 180. Section 4.1: --------------- This is pure editorial, but for alignment purpose I suggest= to change =93in all provisional responses=85=94 to =93in any non-100 provi= sional response=85=94 Section 4.2: --------------- This section is below the =93Updates to RFC 3261=94 section, but it is uncl= ear 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=92t that be text t= hat you add to e.g. the same paragraph? Regards, Christer _______________________________________________ salud mailing list salud@ietf.org https://www.ietf.org/mailman/listinfo/salud --_000_7594FB04B1934943A5C02806D1A2204B1D4411D8ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

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

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

 

Regards,

 

Christer

 

 




 

General:

-----------

 

<QG_1>

 

As it is now allowed to = use the Alert-Info header field in any non-100 provisional response, I assu= me 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 th= at in this draft, because I assume there could be use cases where=

e.g. one value is receiv= ed in a 181, and another value in a subsequent 180.

 

</QG_1>

 


 

 

Section 4.1:

---------------

 

<Q4-1_1>

 

        &nbs= p;       This is pure editorial, but for alig= nment purpose I suggest to change =93in all provisional responses=85=94 to = =93in any non-100 provisional response=85=94

 

</Q4-1_1>

 

 

Section 4.2:

---------------

 

<Q4-2_1>

 

This section is below th= e =93Updates to RFC 3261=94 section, but it is unclear exactly what is upda= ted.

 

The first paragraph of s= ection 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 mo= dify an existing header, shouldn=92t that be text that you add to e.g. the = same paragraph?

 

 

</Q4-2_1>

 

 

Regards,=

 

Christer


_______________________________________________
salud mailing list
salud@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/salud


--_000_7594FB04B1934943A5C02806D1A2204B1D4411D8ESESSMB209erics_-- From nobody Tue Sep 9 13:32:43 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AB81A0172 for ; Tue, 9 Sep 2014 13:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1HlR-NDeuSh for ; Tue, 9 Sep 2014 13:32:40 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 144F41A0149 for ; Tue, 9 Sep 2014 13:32:39 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta09.westchester.pa.mail.comcast.net with comcast id p85S1o0040mv7h0598Yf2y; Tue, 09 Sep 2014 20:32:39 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta11.westchester.pa.mail.comcast.net with comcast id p8Ye1o00b1KKtkw3X8YfVZ; Tue, 09 Sep 2014 20:32:39 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s89KWc2d028511; Tue, 9 Sep 2014 16:32:38 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s89KWcma028510; Tue, 9 Sep 2014 16:32:38 -0400 Date: Tue, 9 Sep 2014 16:32:38 -0400 Message-Id: <201409092032.s89KWcma028510@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410294759; bh=Mt0OlGO9YvgWYcKXQwqXi66MiO1SEflBD+znyFanR18=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=IBmZVsm/AJiOoY9mFh68OJpCz061eb5b1P0B5dEl735xrtfFO4tj3TfqbDgDF9kJx S0FnsFax4XjW++0k1+h83QyhgUKJHqJ3qRL9yyL/erfs5ED+hgzv76kfPycsJ3jy05 lgcmeC4ckSTFt/Mhy0+ubvR1vMavQ/opPs/MngNJVo1kqfBiQ3OCgUMx2/9gF36T02 vDMQklkKKS9H7ypHjiMUbKj0LK940eEmoPGv3HpTLhdpb2DaTz5K4b1usMDPWb09i6 1eqBNnPb1jalowpZ+SiswtFiNW8tbs31XwVDOAXsFNRn65AlrkxE0j9YTrZTjmsqHt ThE42Vj3WDbUg== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/hnpqFsDHAwiT1A-4q7qhNoRfpfQ Cc: salud@ietf.org Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 20:32:42 -0000 Many thanks for your review! My apologies for not tending to this earlier. > From: Christer Holmberg > > > 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: > --------------- > > > > 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. > Section 4.2: > --------------- > > > > 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? 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 nobody Tue Sep 9 14:33:37 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9C61A0337 for ; Tue, 9 Sep 2014 14:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FK0L0TIuJRzl for ; Tue, 9 Sep 2014 14:33:34 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B44071A035E for ; Tue, 9 Sep 2014 14:33:32 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-5a-540f722acc27 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6B.2F.21432.A227F045; Tue, 9 Sep 2014 23:33:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Tue, 9 Sep 2014 23:33:29 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: Review comments on draft-ietf-salud-alert-info-urns-13 Thread-Index: Ac/IFf+gMZjC49hSQeiq/vmrqzhpOAEVzP2cAAFlfTM= Date: Tue, 9 Sep 2014 21:33:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4416B6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se>, <201409092032.s89KWcma028510@hobgoblin.ariadne.com> In-Reply-To: <201409092032.s89KWcma028510@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja5WEX+Iwe+NGhZ3Ow4wWrw8UebA 5DF5/1dmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZazcvI+9YKN2xdI7E9kaGBcqdTFyckgImEgc nf+SEcIWk7hwbz1bFyMXh5DAUUaJzXNPskA4ixklNnZNA8pwcLAJWEh0/9MGMUUENCU6FuSA 9DILqErsvb2ECcQWFnCW+DTnM5gtIuAicfXhDWYI20ri1Y9fYLtYBFQkfp84wgZi8wr4Skx5 epYdYlUjo8SnPa/AijgFHCT2nvgENogR6Ljvp9YwQSwTl7j1ZD4TxNECEkv2nGeGsEUlXj7+ xwpym4SAosTyfjmIch2JBbs/sUHY2hLLFr5mhtgrKHFy5hOWCYxis5BMnYWkZRaSlllIWhYw sqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIydg1t+G+xgfPnc8RCjAAejEg+vQjxfiBBr YllxZe4hRmkOFiVx3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYFyzU+nNFsMPEo/W drEXqkQ/itWW3cBy33jxt19vn9qpnZFd4CGt+CJ0Zo+Eo1LFP9GmL+y13G+uSzuoP9q9+nzN a5FGwTUzxe5NvsC1I5Fl4yUrxXX35us9ttvVetM+/Nuypt5jmk5qexL//z3EyBHzb1J6grHf 04dSfBUteY+ZfIyynu02eqbEUpyRaKjFXFScCABwMWLpfgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/F0yoQSEWflXukXcsJYpNGVZAekc Cc: "salud@ietf.org" Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 21:33:36 -0000 Hi, >> >> >> 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. 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-fowa= rding-urn? If you say "choose among or combine", how do you know that the UA will beha= ve 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... >> Section 4.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. Correct. > I agree that the latter reads better. > >> Section 4.2: >> --------------- >> >> >> >> 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? > > 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). I hear what you are saying. However, I think we have already broken those rules in the past. For exampl= e, 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-Requ= ire 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 automati= cally justify us to do it again, I just wonder whether it would be the end = of the world? >>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. 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 w= e 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 nobody Wed Sep 10 06:00:45 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FEE1A6FD5 for ; Wed, 10 Sep 2014 06:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WFU0-hpG2vi for ; Wed, 10 Sep 2014 06:00:33 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE131A0068 for ; Wed, 10 Sep 2014 06:00:32 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gi9so9766811lab.16 for ; Wed, 10 Sep 2014 06:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yrUvh5LGo2Bqu1bx8VS925CH6eWmwvUvl1mRGawMa7E=; b=P8X5xu5VW9y4kyWczw6+rfqEM/oA01T6fDdyDO6wiVspKbiz2M2ELCgkcof9pzhPyv 9PemtM8q64K0CVrXYLOZ5qOHrXz+Wr1BoWGOkRxlvj5DZxYXCB4+9U6YKLmcvV49Xkmn R3BpdpL5Bnl9cEfZR4kscim4Z+fkR7KPdhHPyhIPbeR9vkXZBI4wJVfk1jPJOOmW584p BpcKmq+hLNaOedTjpqXeCZLDGhSpoF5jlZeKuyRWaIKm/ycfx9LUjq71SKpD5zRLUYA4 52CevC+sjnx2OtPJSS3TO02jnl/DEWu5/S1NUkyKGllLxp1SmLLDybjnOz6tMi/JDUBR RB6Q== MIME-Version: 1.0 X-Received: by 10.152.4.9 with SMTP id g9mr42789049lag.14.1410354030774; Wed, 10 Sep 2014 06:00:30 -0700 (PDT) Received: by 10.114.77.227 with HTTP; Wed, 10 Sep 2014 06:00:30 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se> Date: Wed, 10 Sep 2014 15:00:30 +0200 Message-ID: From: Laura Liess To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e013d1708030dbe0502b5a3e2 Archived-At: http://mailarchive.ietf.org/arch/msg/salud/oplt90gOj2MoneIcmuRhAu69BLc Cc: "salud@ietf.org" Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 13:00:43 -0000 --089e013d1708030dbe0502b5a3e2 Content-Type: text/plain; charset=ISO-8859-1 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 : > 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. > > So, my personal opinion is to leave this out. > > > > 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: >> >> ----------- >> >> >> >> >> >> >> >> 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. >> >> >> >> >> >> >> > > > >> >> >> Section 4.1: >> >> --------------- >> >> >> >> >> >> >> >> This is pure editorial, but for alignment purpose I >> suggest to change "in all provisional responses..." to "in any non-100 >> provisional response..." >> >> >> >> >> >> >> >> >> >> Section 4.2: >> >> --------------- >> >> >> >> >> >> >> >> 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? >> >> >> >> >> >> >> >> >> >> >> >> Regards, >> >> >> >> Christer >> >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> >> > --089e013d1708030dbe0502b5a3e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Christer,

      > I don&= #39;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 usag= e 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 fir= st paragraph of section 4.1: 


=

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


A SIP proxy MAY add or re= move 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 Chris= ter Holmberg <christer.holmberg@ericsson.com>:<= br>

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 :)<= /p>


 

> 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 mess= age, there is no text saying in any way that the content of the Alert-Info = applies to a dialog or transaction. 
> Additionaly, if w= e add text and mention these use cases, I think people will ask for concret= e 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 Aler= t-Info in two non-100 provisional reasponses, we have no rules on how the U= A has to handle them, this is implementation dependent anyway.  
> So, my personal opinion is to leave this out. 

 

I think a simple no= te, 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 al= lowed or not...

 

Regards,

 

Christer

=

 

 




 

General:

-----------

 

<QG_1>

 

As it is now allowed to u= se the Alert-Info header field in any non-100 provisional response, I assum= e the value could actually change from one

response to another. <= /u>

 

Eventhough RFC3261 does n= ot explicitly forbid it, perhaps it would be good to explicitly mention tha= t in this draft, because I assume there could be use cases where<= /u>

e.g. one value is receive= d in a 181, and another value in a subsequent 180.

 

</QG_1>

 


 

 

Section 4.1:

---------------

 

<Q4-1_1>

 

        &nbs= p;       This is pure editorial, but for alig= nment purpose I suggest to change “in all provisional responses&helli= p;” 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 se= ction 20.4/RFC 3261 already says that a proxy can insert a A-I header. If y= ou want to explicitly say

that a proxy can also mod= ify an existing header, shouldn’t that be text that you add to e.g. t= he same paragraph?

 

 

</Q4-2_1>

 

 

Regards,=

 

Christer


_______________________________________________
salud mailing list
salud@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/salud



--089e013d1708030dbe0502b5a3e2-- From nobody Wed Sep 10 07:05:37 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD3C1A0277 for ; Wed, 10 Sep 2014 07:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnB3eLmRm4ls for ; Wed, 10 Sep 2014 07:05:34 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D901A00E9 for ; Wed, 10 Sep 2014 07:05:32 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-42-54105aa9ea35 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 86.3F.21334.9AA50145; Wed, 10 Sep 2014 16:05:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Wed, 10 Sep 2014 16:05:29 +0200 From: Christer Holmberg To: Laura Liess Thread-Topic: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 Thread-Index: Ac/IFf+gMZjC49hSQeiq/vmrqzhpOAECnhIAAA0sVGIAJFGJAAAGdc21 Date: Wed, 10 Sep 2014 14:05:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4425A3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4425A3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvje7KKIEQg+1/NS3mXDG0uNtxgNGB yePphMnsHkuW/GQKYIrisklJzcksSy3St0vgyvh9tbDgyhzGipc9h9kbGK91MnYxcnBICJhI rG7m7WLkBDLFJC7cW8/WxcjFISRwlFFi8crpjBDOEkaJLQ0TmEEa2AQsJLr/aYM0iAjoS5zo +8gOYjMLqErsvb2ECcQWFvCWWH7/DzNEjY/E7e1voWw3icP7d7OC2CxA9SdX/gWzeQV8JT6t ucgIYgsJzGWSeLo0FMTmFAiUuHzqENh8RqDjvp9awwSxS1yi6ctKVoijBSSW7DnPDGGLSrx8 /I8VoiZfYsvPoywQ8wUlTs58wjKBUWQWkvZZSMpmISmDiBtIfHl/G8rWlli28DUzhK0v0f3+ NBOy+AJG9lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgVF1cMtv3R2Mq187HmIU4GBU4uFd sIE/RIg1say4MvcQozQHi5I476Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MIpqRLjY tvaqJd19wjmL4aQ/f4r5441MV1On628zspj+7HHY0R3vfZ0fCW7xLVz4f2unhbvv047l5wwO f7t506PCxvGz2bXwovM5iv8rXQ55z32uY15X7GypUMIt7NZyVmXucrXZ7y5mzuK3UyhI3LE6 1/vkz+3v3jYl2/KtOsb3yK027vZqKyWW4oxEQy3mouJEAJmpqReLAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/salud/gdYlpQacED68Cj8thvNOP7xynBM Cc: "salud@ietf.org" Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 14:05:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4425A3ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Laura, Regarding Q4-2_1, we need to say that proxies can remove the whole header f= ield, not only header field values. Regards, Christer Sent from my Windows Phone ________________________________ From: Laura Liess Sent: =FD10/=FD09/=FD2014 16:00 To: Christer Holmberg Cc: salud@ietf.org 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: New text for the first paragraph of section 4.1: "This specification changes the usage of the Alert-Info header field def= ined in [RFC3261] by additionally allowing its use in any non-100 provis= ional 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 heade= r 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 >: 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, usuall= y 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 w= ill ask for concrete examples, then for message flows and so on, so that fi= nishing the draft will take another year... > There is also nothing we can do here for a UA receiving different Alert-I= nfo in two non-100 provisional reasponses, we have no rules on how the UA h= as to handle them, this is implementation dependent anyway. > So, my personal opinion is to leave this out. I think a simple note, saying that depending on the use-case/service, subse= quent non-100 provisional responses might contain different values. Otherwi= se I am pretty sure that people, sooner or later, will argue whether it is = allowed or not... Regards, Christer General: ----------- As it is now allowed to use the Alert-Info header field in any non-100 prov= isional 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 u= se cases where e.g. one value is received in a 181, and another value in a subsequent 180. Section 4.1: --------------- This is pure editorial, but for alignment purpose I suggest= to change =93in all provisional responses=85=94 to =93in any non-100 provi= sional response=85=94 Section 4.2: --------------- This section is below the =93Updates to RFC 3261=94 section, but it is uncl= ear 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=92t that be text t= hat you add to e.g. the same paragraph? Regards, Christer _______________________________________________ salud mailing list salud@ietf.org https://www.ietf.org/mailman/listinfo/salud --_000_7594FB04B1934943A5C02806D1A2204B1D4425A3ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Laura,

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

Regards,

Christer

Sent from my Windows Phone
From: Laura Liess
Sent: =FD10= /=FD09/=FD2014 16:00
To: Christer Holmberg Cc: salud@ietf.org
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 dra= ft version.   

For Q4-1_1:

 

New text for the first paragraph of section = 4.1:
      

"This specification changes the usa= ge of the Alert-Info header field    defined in [RFC3261] by additionally allowing its use = in any non-100    provisional response<= /span> 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]:<= /p>


A SIP proxy MAY add or re= move 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= <chr= ister.holmberg@ericsson.com>:

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 me= ssage, there is no text saying in any way that the content of the Alert-Inf= o applies to a dialog or transaction. 
> Additionaly, if= we add text and mention these use cases, I think people will ask for concr= ete 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 Aler= t-Info in two non-100 provisional reasponses, we have no rules on how the U= A has to handle them, this is implementation dependent anyway.  
> So, my personal opinion is to leave this out. 

 

I think a simple note, s= aying that depending on the use-case/service, subsequent non-100 provi= sional responses might contain different values. Otherwise I am pretty sure that people, sooner or later, will argue whether it is allo= wed or not...

 

Regards,

 

Christer

 

 




 

General:

-----------

 

<QG_1>

 

As it is now allowed to u= se the Alert-Info header field in any non-100 provisional response, I assum= e the value could actually change from one

response to another. <= /u>

 

Eventhough RFC3261 does n= ot explicitly forbid it, perhaps it would be good to explicitly mention tha= t in this draft, because I assume there could be use cases where<= /u>

e.g. one value is receive= d in a 181, and another value in a subsequent 180.

 

</QG_1>

 


 

 

Section 4.1:

---------------

 

<Q4-1_1>

 

        &nbs= p;       This is pure editorial, but for alig= nment purpose I suggest to change =93in all provisional responses=85=94 to = =93in any non-100 provisional response=85=94

 

</Q4-1_1>

 

 

Section 4.2:

---------------

 

<Q4-2_1>

 

This section is below the= =93Updates to RFC 3261=94 section, but it is unclear exactly what is updat= ed.

 

The first paragraph of se= ction 20.4/RFC 3261 already says that a proxy can insert a A-I header. If y= ou want to explicitly say

that a proxy can also mod= ify an existing header, shouldn=92t that be text that you add to e.g. the s= ame paragraph?

 

 

</Q4-2_1>

 

 

Regards,=

 

Christer


_______________________________________________
salud mailing list
salud@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/salud



--_000_7594FB04B1934943A5C02806D1A2204B1D4425A3ESESSMB209erics_-- From nobody Wed Sep 10 12:35:54 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE8B1A8733 for ; Wed, 10 Sep 2014 12:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFPmD719IjdD for ; Wed, 10 Sep 2014 12:35:51 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 19BB31A000B for ; Wed, 10 Sep 2014 12:35:51 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta05.westchester.pa.mail.comcast.net with comcast id pXWG1o0020QuhwU55Xbqqr; Wed, 10 Sep 2014 19:35:50 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta02.westchester.pa.mail.comcast.net with comcast id pXbq1o0081KKtkw3NXbq3W; Wed, 10 Sep 2014 19:35:50 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s8AJZn7h031579; Wed, 10 Sep 2014 15:35:49 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s8AJZn21031578; Wed, 10 Sep 2014 15:35:49 -0400 Date: Wed, 10 Sep 2014 15:35:49 -0400 Message-Id: <201409101935.s8AJZn21031578@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Laura Liess In-reply-to: (laura.liess.dt@googlemail.com) References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410377750; bh=H7O3zYGbLMhdtafbzwJjbjrKbpKCaZvyqGKLvOG47P8=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=LntzkgYSNsnokrB5m++SOeFkmL+sy4VLAMqJFVtYTJLAThns8mJ5JPtqoizS2dRJh cjz/30fjHhsnH07Y7/e8buQSkjWRncf5AsGWZZWkqxA+o9NU2EzZWKcY48VwWXsMhf 9R/1arumH3VGkmYPlRdoyuvdfRR243iht9f1ytnKsALEj491KgMlXoE94AcB5ZF3lP 6R3Fugaf4Uc3T3PnRi+s8pw4apgcJy6BwZ8IlIIoHCpJF/diBZ5ZdSMfY3XUz+9rOD NdBsIdtku19bJEoGgYqh5WRKIx/K6jNcJNWBMtph978/S1Uj45c8s+6+5CEZacjx8c K0nd2zLJ8DCjA== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/jDwU52dL54Psiyv0KIYe1bofL5I Cc: salud@ietf.org Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 19:35:53 -0000 > From: Christer Holmberg > > From: worley@ariadne.com (Dale R. Worley) > > > From: Christer Holmberg > > > > > > 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. > > 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. > > 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 > > From: worley@ariadne.com (Dale R. Worley) > > > From: Christer Holmberg > > > > Section 4.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. > > 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." Which is essentially the same as my version, so we're all agreed on that. > From: Christer Holmberg > > From: worley@ariadne.com (Dale R. Worley) > > > From: Christer Holmberg > > > Section 4.2: > > > --------------- > > > 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? > > > > 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). > > 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? 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. > > 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. > > 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. > > From: Laura Liess > > "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." 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? Repeating: > 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. 4.2. Proxies May Alter Alert-Info Header Fields 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. 4.2. Proxies May Alter Alert-Info Header Fields 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 nobody Wed Sep 10 23:51:31 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A12C1A04B0 for ; Wed, 10 Sep 2014 23:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yus1XFCikHWh for ; Wed, 10 Sep 2014 23:51:27 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936E01A0453 for ; Wed, 10 Sep 2014 23:51:26 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-99-5411466c31e7 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 16.8C.02247.C6641145; Thu, 11 Sep 2014 08:51:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Thu, 11 Sep 2014 08:51:23 +0200 From: Christer Holmberg To: "Dale R. Worley" , Laura Liess Thread-Topic: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 Thread-Index: Ac/IFf+gMZjC49hSQeiq/vmrqzhpOAECnhIAAA0sVGIAJFGJAAAR/8GHABZAk5A= Date: Thu, 11 Sep 2014 06:51:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D443180@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se> <201409101935.s8AJZn21031578@hobgoblin.ariadne.com> In-Reply-To: <201409101935.s8AJZn21031578@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+JvjW6Om2CIwd63ahZzrhha3O04wGjx 8kSZA7PH5P1fmT2eTpjM7rFkyU+mAOYoLpuU1JzMstQifbsErow9U+6yFkzPrXh9X7CB8Uto FyMnh4SAicSfIxPYIGwxiQv31gPZXBxCAkcZJVb+OswM4SxhlDg4YzVjFyMHB5uAhUT3P22Q BhGBCIlz7+ezgNjMAqoSe28vYQKxhQW8JZbf/8MMUeMjcXv7WyjbT2Ldlt8sIGNYgOr7r2WD hHkFfCUeH+thgVh1lUniZucJRpAEp4CDxKutW8FmMgId9/3UGiaIXeISt57MZ4I4WkBiyZ7z zBC2qMTLx/9YIWwliR8bLkHdpiOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0zELS MgtJywJGllWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgdF0cMtvqx2MB587HmIU4GBU4uFN sBIMEWJNLCuuzD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjLMum9au e/tvcgjbo2QbswNaHTcDdW7MM3kfmGy9+uA7IXbJ3Z962EIzf2/SOKE44T+rZ+z82Af+vYef u8nW/pq45Z52Sp94se1ah/4UtsYFbAv+hYXttM6d+Etth85L3tq7e1n8rxbGbXmSklVtteV0 eYHSgfIKg6LLjRp55yINldMiV6vUKLEUZyQaajEXFScCAMg65PCHAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/salud/Y6jNlLD_JvKntnKwzaWuTdtVAMU Cc: "salud@ietf.org" Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 06:51:29 -0000 Hi, >>>> As it is now allowed to use the Alert-Info header field in any >>>> non-100 provisional response, I assume the value could actually=20 >>>> change from one response to another. >>> >>> It seems to me that the best place to insert this would be at the=20 >>> end of section 13, where we are stating the rules for UAs regarding=20 >>> rendering Alert-Info. We could add a paragraph at the end: >>>=20 >>> Different provisional responses (even within one early dialog) may >>> have different Alert-Info header field values. Each Alert-Info hea= der >>> 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 th= at >>> are received earlier. >>=20 >> I was actually assuming that, when you receive a new Alert-Info, you=20 >> would "disable" whatever rendering the previous triggered. >>=20 >> For example, if I receive a 181 with a call-forwarding-urn, and later=20 >> a 180 with a called-party-alerting-urn, why would I keep rendering the=20 >> 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 perfor= ming=20 > 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 fo= r the two 180s that you receive. That seems to be how situations in the PS= TN work if two destination telephone systems deal with the call simultaneou= sly. > > If you have a visual display, and the renderings are text fragments, simp= ly 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=20 >> behave as you expect? We would need to define how different urns=20 >> interact with each other, and I don't think we want to go down that=20 >> 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 devel= oping good logic for handling multiple responses. My goal with that text i= s to allow freedom for the UA=20 > 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 render= ings that they specify, and (2) later=20 > information is "prefered" relative to earlier information. That second r= ule 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 a= n implementation issue how URNs received on different dialogs are treated, = and how/if they interact. > From: Laura Liess > > From: worley@ariadne.com (Dale R. Worley) > > > From: Christer Holmberg >=20 > > > Section 4.1: > > > --------------- > > >=20 > > > > > >=20 > > > This is pure editorial, but for alignment purpose I suggest to=20 > > > change "in all provisional responses..." to "in any non-100=20 > > > provisional response..." > >=20 > > I believe the text you are referring to is: > >=20 > > 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). > >=20 > > I think you mean to revise it to: > >=20 > > 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. > >=20 > > I agree that the latter reads better. > > New text for the first paragraph of section 4.1: >=20 > "This specification changes the usage of the Alert-Info header field=20 > defined in [RFC3261] by additionally allowing its use in any non-100=20 > provisional response to INVITE." Which is essentially the same as my version, so we're all agreed on that. >>>> 4.2: >>>> --------------- >>>> This section is below the "Updates to RFC 3261" section, but it is=20 >>>> unclear exactly what is updated. >>>>=20 >>>> The first paragraph of section 20.4/RFC 3261 already says that a=20 >>>> proxy can insert a A-I header. If you want to explicitly say that=20 >>>> a proxy can also modify an existing header, shouldn't that be text=20 >>>> that you add to e.g. the same paragraph? >>>=20 >>> The problem is that it is actually a modification to the rules=20 >>> governing proxies, forwarding requests (section 16.6 item 1) and=20 >>> forwarding responses (section 16.7 item 9), both of which forbid >>> *removing* header field values (except Via in responses). >>>=20 >>> I hear what you are saying. >>>=20 >>> However, I think we have already broken those rules in the past. For=20 >>> example, RFC 3325 specifies that a proxy can remove a=20 >>> P-Preferred-Identity header field, and that RFC does not update RFC=20 >>> 3261. >>>=20 >>> Also, RFC 3329 specifies that a proxy can remove the Require and=20 >>> Proxy-Require header field, after it has removed the security=20 >>> option-tags, and there are no option-tags left. >>> >>> So, while the fact that we have done something in the past doesn't=20 >>> automatically justify us to do it again, I just wonder whether it=20 >>> would be the end of the world? >> >> Looking at 3325 and 3329, there are a number of places where they specif= y header fields to be removed, and neither of them provides indication of w= hat 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 :) >>> The text of 20.4 allows a proxy to *insert* Alert-Info. That can be=20 >>> 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. >>>=20 >>> Given how long and complicated those sections are, it's rather=20 >>> awkward to edit the change into those sections textually. >>>=20 >>> But I can see the value of pointing out what specifically is changed. >>> Perhaps this would suffice? (I am also including the wording change=20 >>> you suggest in the second item, because it seems to apply to this=20 >>> item as well.) >>>=20 >>> 4.2. Proxies May Alter Alert-Info Header Fields >>>=20 >>> 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. >>=20 >> Don't you mean "add or remove an Alert-Info header field"? >>=20 >> Also, I think you could remove "1xx", and say "non-100 provisional=20 >> response". >>=20 >> I don't have any strong preference, as long as it is clear what we=20 >> update. But, perhaps we should ask the SIPCORE folks (that's mostly us=20 >> :) whether we really would need to go down the path and update=20 >> sections 16.6 and 16.7, or whether we e.g. in section 20.4 could=20 >> simply say that a proxy can remove the header field. >>=20 >> From: Laura Liess >>=20 >> "Following text is added after the first paragraph of section 20.4 >> [RFC3261]: >>=20 >> A SIP proxy MAY add or remove header field values in an Alert-Info=20 >> 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 proxi= es=20 > 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 textua= l amendment to RFC 3261." then Laura's change seems to be a good=20 > one, as any attempt to track down all statements regarding Alert-Info wil= l find it. And it does not involve textually editing the words of=20 > sections 16.6 and 16.7, which would be quite unpleasant -- but just as ab= ove, it requires the reader to semantically combine the amendment=20 > 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? > >Repeating: > 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 automat= ically=20 > removes the last header field (as a header field with no values is not al= lowed syntactically). > And if there are no Alert-Info header fields, adding one value will creat= e 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 remov= ed, then the header field itself is also removed. I don't think it would hu= rt to explicitly say that also in this draft - at least as a note.=20 > 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=20 > Alert-Info "header field", which consists of "header field rows" (each of= which is what is ordinarily called a "header"), with each row containing o= ne 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. > > 4.2. Proxies May Alter Alert-Info Header Fields > > 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 poss= ibilities 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. > > 4.2. Proxies May Alter Alert-Info Header Fields > > 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. 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 s= hould 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 nobody Fri Sep 12 12:43:50 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BBD1A0047 for ; Fri, 12 Sep 2014 12:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSzMjEZ_4DXj for ; Fri, 12 Sep 2014 12:43:48 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884D91A000F for ; Fri, 12 Sep 2014 12:43:48 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by resqmta-ch2-05v.sys.comcast.net with comcast id qJo21o0010vyq2s01KjnVK; Fri, 12 Sep 2014 19:43:47 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta05.westchester.pa.mail.comcast.net with comcast id qKjn1o00C1KKtkw3RKjnpz; Fri, 12 Sep 2014 19:43:47 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s8CJhk9s013343; Fri, 12 Sep 2014 15:43:46 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s8CJhjoS013342; Fri, 12 Sep 2014 15:43:45 -0400 Date: Fri, 12 Sep 2014 15:43:45 -0400 Message-Id: <201409121943.s8CJhjoS013342@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D443180@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se> <201409101935.s8AJZn21031578@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D443180@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410551027; bh=Tfn5jlD8Wof+1Tpq+QtwpNaIxoDdJiZRLZQLydaY0Us=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=bj7GOzigVwhmiAxfWkBvdpfwXJtUN1UMTI++5q1aUpVCZdpAafyPQFm/AjUQYRA6B 5nUuW1UPK62DBjXKAi9HjmxInx8iHCEG4QK1gavQI7r2Wk2FTnVfMc0yr03vwGrA37 +uFTYyDX5nsRPHOfeCpPl/qmGgmCDPFhXiulgo0RL/a21/YQTNHxLjpm2su1+Im9+6 A6g+DISoauhpT3ur3brJXi/5PMFIex0XhPZzVW8JI1yHibjJN7fCKWDqMLMEblGKVN TDGpi7YwbgtHXouTgSBN+hx5JuN8G2MBFf+jlqTiTz2i3NqfaZcRa53gkRDPWUhUXx pYAd/Pzq3sMPw== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/r_M6z-RsD2dPBAVKQxfB7hjdcJY Cc: salud@ietf.org Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 19:43:49 -0000 > From: Christer Holmberg > 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 nobody Sat Sep 13 01:28:59 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10C61A87AE for ; Sat, 13 Sep 2014 01:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnND4afR3MKt for ; Sat, 13 Sep 2014 01:28:56 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4DB1A87B2 for ; Sat, 13 Sep 2014 01:28:55 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-01-541400458eca Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7C.B7.21334.54004145; Sat, 13 Sep 2014 10:28:54 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Sat, 13 Sep 2014 10:28:53 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 Thread-Index: Ac/IFf+gMZjC49hSQeiq/vmrqzhpOAECnhIAAA0sVGIAJFGJAAAR/8GHABZAk5AATpvdCgAaoUmg Date: Sat, 13 Sep 2014 08:28:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D449E7C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se> <201409101935.s8AJZn21031578@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D443180@ESESSMB209.ericsson.se> <201409121943.s8CJhjoS013342@hobgoblin.ariadne.com> In-Reply-To: <201409121943.s8CJhjoS013342@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvja4bg0iIwYT7jBZzrhha3O04wGjx 8kSZA7PH5P1fmT2eTpjM7rFkyU+mAOYoLpuU1JzMstQifbsErozZD6awFExgrXh7ZhNbA+N/ 5i5GTg4JAROJzjPNTBC2mMSFe+vZuhi5OIQEjjJKLLi5nhEkISSwhFHi1wKtLkYODjYBC4nu f9ogpoiApkTHghyQCmaBDInbFw6DjREW8JZYfv8P2HgRAR+J29vfQtlREk+/LQSbyCKgKtFy 7iY7iM0r4Cvx5tIdVoi155klbnU1MYHM5xRwkDj30xWkhhHotO+n1jBB7BKXuPVkPtTJAhJL 9pyHekVU4uXjf6wQtpJE45InrBD1OhILdn9ig7C1JZYtfM0MsVdQ4uTMJywTGMVmIRk7C0nL LCQts5C0LGBkWcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGEsHt/zW3cG4+rXjIUYBDkYl Ht6Eu8IhQqyJZcWVuYcYpTlYlMR5F52bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0WfC pZXW/LET9rN1nrd9cuG8rY7gilsO19c/Kzl3+MV+yXf/BV9zbFKZv0O7b/aWB63vEtMj/UMa NWNFxSNTqy2a1a/+6LqhuXOvok1ir1NmBdv+QPvNyU9SVlVkTTy8rGbe6vMb2I7/CP0owthh GyXFMzE6ludRZrhNwgl5d/eMlOBDMblJSizFGYmGWsxFxYkAxpz7boYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/salud/O8Aa-aRIfitusLgMb_Vk7G89egk Cc: "salud@ietf.org" Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 08:28:57 -0000 Hi, >> That's my point: we could say that a proxy can remove the Alert-Info=20 >> 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 do= ne 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 fi= eld values, and that's it. Regards, Christer From nobody Fri Sep 19 04:15:49 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6C41A00C2 for ; Fri, 19 Sep 2014 04:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYikuw3Sqmit for ; Fri, 19 Sep 2014 04:15:21 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675361A00AD for ; Fri, 19 Sep 2014 04:15:20 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id n15so1044875lbi.29 for ; Fri, 19 Sep 2014 04:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bbN2h0ypukOnbZw6tG38AJX4efvHIhC6Va4vXxhmwhs=; b=TsESfKmS+W1Z/1N2MdSwhJr60OizzsRdVWmiW//zRIc/Mdw3vrQxKEuy5AKJTZyrRT spT+NhU/oXg4QQwmZlmZ1tNecRbwVXcBzIvltKJ2Vqhs6+BdaVKx7bzJSODGx3gIRc7Q OAOInJjWKyz0al+HJbqBB8j/gcqCN7HaHHbe5lCLa6RasUH2Q1NjnJeOFAGoC2OjdCmg fJzwiazuqdWoDU29+bwWQdXWRiBBWhiB5USgEVUQHxDNQ2/yEWwh/WX2U/YPFTes0iBM 8vrI5aOPtGNxkLMLWpWFk4vy4AHNWD7PbUnkRypNFe8Tc6tvmWhaVx7hPQb7GI61cR6M rdQw== MIME-Version: 1.0 X-Received: by 10.152.6.40 with SMTP id x8mr6134573lax.18.1411125318627; Fri, 19 Sep 2014 04:15:18 -0700 (PDT) Received: by 10.114.77.227 with HTTP; Fri, 19 Sep 2014 04:15:18 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D449E7C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se> <201409101935.s8AJZn21031578@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D443180@ESESSMB209.ericsson.se> <201409121943.s8CJhjoS013342@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D449E7C@ESESSMB209.ericsson.se> Date: Fri, 19 Sep 2014 13:15:18 +0200 Message-ID: From: Laura Liess To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0141a02059b5c10503693766 Archived-At: http://mailarchive.ietf.org/arch/msg/salud/RpQ4iwcslRPkcJeTXKFw8Edq4nI Cc: "salud@ietf.org" Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 11:15:24 -0000 --089e0141a02059b5c10503693766 Content-Type: text/plain; charset=ISO-8859-1 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 : > Hi, > > >> 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. > > 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 > > --089e0141a02059b5c10503693766 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Christer, Dale,

I put my curre= nt understanding of the discussion outcome into the text modifications belo= w. Please look at it and let me know your opinion.

- Iss= ue 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 Initia= tion 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 o= r remove an Alert-Info  header field, and to add or remove Alert-Info he= ader field values."

  &n= bsp;  - It is not clear to me if we completly drop Section 4.2 or if w= e keep it with the new text:
"A SIP proxy MAY add or remove an Ale= rt-Info header field, and MAY add or remove Alert-Info header field values, in a SIP request or a non-100 provisional res= ponse."

   &n= bsp;   - 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 rem= ove Alert-Info header field values, in a SIP request or a  non-100 provision= al response when it needs to modify the  information about the call or about the provided servi= ces."
<= /div>

 

 

-  Issue “Gene= ral”:  New text at the end of Section 13 &ldq= uo;User Agent Behaviour”

“Subsequent provisional responses, e= ven 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  indepe= ndently.  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 respons= es 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 <christer.holm= berg@ericsson.com>:
Hi,

>> That's my point: we could say that a proxy can remove the Aler= t-Info
>> header field - without saying anything about updating 3261 :)
>
> It seems to me that if we're going to have a section which describ= es the normative changes to 3261, > it should list every normative chang= e 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 32= 61. We simply say that a proxy can remove the Alert-Info header field/heade= r field values, and that's it.

Regards,

Christer


--089e0141a02059b5c10503693766-- From nobody Fri Sep 19 13:46:56 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A031A876F for ; Fri, 19 Sep 2014 13:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuUVVFk3Jq4d for ; Fri, 19 Sep 2014 13:46:51 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E0C1A88A4 for ; Fri, 19 Sep 2014 13:46:51 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by resqmta-ch2-10v.sys.comcast.net with comcast id t8kf1o0010cZkys018mqNo; Fri, 19 Sep 2014 20:46:50 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta10.westchester.pa.mail.comcast.net with comcast id t8mm1o00E1KKtkw3W8moEJ; Fri, 19 Sep 2014 20:46:49 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s8JKkf3j026751; Fri, 19 Sep 2014 16:46:41 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s8JKkdSR026744; Fri, 19 Sep 2014 16:46:39 -0400 Date: Fri, 19 Sep 2014 16:46:39 -0400 Message-Id: <201409192046.s8JKkdSR026744@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Laura Liess In-reply-to: (laura.liess.dt@googlemail.com) References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se> <201409101935.s8AJZn21031578@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D443180@ESESSMB209.ericsson.se> <201409121943.s8CJhjoS013342@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D449E7C@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1411159610; bh=PBt5PbO84xsaf0WYB809mF/zogZxAJ8L6TguNONWTlM=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=ftFtCYsKW23MjiU19t4BVZUANwUWekD/NaPNE7U1JaswDTRCsi2CuT3Y1IlWEzB5a vKRrGo9E6iXb0ysoFVK8udqLdkTCIRebegoeR3IpRn/9CgOOjV2fc9nZN5yC6YMiwL xKvXVM/kPFLRvcip9/yPLHTmtO90DoRmI7xLTGlKwlVYgtm+qLaTFms8ul1wiGD+Ip J8FyC1ajz3PeWmo5+KNWFjUJNDp87MR3steTtAkooOA3lNoZaicxSBGmMZ7MDnNLY2 sU7SBwFJ1AkxrEYZ0TqCpJsRXcZW9ZM5aRT769IdMAfFHWb+xSRKeOTx9M63FSZnHT v+Wu7fC9e86Mg== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/KKimZRJaX7TekOnu3OEI6u0N9NY Cc: salud@ietf.org Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:46:53 -0000 [as an individual] > From: Laura Liess > > I put my current understanding of the discussion outcome into the text > 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. > - 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 ^-----------------------^ This text is redundant and can be removed. > 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 Put this word in lower case. ------^ > 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 -------------^ I think we want "SHOULD" here. > 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." Dale From nobody Sat Sep 20 01:38:12 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F7B1A044F for ; Sat, 20 Sep 2014 01:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR6zuGN3s95f for ; Sat, 20 Sep 2014 01:38:08 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D901A005B for ; Sat, 20 Sep 2014 01:38:07 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-6f-541d3ceca04d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AE.3D.02247.CEC3D145; Sat, 20 Sep 2014 10:38:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Sat, 20 Sep 2014 10:38:04 +0200 From: Christer Holmberg To: Laura Liess Thread-Topic: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 Thread-Index: Ac/IFf+gMZjC49hSQeiq/vmrqzhpOAECnhIAAA0sVGIAJFGJAAAR/8GHABZAk5AATpvdCgAaoUmgAS91ZAAAMPKqoA== Date: Sat, 20 Sep 2014 08:38:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D454AAB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se> <201409101935.s8AJZn21031578@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D443180@ESESSMB209.ericsson.se> <201409121943.s8CJhjoS013342@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D449E7C@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D454AABESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3RvetjWyIwZVqizlXDC3udhxgtHh5 osyB2WPy/q/MHk8nTGb3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxpV9E5gK7qVVLF08mbWB8UVk FyMHh4SAicThezldjJxAppjEhXvr2UBsIYGjjBKPLql0MXIB2UsYJdrPTGQFqWcTsJDo/qcN UiMioC9xou8jO4jNLOAjsWHfXxYQW1jAW2L5/T/MEDU+Ere3v4WysyROH90NZrMIqErcWvaW BWQkr4CvxNxdCRCrbrFI/N67D6yGUyBQYnHvY7D5jEC3fT+1hglil7jErSfzmSBuFpBYsuc8 M4QtKvHy8T9WCFtJonHJE1aI+nyJxk89YH/xCghKnJz5hGUCo+gsJKNmISmbhaQMIq4jsWD3 JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2IULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjLyDW35b 7WA8+NzxEKMAB6MSD++C+zIhQqyJZcWVuYcYpTlYlMR5F56bFywkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBsetT1XPn6yVLtRfqLP8vMP9JsOaa83OfdK16zGfeXHZP/PrBRX4/G/KyeMt5 ducLnr52aWnVxDtr3dqPS09k3Vh8Q/j87a+P/145U3Qo7/3kEo1vCz5/LLlwlrlKb0HAejce vnMChyo+iDDXK3jvu3E+rrRvsozNwVU/G3/9e7fz/I28T1WZ3+uUWIozEg21mIuKEwFQFjDS nQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/ft3E9xgFQIDLQUNXEqqq2iTcq-c Cc: "salud@ietf.org" Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 08:38:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D454AABESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Laura, - Issue 4.2 : - New text for Section "Abstract", second paragraph: "This document normatively updates RFC 3261, which defines the Session Init= iation 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 provisi= onal response to INVITE (except the 100 response).This document also permit= s proxies to add or remove an Alert-Info header field, and to add or remov= e Alert-Info header field values." I suggest you remove "except the 100 response". You already say "non-100 pr= ovisional 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 r= emove Alert-Info header field values, in a SIP request or a non-100 provisi= onal 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 r= emove Alert-Info header field values, in a SIP request or a non-100 provis= ional response when it needs to modify the information about the call or a= bout the provided services." - Issue "General": New text at the end of Section 13 "User Agent Behaviou= r" "Subsequent provisional responses, even within the same dialog, may cont= ain different Alert-Info header field values. The Alert-Info header fie= ld values received within different Provisional responses are treated inde= pendently. If subsequent provisional responses containing different Alert= -Info header field values were received within the same dialog, the User Ag= ent should render at anytime the last received Alert-Info header field valu= e. The handling of provisional responses containing different Alert-Info h= eader field values which were not received within the same dialog is left a= s an implementation issue." Thank you Laura 2014-09-13 10:28 GMT+02:00 Christer Holmberg >: Hi, >> 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 do= ne 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 fi= eld values, and that's it. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D454AABESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

- Issue 4.2 :

     - New text for Section &quo= t;Abstract", second paragraph:

"This document normatively updates RFC 3261, which defi= nes the Session Initiation Protocol (SIP): It changes the usage of the Aler= t-Info header field defined in RFC 3261 by additionally allowing its use <= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,"sans-serif"">in any non-100 provisional response to INVITE (except the 100 response).This document also permits prox= ies to add or remove an Alert-Info  header field, and to add or remove= Alert-Info header field values."

 

I suggest you remove R= 20;except the 100 response”. You already say “non-100 provision= al response”, so…

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

     - 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 ad= d or remove an Alert-Info header field, and MAY add or remove Alert-Info he= ader field values, in a SIP request or a non-100 provisional response."

 

   &nb= sp;   - Section  14 "Proxy Behaviour". First paragr= aph is replaced by:

"A SIP proxy MAY add or remove an Alert-Info hea= der field, and MAY add or remove Alert-Info hea= der field values, in a SIP request or a  non-100 provisional response whe= n it needs to modify the  information about the call or about the prov= ided services."

 

 

 

-  Issue “General”:  Ne= w text at the end of Section 13 “User Agent Behaviour”

“S= ubsequent provisional responses, even within the same dialog, may &nbs= p;  contain different Alert-Info header field values.  The Alert-= Info header    field values received within different Provis= ional responses are treated  independently.  If subsequent provisional responses= containing  different Alert-Info header field values were received wi= thin the same dialog, the User Agent should render at anytime the last rece= ived Alert-Info header field value. The handling of provisional responses containing  different Alert-Info header fiel= d values which were not received within the same dialog is left as an imple= mentation issue.”

 

Thank you

Laura

 

 

2014-09-13 10:28 GMT+02:00 Christer Holmberg <= ;christ= er.holmberg@ericsson.com>:

Hi,

>> That's my point: we could say that a proxy can remove the Alert-In= fo
>> header field - without saying anything about updating 3261 :)
>
> It seems to me that if we're going to have a section which describes t= he 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 pas= t 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 fi= eld values, and that's it.

Regards,

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D454AABESESSMB209erics_-- From nobody Sun Sep 21 05:01:45 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E3B1A00B2 for ; Sun, 21 Sep 2014 05:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df7S-LfXbHzH for ; Sun, 21 Sep 2014 05:01:37 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18841A00A6 for ; Sun, 21 Sep 2014 05:01:35 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id u10so5393246lbd.27 for ; Sun, 21 Sep 2014 05:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pj8fj9cXz/2ZCC8kjdQkHLMoNcL8F1oVyRbV36Kggpk=; b=CwDsrDCNArVk06gHnwnrgzckSdoZKhinvj07Nyp4dph2g+5pLhaQDNohrkP+aUbC9Y bcwYfD/0UikTReUBl92x1FXNIBn6KDql21cgnaLvfbN4zG8+JKW3Wt600Q5GZYcmnBQG z/JdpkvcD0BTU6OGnmLuWWkcNIjsRLePw2WIMq3iRq/EEPoqUWdhsBGZxaEhDWxoi1Pm w+O0sr1PzJhBad+4KnXqn7vXP6IutOkmNaN8vkT6pmDmrKjHK8AVIXoseVL0cl26VCxM jFpCBoJ8BjNRjLOIM25Wjcxoftc420o0hifroXjNm3lAq5dPFA091tRIhm9K27vxV9Zw kitA== MIME-Version: 1.0 X-Received: by 10.112.34.210 with SMTP id b18mr18129812lbj.62.1411300893908; Sun, 21 Sep 2014 05:01:33 -0700 (PDT) Received: by 10.114.77.227 with HTTP; Sun, 21 Sep 2014 05:01:33 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D454AAB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se> <201409101935.s8AJZn21031578@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D443180@ESESSMB209.ericsson.se> <201409121943.s8CJhjoS013342@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D449E7C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D454AAB@ESESSMB209.ericsson.se> Date: Sun, 21 Sep 2014 14:01:33 +0200 Message-ID: From: Laura Liess To: Christer Holmberg Content-Type: multipart/alternative; boundary=14dae93d938073e481050392185c Archived-At: http://mailarchive.ietf.org/arch/msg/salud/s0HJPsJK_sbg7t6rbKFTVfj5pLU Cc: "salud@ietf.org" Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 12:01:42 -0000 --14dae93d938073e481050392185c Content-Type: text/plain; charset=ISO-8859-1 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 : > 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 < > christer.holmberg@ericsson.com>: > > Hi, > > >> 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. > > 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 > > > --14dae93d938073e481050392185c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dale, Christer,

Thank you.&nbs= p; I hope to be able to publish version 14 by Tuesday.

Kind r= egards
Laura 

2014-09-20 10:38 GMT+02:00 Christer Holmberg <christer.holmberg@ericsson.com>:

Hi Laura,

 

- Issue 4.2 :

     - New text for Section &quo= t;Abstract", second paragraph:

"This document normatively updates RFC 3261, which defi= nes the Session Initiation Protocol (SIP): It changes the usage of the Aler= t-Info header field defined in RFC 3261 by additionally allowing its use <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif"" lang=3D"EN-US">in any non-100 provisional response to INVITE (except the 100 response).This document also permits prox= ies to add or remove an Alert-Info  header field, and to add or remove= Alert-Info header field values."

 

I suggest you remo= ve “except the 100 response”. You already say “non-100 pr= ovisional 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 ad= d or remove an Alert-Info header field, and MAY add or remove Alert-Info he= ader field values, in a SIP request or a non-100 provisional response."

 

   &nb= sp;   - Section  14 "Proxy Behaviour". First paragr= aph is replaced by:

"A SIP proxy MAY add or remove an Alert-Info hea= der field, and MAY add or remove Alert-Info hea= der field values, in a SIP request or a  non-100 provisional response whe= n it needs to modify the  information about the call or about the prov= ided services."

 

 

 

-  Issue “General&rd= quo;:  New text at the end of Section 13 “User Agent Behaviour&r= dquo;

“S= ubsequent provisional responses, even within the same dialog, may &nbs= p;  contain different Alert-Info header field values.  The Alert-= Info header    field values received within different Provis= ional responses are treated  independently.  If subsequent provisional responses= containing  different Alert-Info header field values were received wi= thin the same dialog, the User Agent should render at anytime the last rece= ived Alert-Info header field value. The handling of provisional responses containing  different Alert-Info header fiel= d values which were not received within the same dialog is left as an imple= mentation issue.”

 

Thank you

Laura

 

 

2014-09-13 10:28 GMT+02:00 Christer Holmberg <christer.h= olmberg@ericsson.com>:

Hi,

>> That's my point: we could say that a proxy can remove the Aler= t-Info
>> header field - without saying anything about updating 3261 :)
>
> It seems to me that if we're going to have a section which describ= es the normative changes to 3261, > it should list every normative chang= e 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 32= 61. We simply say that a proxy can remove the Alert-Info header field/heade= r field values, and that's it.

Regards,

Christer

 


--14dae93d938073e481050392185c-- From nobody Tue Sep 23 06:55:23 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44ABC1A1ADC for ; Tue, 23 Sep 2014 06:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_UoGPE0e0tb for ; Tue, 23 Sep 2014 06:55:19 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2811B1A010C for ; Tue, 23 Sep 2014 06:55:18 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id l4so8861117lbv.33 for ; Tue, 23 Sep 2014 06:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SAaTJ3PtdPyjbLo9P37tg0Yyjlfl7qQwBZlV/j1CvF8=; b=i6Cim4jzNhy3DF4CTuzI+pKdYqMQyA2X7ZHEbkYmQq98RCxW5OgbnGS5KlNWAWgSpL e39MMDgrNdk/GWKefRvSMWuZy3j5Uj+/cjhJDScoyI6hOx8+8x4CEGU68zcdgComLaHM lu2LLxZxssBa+3r8/4f/fD7okM293EfbSp9n1PB1+2Pnn6S3qXgeDSCzVL/4LFkda3XT XL62Zp0xVIwOL+pAESR/Y/8IEqlNsjmpS1O7P7YnV5eMY1gv39++YCCW6nwMVPU+cVkE 3cmCVTYn3Yqs5e0lU0ldlbAiGTSWRiBB+jHkpCK9i1xJt5C7zTSMEi+JvqYKsrr/HfY3 KWlg== MIME-Version: 1.0 X-Received: by 10.152.21.168 with SMTP id w8mr33607551lae.59.1411480517404; Tue, 23 Sep 2014 06:55:17 -0700 (PDT) Received: by 10.114.77.227 with HTTP; Tue, 23 Sep 2014 06:55:17 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se> <201409101935.s8AJZn21031578@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D443180@ESESSMB209.ericsson.se> <201409121943.s8CJhjoS013342@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B1D449E7C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D454AAB@ESESSMB209.ericsson.se> Date: Tue, 23 Sep 2014 15:55:17 +0200 Message-ID: From: Laura Liess To: Christer Holmberg , "salud@ietf.org" Content-Type: multipart/alternative; boundary=089e0158ad54d8ed630503bbea43 Archived-At: http://mailarchive.ietf.org/arch/msg/salud/EsLjOzmy6s9zQFZMCBVit0DLW7Q Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 13:55:21 -0000 --089e0158ad54d8ed630503bbea43 Content-Type: text/plain; charset=ISO-8859-1 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 : > 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 < > christer.holmberg@ericsson.com>: > >> 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 < >> christer.holmberg@ericsson.com>: >> >> Hi, >> >> >> 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. >> >> 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 >> >> >> > > --089e0158ad54d8ed630503bbea43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I promised to publish ver= sion 14 today. But it seems now that we still have an open issue with IANA&= nbsp; so I will wait for this issue to be clarified.

Thank yo= u
Laura

2014-09-21 14:01 GMT+02:00 Laura Liess <laura.liess.= dt@googlemail.com>:
Dale, Christer,

Thank you.  I ho= pe to be able to publish version 14 by Tuesday.

Kind regards<= span class=3D"HOEnZb">
Laura 

<= div class=3D"gmail_quote">2014-09-20 10:38 GMT+02:00 Christer Holmberg <christer.holmberg@ericsson.com>:

Hi Laura,

 

- Issue 4.2 :

     - New text for Section &quo= t;Abstract", second paragraph:

"This document normatively updates RFC 3261, which defi= nes the Session Initiation Protocol (SIP): It changes the usage of the Aler= t-Info header field defined in RFC 3261 by additionally allowing its use <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif"" lang=3D"EN-US">in any non-100 provisional response to INVITE (except the 100 response).This document also permits prox= ies to add or remove an Alert-Info  header field, and to add or remove= Alert-Info header field values."

 

I suggest you remo= ve “except the 100 response”. You already say “non-100 pr= ovisional 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 ad= d or remove an Alert-Info header field, and MAY add or remove Alert-Info he= ader field values, in a SIP request or a non-100 provisional response."

 

   &nb= sp;   - Section  14 "Proxy Behaviour". First paragr= aph is replaced by:

"A SIP proxy MAY add or remove an Alert-Info hea= der field, and MAY add or remove Alert-Info hea= der field values, in a SIP request or a  non-100 provisional response whe= n it needs to modify the  information about the call or about the prov= ided services."

 

 

 

-  Issue “General&rd= quo;:  New text at the end of Section 13 “User Agent Behaviour&r= dquo;

“S= ubsequent provisional responses, even within the same dialog, may &nbs= p;  contain different Alert-Info header field values.  The Alert-= Info header    field values received within different Provis= ional responses are treated  independently.  If subsequent provisional responses= containing  different Alert-Info header field values were received wi= thin the same dialog, the User Agent should render at anytime the last rece= ived Alert-Info header field value. The handling of provisional responses containing  different Alert-Info header fiel= d values which were not received within the same dialog is left as an imple= mentation issue.”

 

Thank you

Laura

 

 

2014-09-13 10:28 GMT+02:00 Christer Holmberg <christer.h= olmberg@ericsson.com>:

Hi,

>> That's my point: we could say that a proxy can remove the Aler= t-Info
>> header field - without saying anything about updating 3261 :)
>
> It seems to me that if we're going to have a section which describ= es the normative changes to 3261, > it should list every normative chang= e 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 32= 61. We simply say that a proxy can remove the Alert-Info header field/heade= r field values, and that's it.

Regards,

Christer

 



--089e0158ad54d8ed630503bbea43--