Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A353A6832 for ; Mon, 6 Dec 2010 07:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.125 X-Spam-Level: X-Spam-Status: No, score=-103.125 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCwyLjEwmIgl for ; Mon, 6 Dec 2010 07:37:14 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 814CD3A6827 for ; Mon, 6 Dec 2010 07:37:13 -0800 (PST) Received: by yxt33 with SMTP id 33so2672206yxt.31 for ; Mon, 06 Dec 2010 07:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=8oOZ+TcnuPdPXySiMhO7f1oqzhOUjVdywtrsbSDo4+4=; b=r3sUqT2UpTwAJe5wrviQ3M0u3lJnXq0Sd4D8FZND7jxUBpSHPJKXjJCevjtL6uh+1T c1E+AXTjrgsTZ77i4QyBeioEPEmTaZGRRivhsKg4tx4wg+zTHp+Qv+waoyyuU9nbCGfw LdUB3SNFo7bPNFi09Q/AMo8k927HCTLRyxKug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ABRuWAkvJG+dgiOnFlThQTvPbP02ruSQtfVhRlokqKVhx+oW+NgdFP1ht6ZQp8DQya RKcfKW3VCRar2QzObGWnrugbEM7mCyviOxGl2/D9aUeLYiAyo9uQM+R8f8xlUk8PRuwM 9bwnZ+AEtwT/oNZXADFNQVrTW3f/8owXj9G60= MIME-Version: 1.0 Received: by 10.150.148.17 with SMTP id v17mr9856402ybd.90.1291649913597; Mon, 06 Dec 2010 07:38:33 -0800 (PST) Received: by 10.236.95.35 with HTTP; Mon, 6 Dec 2010 07:38:33 -0800 (PST) In-Reply-To: References: <4CDC04F2.3010701@cisco.com> <4CEC570D.8080700@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se> <4CED9370.5010001@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850307DAE8@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 6 Dec 2010 09:38:33 -0600 Message-ID: From: Mary Barnes To: marianne.mohali@orange-ftgroup.com Content-Type: multipart/alternative; boundary=000e0cd4053046a39d0496bfaea3 Cc: sipcore@ietf.org, dworley@avaya.com Subject: Re: [sipcore] Reason as a parameter rather than an escaped header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 15:37:15 -0000 --000e0cd4053046a39d0496bfaea3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 suggeste= d 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, wrote= : > Hi, > > I agree that draft-mohali-sipcore-reason-extension-application could live > independently of 4244bis, except for the section "Reason in the History-I= nfo > header" that should still allow wat is proposed in draft-reason. > > Note that RFC4244 is compatible with the draft-reason proposal: As work o= n > 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 Rea= son > 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=E9 : jeudi 25 novembre 2010 07:48 > > =C0 : 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 > --000e0cd4053046a39d0496bfaea3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Marianne et al,
=A0
I totally agree that there was some text removed from RFC 4244 that wa= s 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 suggeste= d earlier in the thread and add a note with regards the definition of any n= ew Reason headers=A0- something like the following:
=A0
=A0 If the response contains any Reason header fields, then
=A0 th= e Reason header fields MUST be captured as Reasons
=A0 associated with = the hi-targeted-to-uri that has been
=A0 retargeted.=A0 If the SIP respo= nse does not include a Reason header field
=A0 (see [RFC3326]), the SIP =A0Response Code that triggered the retar= geting
=A0 MUST be included as the Reason associated with the hi-targeted-to-= uri
=A0 that has been=A0retargeted.=A0
=A0
=A0 For retargets as a result of timeouts or internal events, a Reason=
=A0=A0MAY be associated with the hi-targeted-to-uri that has been
= =A0=A0retargeted.=A0 [MB: this is the original text from RFC 4244.]
=A0
=A0 In the case that additional Reason headers are defined, per RFC 33= 26,
=A0 the use of these Reason headers for the History-Info header field =
=A0 MUST follow the same rules as described above.
=A0
Thanks,
Mary.

On Thu, Nov 25, 2010 at 4:33 PM, <marianne.mohal= i@orange-ftgroup.com> wrote:
Hi,

I agree that draft-mo= hali-sipcore-reason-extension-application could live independently of 4244b= is, except for the section "Reason in the History-Info header" th= at 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 retarget= ed."

Unfortunately, this sentence disappeared and only the last sentence abo= ut timeout suggests to insert a Reason for an internal process.

If t= here is no objection, we could put this text back in 4244bis to keep explic= it the ability to insert the Reason header field in a H-I entry for *intern= al* reasons (with a MAY).


Regards,
Marianne

> -----Message d'origine-----> De : sipcore-bounces@ietf= .org
> [mailto:sipcor= e-bounces@ietf.org] De la part de Christer Holmberg
> Envoy=E9 : jeudi 25 novembre 2010 07:48
> =C0 : Paul Kyzivat
= > Cc : Worley, Dale R (Dale); sipcor= e@ietf.org
> Objet : Re: [sipcore] Reason as a parameter rather t= han an
> escaped header
>
>
> Hi,
>
> >>I think = we should ask ourselves: assuming we allowed to do what
> >>Mar= ianne 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 p= eople more interested in the
> >>actual reason value?
> &= gt;
> >I don't currently see a problem with permitting this (t= hough 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 a= dd some text.
>
> Regards,
>
> Christer
>
=
> _______________________________________________
> si= pcore mailing list
> sipcore@ietf.org
> http= s://www.ietf.org/mailman/listinfo/sipcore
>
__________________= _____________________________
sipcore mailing list
sipcore@ietf.or= g
https://www.ietf.org/mailman/listinfo/sipcore

--000e0cd4053046a39d0496bfaea3--