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

[<[e-mail]>]

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
>