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

From: Mary Barnes <[email-masked]>
Date: Mon, 6 Dec 2010 09:38:33 -0600

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, <[email-masked]> 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 : [email-masked]
> > [mailto:[email-masked]] De la part de Christer Holmberg
> > Envoyé : jeudi 25 novembre 2010 07:48
> > À : Paul Kyzivat
> > Cc : Worley, Dale R (Dale); [email-masked]
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: <[email-masked]>
Date: Tue, 7 Dec 2010 20:50:51 +0100

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

________________________________

	De : Mary Barnes [mailto:[email-masked]] 
	Envoyé : lundi 6 décembre 2010 16:39
	À : MOHALI Marianne RD-CORE-ISS
	Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]
	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:

	 
	 
	Thanks,
	Mary. 

		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

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 10 Dec 2010 11:46:53 -0500

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,

Thanks,
Mary.

On Thu, Nov 25, 2010 at 4:33 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,
Marianne

> De : [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]<mailto:[email-masked]>] De la part de Christer Holmberg
> Cc : Worley, Dale R (Dale); [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

<ATT00001..c>

---

From: <[email-masked]>
Date: Mon, 13 Dec 2010 09:42:50 +0100

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: [email-masked] [mailto:[email-masked]] Im Auftrag von Hadriel Kaplan
Gesendet: Freitag, 10. Dezember 2010 17:47
An: Mary Barnes
Cc: [email-masked] WG
Betreff: Re: [sipcore] Reason as a parameter rather than an escaped header

-hadriel

Hi Marianne et al,

Thanks,
Mary.

Hi,

Regards,
Marianne

<ATT00001..c>

---

From: <[email-masked]>
Date: Mon, 13 Dec 2010 22:27:25 +0100

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 : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
	Envoyé : lundi 13 décembre 2010 09:43
	À : [email-masked]; [email-masked]
	Cc : [email-masked]
	Objet : Re: [sipcore] Reason as a parameter rather than an escaped header

	Hi Hadriel,

	Best Regards
	 
	Roland 

		

		-hadriel

			Hi Marianne et al,

			 

			Thanks,
			Mary. 

				Hi,

				

				Regards,
				Marianne

				

			<ATT00001..c>