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

Laura Liess <laura.liess.dt@googlemail.com> Fri, 19 September 2014 11:15 UTC

Return-Path: <laura.liess.dt@googlemail.com>
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 <salud@ietfa.amsl.com>; 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 <salud@ietfa.amsl.com>; 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 <salud@ietf.org>; Fri, 19 Sep 2014 04:15:20 -0700 (PDT)
Received: by mail-lb0-f170.google.com with SMTP id n15so1044875lbi.29 for <salud@ietf.org>; 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> <CACWXZj0e8pdneJq_d+Cug86R8J+SHdwEyXFaxFs19hVWMNXLpA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se> <CACWXZj2aKOVuMkF5yZS5-LeZDXq=GL3-u5SYW0BSRq2DWWfV_A@mail.gmail.com> <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: <CACWXZj0gdum8U6tHz_f5H4v+cDw0s_feTJ3PktKMtQ-Qr0Mx+g@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=089e0141a02059b5c10503693766
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/RpQ4iwcslRPkcJeTXKFw8Edq4nI
Cc: "salud@ietf.org" <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 <salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>, <mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/salud/>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>, <mailto:salud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Sep 2014 11:15:24 -0000

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