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

Laura Liess <laura.liess.dt@googlemail.com> Tue, 09 September 2014 13:23 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 4AE031A02F1 for <salud@ietfa.amsl.com>; 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 <salud@ietfa.amsl.com>; 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 <salud@ietf.org>; Tue, 9 Sep 2014 06:23:26 -0700 (PDT)
Received: by mail-la0-f42.google.com with SMTP id hz20so4468421lab.15 for <salud@ietf.org>; 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, 09 Sep 2014 15:23:24 +0200
Message-ID: <CACWXZj0e8pdneJq_d+Cug86R8J+SHdwEyXFaxFs19hVWMNXLpA@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="001a1135fb420d18510502a1d754"
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/eKq5WWdMNQHrNNENlz-SBQX5CU4
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: Tue, 09 Sep 2014 13:23:29 -0000

Hi Christer,

Thank you very much for the comments.

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

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

Thank you
Laura




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