Re: [sipcore] Reason as a parameter rather than an escaped header

<marianne.mohali@orange-ftgroup.com> Tue, 07 December 2010 19:49 UTC

Return-Path: <marianne.mohali@orange-ftgroup.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91903A67FF for <sipcore@core3.amsl.com>; Tue, 7 Dec 2010 11:49:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.958
X-Spam-Level:
X-Spam-Status: No, score=-2.958 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBuuEO3+y7W7 for <sipcore@core3.amsl.com>; Tue, 7 Dec 2010 11:49:28 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 4B68D3A6891 for <sipcore@ietf.org>; Tue, 7 Dec 2010 11:49:28 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B18FF858001; Tue, 7 Dec 2010 20:54:50 +0100 (CET)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id A5D1F798007; Tue, 7 Dec 2010 20:54:50 +0100 (CET)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Dec 2010 20:50:53 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB9648.0E180C13"
Date: Tue, 7 Dec 2010 20:50:51 +0100
Message-ID: <B11765B89737A7498AF63EA84EC9F57727A8C4@ftrdmel1>
In-Reply-To: <AANLkTimH+onHwUeYAYRmARXCzHe=nt_wknXRhwA7haUL@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header
Thread-Index: AcuVW6b6/18kWRWiSxqvrGvHmZy9HwA0W6Ew
References: <CD5674C3CD99574EBA7432465FC13C1B2202288A06@DC-US1MBEX4.global.avaya.com><4CDC04F2.3010701@cisco.com><AANLkTi=utzFcqg_QTfurdB0WKK8MRAny8Pb8CEE=s60L@mail.gmail.com><4CEC570D.8080700@cisco.com><7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se><4CED9370.5010001@cisco.com><7F2072F1E0DE894DA4B517B93C6A05850307DAE8@ESESSCMS0356.eemea.ericsson.se><B11765B89737A7498AF63EA84EC9F5772378A7@ftrdmel1> <AANLkTimH+onHwUeYAYRmARXCzHe=nt_wknXRhwA7haUL@mail.gmail.com>
From: <marianne.mohali@orange-ftgroup.com>
To: <mary.ietf.barnes@gmail.com>
X-OriginalArrivalTime: 07 Dec 2010 19:50:53.0620 (UTC) FILETIME=[0E8E2740:01CB9648]
Cc: sipcore@ietf.org, dworley@avaya.com
Subject: Re: [sipcore] Reason as a parameter rather than an escaped header
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Dec 2010 19:49:30 -0000

Hi Mary,
 
It's OK for me !
 
Thanks,
Marianne


________________________________

	De : Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 
	Envoyé : lundi 6 décembre 2010 16:39
	À : MOHALI Marianne RD-CORE-ISS
	Cc : christer.holmberg@ericsson.com; pkyzivat@cisco.com; dworley@avaya.com; sipcore@ietf.org
	Objet : Re: [sipcore] Reason as a parameter rather than an escaped header
	
	
	Hi Marianne et al,
	 
	I totally agree that there was some text removed from RFC 4244 that was intended to handle the internal retargeting case. I would suggest we add that back, updating the paragraph to be a little more concise as I suggested earlier in the thread and add a note with regards the definition of any new Reason headers - something like the following:
	 
	  If the response contains any Reason header fields, then 
	  the Reason header fields MUST be captured as Reasons 
	  associated with the hi-targeted-to-uri that has been
	  retargeted.  If the SIP response does not include a Reason header field 
	  (see [RFC3326]), the SIP  Response Code that triggered the retargeting 
	  MUST be included as the Reason associated with the hi-targeted-to-uri 
	  that has been retargeted.  
	 
	  For retargets as a result of timeouts or internal events, a Reason
	  MAY be associated with the hi-targeted-to-uri that has been
	  retargeted.  [MB: this is the original text from RFC 4244.]
	 
	  In the case that additional Reason headers are defined, per RFC 3326, 
	  the use of these Reason headers for the History-Info header field 
	  MUST follow the same rules as described above. 
	 
	Thanks,
	Mary. 
	
	
	On Thu, Nov 25, 2010 at 4:33 PM, <marianne.mohali@orange-ftgroup.com> wrote:
	

		Hi,
		
		I agree that draft-mohali-sipcore-reason-extension-application could live independently of 4244bis, except for the section "Reason in the History-Info header" that should still allow wat is proposed in draft-reason.
		
		Note that RFC4244 is compatible with the draft-reason proposal: As work on 4244bis was in progress, we based the draft on the following text from RFC4244: "For retargets as a result of timeouts or internal events, a Reason MAY be associated with the hi-targeted-to-uri that has been retargeted."
		
		Unfortunately, this sentence disappeared and only the last sentence about timeout suggests to insert a Reason for an internal process.
		
		If there is no objection, we could put this text back in 4244bis to keep explicit the ability to insert the Reason header field in a H-I entry for *internal* reasons (with a MAY).
		
		
		Regards,
		Marianne
		
		> -----Message d'origine-----
		> De : sipcore-bounces@ietf.org
		> [mailto:sipcore-bounces@ietf.org] De la part de Christer Holmberg
		> Envoyé : jeudi 25 novembre 2010 07:48
		> À : Paul Kyzivat
		> Cc : Worley, Dale R (Dale); sipcore@ietf.org
		> Objet : Re: [sipcore] Reason as a parameter rather than an
		> escaped header
		
		>
		>
		> Hi,
		>
		> >>I think we should ask ourselves: assuming we allowed to do what
		> >>Marianne is proposing, would anything break?
		> >>
		> >>Does anyone really care whether a H-I entry was inserted based on a
		> >>"real" or "virtual" response? Aren't people more interested in the
		> >>actual reason value?
		> >
		> >I don't currently see a problem with permitting this (though I'm
		> >interested to hear if somebody else sees an issue).
		> >
		> >But IMO the current text doesn't suggest to me that this is valid.
		> >So if the desire is for it to be valid it would be good to have some
		> >text that makes it so.
		>
		> I agree. We would need to add some text.
		>
		> Regards,
		>
		> Christer
		>
		
		> _______________________________________________
		> sipcore mailing list
		> sipcore@ietf.org
		> https://www.ietf.org/mailman/listinfo/sipcore
		>
		_______________________________________________
		sipcore mailing list
		sipcore@ietf.org
		https://www.ietf.org/mailman/listinfo/sipcore