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

[<[e-mail]>]

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


________________________________

	De : Mary Barnes [mailto:[e-mail]] 
	Envoyé : lundi 6 décembre 2010 16:39
	À : MOHALI Marianne RD-CORE-ISS
	Cc : [e-mail]; [e-mail]; [e-mail]; [e-mail]
	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, <[e-mail]> 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 : [e-mail]
		> [mailto:[e-mail]] De la part de Christer Holmberg
		> Envoyé : jeudi 25 novembre 2010 07:48
		> À : Paul Kyzivat
		> Cc : Worley, Dale R (Dale); [e-mail]
		> 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
		> [e-mail]
		> https://www.ietf.org/mailman/listinfo/sipcore
		>
		_______________________________________________
		sipcore mailing list
		[e-mail]
		https://www.ietf.org/mailman/listinfo/sipcore