Re: [salud] Normative change to proxy behavior

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 16 May 2014 22:55 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 D06601A017B for <salud@ietfa.amsl.com>; Fri, 16 May 2014 15:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 28pC9mKcwID9 for <salud@ietfa.amsl.com>; Fri, 16 May 2014 15:55:24 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD551A0144 for <salud@ietf.org>; Fri, 16 May 2014 15:55:24 -0700 (PDT)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta10.westchester.pa.mail.comcast.net with comcast id 2mor1o0011uE5Es5AmvGNQ; Fri, 16 May 2014 22:55:16 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id 2mvG1o00N3ZTu2S3cmvGCD; Fri, 16 May 2014 22:55:16 +0000
Message-ID: <53769754.2030404@alum.mit.edu>
Date: Fri, 16 May 2014 18:55:16 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: salud@ietf.org
References: <201405162159.s4GLxt4x010778@hobgoblin.ariadne.com>
In-Reply-To: <201405162159.s4GLxt4x010778@hobgoblin.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1400280916; bh=fiNvWtg5UJzXioN3DMaBP1LVZUc7kiZAAXMPbfIfEcc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ByR748JN1R3b5RXWSOvnH/e5Qbk8g8iRHzVIw1ovhOD9x9ikSkSBdDPe6Anwq7Se0 iQXFffgm4/+t1Rjm2uohdjATa97XNPDTLduNg/mpvSpyBQM8cwxgt5XZG2JbwFK5DI doCxOZbyWnOCp9eeJwdNV2/Qby51o8xaVGMEnJyK+zd+1CjbKoekzLezhlolujEkf3 YD1q9loZC9rubTol7KCuJF6INDATV7AAxKwFU+2jlBexW8Wj2NfAXQmkio0Ei7sqIA 9HoJjCDBfRIlNiNDzhxtsK7AfT0zFrEpB1jov3sWJIsZtnutnl6js7uKVCxxBY/nrw NmLCZ5PBP+Q3g==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/Yck7oecO78fnwbSZ2xXfgdU9mqo
Subject: Re: [salud] Normative change to proxy behavior
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, 16 May 2014 22:55:26 -0000

Yes, I think we should. It is preferable to pretending that inserting 
conflicting values is the recommended alternative.

	Thanks,
	Paul

On 5/16/14 5:59 PM, Dale R. Worley wrote:
> Since we're being particular about listing normative changes, I
> thought we'd want to be more explicit about the change we're
> permitting for proxies:
>
>     14.  Proxy Behaviour
>
>     A A SIP proxy MAY add an Alert-Info header field if none is present,
>     and MAY add or remove URNs to an Alert-Info header field in a SIP
>     request or a provisional 1xx response (excepting a 100 response) when
>     it needs to provide additional information about the call or about
>     the provided service.
>
> By 3261, proxies are allowed to append a new header field value to a
> header field that allows multiple values.  (This is done by an implied
> redirection to an internal UA which provides a 4xx response with
> "Contact:  <whatever?Alert-Info=urn:alert:additional:value>".)  But
> removing header field values is not generally allowed.  Section 14 of
> our draft enables removing values and adding values that are not at
> the end of the value list.
>
> We should document this change in the final paragraph of the abstract
> and section 4 by adding something like this:
>
>     Abstract
>
>     This document normatively updates the RFC 3261, which defines the
>     Session Initiation Protocol (SIP): It changes the usage of the Alert-
>     Info header field defined in the RFC 3261 by additionally allowing
>     its use in all provisional responses to INVITE (except the 100
>     response).
> +  This document also permits proxies to add and remove header field
> +  values from the Alert-Info header field.
>
>     4.  Update to RFC 3261
>
> +  4.3.  Proxies may alter Alert-Info header fields
> +
> +  A SIP proxy MAY add or remove URNs to an Alert-Info header field in
> +  a SIP request or a provisional 1xx response (excepting a 100
> +  response).
>
> Dale
>
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>