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

worley@ariadne.com (Dale R. Worley) Fri, 19 September 2014 20:46 UTC

Return-Path: <worley@ariadne.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 02A031A876F for <salud@ietfa.amsl.com>; 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 <salud@ietfa.amsl.com>; 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 <salud@ietf.org>; 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 <laura.liess.dt@googlemail.com>
In-reply-to: <CACWXZj0gdum8U6tHz_f5H4v+cDw0s_feTJ3PktKMtQ-Qr0Mx+g@mail.gmail.com> (laura.liess.dt@googlemail.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>
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 <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 20:46:53 -0000

[as an individual]

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