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
>