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

[<[e-mail]>]

Hi Hadriel, Roland,
 
I agree with Roland. 

Additionally, 
1) the text could be more clear as "For retargets as a result of timeouts or internal events, a Reason header field MAY be inserted in the History-Info header field. If inserted, the Reason header field MUST be associated with the hi-targeted-to-uri that has been retargeted and encoded as an embedded Reason header field in the URI."
About the signification of the MAY, is it really needed to explain why or why not? It is under the retargeting entity responsibility to decide, non? 

2) About the form of the reason-value, I'm not sure it is the purpose of RFC4244bis, defining the History-Info header, to describe how the Reason header field should be used (protocole-value...). And I don't know why should we do such a thing.

Best regards,
Marianne

________________________________

	De : [e-mail] [mailto:[e-mail]] De la part de [e-mail]
	Envoyé : lundi 13 décembre 2010 09:43
	À : [e-mail]; [e-mail]
	Cc : [e-mail]
	Objet : Re: [sipcore] Reason as a parameter rather than an escaped header
	
	
	Hi Hadriel,
	 
	for 1) I see this as a option which the service provider could choose. Not everybody will be mandated to put in a Reason on a internal event within the server which ends in a retargeting/diversion. 
	for 2) I think it could be a normal Reason value, based on a equivalent processes as it would be sent out by an other sever. E.G. If a timer expires a 408 could be included.
	 
	Best Regards
	 
	Roland 


________________________________

		Von: [e-mail] [mailto:[e-mail]] Im Auftrag von Hadriel Kaplan
		Gesendet: Freitag, 10. Dezember 2010 17:47
		An: Mary Barnes
		Cc: [e-mail] WG
		Betreff: Re: [sipcore] Reason as a parameter rather than an escaped header
		
		
		
		
		OK, so I think there's general agreement to add additional H-I header fields for internal retargeting.
		
		
		I have two questions then:
		
		
		1) the text below says: "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."
		Why is this a MAY?  What's the alternative?  Does it mean they may do something else, like use a RFC 4458 style cause URI parameter?  Does it mean they may associate it with a different hi-targeted-to-uri? (I assume not, but the text isn't clear)  

		For example, is this what you really want to say: "For retargets as a result of timeouts or internal events, a Reason MUST be associated with the hi-targeted-to-uri that has been retargeted and encoded as an embedded Reason header field in the URI, unless the reason for the retargeting is unknown."

		2) What form of reason-value protocol can be used for a Reason from an internal operation?  Can it be a "SIP" cause?  Ultimately if this info is used by a receiver of the H-I entries to trigger different behavior/features, it would be really nice not to have to create a bunch more values that the receiver would have to understand/support.

		-hadriel

		On Dec 6, 2010, at 10:38 AM, Mary Barnes wrote:


			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
				


			<ATT00001..c>