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

Laura Liess <laura.liess.dt@googlemail.com> Tue, 23 September 2014 13:55 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 44ABC1A1ADC for <salud@ietfa.amsl.com>; 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 <salud@ietfa.amsl.com>; 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 <salud@ietf.org>; Tue, 23 Sep 2014 06:55:18 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id l4so8861117lbv.33 for <salud@ietf.org>; 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: <CACWXZj13q0oLAHV1CopmmRQvhM4U5N8XxE63dyrUssuq==ZWpw@mail.gmail.com>
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> <CACWXZj0gdum8U6tHz_f5H4v+cDw0s_feTJ3PktKMtQ-Qr0Mx+g@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D454AAB@ESESSMB209.ericsson.se> <CACWXZj13q0oLAHV1CopmmRQvhM4U5N8XxE63dyrUssuq==ZWpw@mail.gmail.com>
Date: Tue, 23 Sep 2014 15:55:17 +0200
Message-ID: <CACWXZj36KHjPdKfARqvjYa_+d7H2eKPR_A8MWpO-b2MqGkT9bA@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "salud@ietf.org" <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 <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: Tue, 23 Sep 2014 13:55:21 -0000

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 <laura.liess.dt@googlemail.com>;:

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