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

Laura Liess <laura.liess.dt@googlemail.com> Wed, 10 September 2014 13:00 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 80FEE1A6FD5 for <salud@ietfa.amsl.com>; 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 <salud@ietfa.amsl.com>; 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 <salud@ietf.org>; Wed, 10 Sep 2014 06:00:32 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id gi9so9766811lab.16 for <salud@ietf.org>; 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> <CACWXZj0e8pdneJq_d+Cug86R8J+SHdwEyXFaxFs19hVWMNXLpA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D4411D8@ESESSMB209.ericsson.se>
Date: Wed, 10 Sep 2014 15:00:30 +0200
Message-ID: <CACWXZj2aKOVuMkF5yZS5-LeZDXq=GL3-u5SYW0BSRq2DWWfV_A@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=089e013d1708030dbe0502b5a3e2
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/oplt90gOj2MoneIcmuRhAu69BLc
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: Wed, 10 Sep 2014 13:00:43 -0000

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 <christer.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 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:
>>
>> -----------
>>
>>
>>
>> <QG_1>
>>
>>
>>
>> As it is now allowed to use the Alert-Info header field in any non-100
>> provisional response, I assume the value could actually change from one
>>
>> response to another.
>>
>>
>>
>> Eventhough RFC3261 does not explicitly forbid it, perhaps it would be
>> good to explicitly mention that in this draft, because I assume there could
>> be use cases where
>>
>> e.g. one value is received in a 181, and another value in a subsequent
>> 180.
>>
>>
>>
>> </QG_1>
>>
>>
>>
>
>
>
>>
>>
>> Section 4.1:
>>
>> ---------------
>>
>>
>>
>> <Q4-1_1>
>>
>>
>>
>>                 This is pure editorial, but for alignment purpose I
>> suggest to change "in all provisional responses..." to "in any non-100
>> provisional response..."
>>
>>
>>
>> </Q4-1_1>
>>
>>
>>
>>
>>
>> Section 4.2:
>>
>> ---------------
>>
>>
>>
>> <Q4-2_1>
>>
>>
>>
>> This section is below the "Updates to RFC 3261" section, but it is
>> unclear exactly what is updated.
>>
>>
>>
>> The first paragraph of section 20.4/RFC 3261 already says that a proxy
>> can insert a A-I header. If you want to explicitly say
>>
>> that a proxy can also modify an existing header, shouldn't that be text
>> that you add to e.g. the same paragraph?
>>
>>
>>
>>
>>
>> </Q4-2_1>
>>
>>
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>> _______________________________________________
>> salud mailing list
>> salud@ietf.org
>> https://www.ietf.org/mailman/listinfo/salud
>>
>>
>