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 17ECB3A6CC2 for ; Fri, 10 Dec 2010 08:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 WnpfQk8gpE+L for ; Fri, 10 Dec 2010 08:45:49 -0800 (PST) Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id 3359628C0F7 for ; Fri, 10 Dec 2010 08:45:36 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 10 Dec 2010 11:46:54 -0500 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 10 Dec 2010 11:46:54 -0500 From: Hadriel Kaplan To: Mary Barnes Date: Fri, 10 Dec 2010 11:46:53 -0500 Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header Thread-Index: AcuYidnmGLPCFE06Ri2g4olG/+Jk8w== Message-ID: <9DF7AC2B-667B-41CF-842D-1E3BC5724C71@acmepacket.com> References: <4CDC04F2.3010701@cisco.com> <4CEC570D.8080700@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se> <4CED9370.5010001@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850307DAE8@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9DF7AC2B667B41CF842D1E3BC5724C71acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "sipcore@ietf.org WG" 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: Fri, 10 Dec 2010 16:45:51 -0000 --_000_9DF7AC2B667B41CF842D1E3BC5724C71acmepacketcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK, so I think there's general agreement to add additional H-I header field= s 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 bee= n retargeted." Why is this a MAY? What's the alternative? Does it mean they may do somet= hing else, like use a RFC 4458 style cause URI parameter? Does it mean the= y 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 resul= t of timeouts or internal events, a Reason MUST be associated with the hi-t= argeted-to-uri that has been retargeted and encoded as an embedded Reason h= eader 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 inte= rnal 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 re= ceiver would have to understand/support. -hadriel On Dec 6, 2010, at 10:38 AM, Mary Barnes wrote: Hi Marianne et al, I totally agree that there was some text removed from RFC 4244 that was int= ended 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 ear= lier in the thread and add a note with regards the definition of any new Re= ason 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 i= ndependently 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 RFC4= 244: "For retargets as a result of timeouts or internal events, a Reason MA= Y be associated with the hi-targeted-to-uri that has been retargeted." Unfortunately, this sentence disappeared and only the last sentence about t= imeout suggests to insert a Reason for an internal process. If there is no objection, we could put this text back in 4244bis to keep ex= plicit the ability to insert the Reason header field in a H-I entry for *in= ternal* 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 --_000_9DF7AC2B667B41CF842D1E3BC5724C71acmepacketcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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 MA= Y?  What's the alternative?  Does it mean they may do something e= lse, 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 t= he text isn't clear)  

For example, is this w= hat you really want to say: "For retargets as a result of timeouts or inter= nal events, a Reason MUST be associated with the hi-targeted-to-uri that ha= s 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 i= nternal 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 value= s that the receiver would have to understand/support.

<= div>-hadriel
On Dec 6, 2010, at 10:38 AM, Mary Barnes wr= ote:

Hi Marianne et al,
 
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 - something like the following:
 
  If the response contains any Reason header fields, then
&nb= sp; the Reason header fields MUST be captured as Reasons
  associa= ted with the hi-targeted-to-uri that has been
  retargeted.  I= f 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 Rea= son
  MAY be associated with the hi-targeted-to-uri that has b= een
  retargeted.  [MB: this is the original text from RF= C 4244.]
 
  In the case that additional Reason headers are defined, per RFC= 3326,
  the use of these Reason headers for the History-Info header fie= ld
  MUST follow the same rules as described above.
 
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" 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 Reaso= n MAY be associated with the hi-targeted-to-uri that has been retargeted."<= br>
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:sipcore-bo= unces@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 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 vali= d.
> >So if the desire is for it to be valid it would be good to h= ave 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

<ATT00001..c>

= --_000_9DF7AC2B667B41CF842D1E3BC5724C71acmepacketcom_--