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

Mary Barnes <mary.ietf.barnes@gmail.com> Mon, 06 December 2010 15:37 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
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 <sipcore@core3.amsl.com>; 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 <sipcore@core3.amsl.com>; 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 <sipcore@ietf.org>; Mon, 6 Dec 2010 07:37:13 -0800 (PST)
Received: by yxt33 with SMTP id 33so2672206yxt.31 for <sipcore@ietf.org>; 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: <B11765B89737A7498AF63EA84EC9F5772378A7@ftrdmel1>
References: <CD5674C3CD99574EBA7432465FC13C1B2202288A06@DC-US1MBEX4.global.avaya.com> <4CDC04F2.3010701@cisco.com> <AANLkTi=utzFcqg_QTfurdB0WKK8MRAny8Pb8CEE=s60L@mail.gmail.com> <4CEC570D.8080700@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se> <4CED9370.5010001@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850307DAE8@ESESSCMS0356.eemea.ericsson.se> <B11765B89737A7498AF63EA84EC9F5772378A7@ftrdmel1>
Date: Mon, 6 Dec 2010 09:38:33 -0600
Message-ID: <AANLkTimH+onHwUeYAYRmARXCzHe=nt_wknXRhwA7haUL@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
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 <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Dec 2010 15:37:15 -0000

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
>