Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 22 March 2016 18:31 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648E012D78F for <dispatch@ietfa.amsl.com>; Tue, 22 Mar 2016 11:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 8MRnScHdBCdl for <dispatch@ietfa.amsl.com>; Tue, 22 Mar 2016 11:31:19 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F9112D132 for <dispatch@ietf.org>; Tue, 22 Mar 2016 11:31:18 -0700 (PDT)
Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-08v.sys.comcast.net with comcast id Z6WJ1s0042Fh1PH016XHbC; Tue, 22 Mar 2016 18:31:17 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-08v.sys.comcast.net with comcast id Z6XH1s00E3KdFy1016XHEq; Tue, 22 Mar 2016 18:31:17 +0000
To: dispatch@ietf.org
References: <21379_1458588251_56F04A5B_21379_5094_1_8B970F90C584EA4E97D5BAAC9172DBB81A970D51@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56F18F74.9050504@alum.mit.edu>
Date: Tue, 22 Mar 2016 14:31:16 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <21379_1458588251_56F04A5B_21379_5094_1_8B970F90C584EA4E97D5BAAC9172DBB81A970D51@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458671477; bh=Zri5DJtidNkVFGNOyjAdvKV/EPWr+sSx9RaJeB3xBrg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hWLHZpA74n4zHnt7s1BKo3u7YgXbRpecvKSuA1K4N0VWLUWeyGQ44cGXjH+KB3TM2 vqJBjsJcPgjVZKdpnrlcVF56nd3xu9eW+M7P46OYBKAyOXakswQ8SEjLmzbq/R4mhL oc19OfNfFkn9mTRHqP0NyKgDSAB3YPfEJ273Lv6d0RDEEEXVjrXMcaUHlIMG6sCqUG GlHmNtAHU8xrKeLh7nfPbOuHuk3bBndpDjBCbG5I3PJ1mBoQr5UCofs8UxArt27p1C IZfOtW5xCbzsFGuKzrH0rTcdwDHdKUS+DqV+Uqo3SKinofW1RMLfZ1XKoDpm90pzpT VwlJ42YAREr/w==
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/waDUuJb8kMK-4aD6WkaB8__5q6A>
Subject: Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2016 18:31:20 -0000

Marianne,

Thank you. This draft is a huge improvement over the prior proposal for 
this purpose!

I don't have a problem with this approach. The draft seems in reasonable 
shape. (I didn't read it for nits, as doing that seems premature.)

One thing I noticed, which is really an issue with rfc5502:

The P-Served-User header field doesn't seem to have the usual provision 
of headers like this for comma-separated repetition. And there is no 
mention pro or con regarding whether this header field can be repeated. 
Since it can already have both orig and term options, that presumably 
can coexist, I guess it can be repeated, but not using comma. Is that 
how it is being used in practice?

It would be wise to clarify the ways in which this header field may be 
repeated. (E.g., every usage must have a distinct value of 
sessioncase-param.) And if multiple values separated by comma are being 
used in practice then the syntax ought to be corrected to allow that.

	Thanks,
	Paul

On 3/21/16 3:24 PM, marianne.mohali@orange.com wrote:
> Hello,
>
> Please find hereafter a new Internet-Draft  "P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP)".
> The purpose of the draft is to register a new SIP parameter for the P-Served-User header field defined as per RFC5502.
>
> Abstract:
>     This specification defines a new Session Initiation Protocol (SIP) P-
>     Served-User header field parameter, "orig-cdiv-param", which defines
>     the session case used by a proxy when handling an originating session
>     after Call Diversion (CDIV) services has been invoked for the served
>     user.  The P-Served-User header field is defined in [RFC5502].  The
>     P-Served-User header field conveys the identity of the served user
>     and the session case that applies to this particular communication
>     session and application invocation.
>     This document updates [RFC5502] in order to add the originating after
>     CDIV session case.
>
> The draft can be found in :
> URL:            https://www.ietf.org/internet-drafts/draft-mohali-dispatch-originating-cdiv-parameter-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-mohali-dispatch-originating-cdiv-parameter/
> Htmlized:       https://tools.ietf.org/html/draft-mohali-dispatch-originating-cdiv-parameter-00
>
> Best Regards,
> Marianne Mohali
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>