Re: [sipcore] Reason as a parameter rather than anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)

[<[e-mail]>]

Hi,
I see the problems also with the future use of the H-I. But how we could solve it?

Question is if we could make the Reason optional instead mandatory for cases where the retargeting was based on a SIP Response?

I cannot see what will break if we do it as a option. (For Call forwarding it is important that we can count the real forwarding's. It is not really important on which the forwarding's are based.)

Next Question is if we could use instead the RFC4458 causes with further values. I know I asked already this question but I didn't get a clear answer why not to use. RFC4458 does define this causes not only for the cases Voicemail and IVR, it says: "such as".


What are the opinions on that.

The only what I also want to have is a future proof solution as Marianne would like.

Within ISUP the Redirecting reason is within the Redirection Information Parameter included which is not bind to any of the Numbers. It is a own Parameter. So  
there are not the problems where and how to place the "cause"

Best Regards

Roland
 

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] 
Gesendet: Dienstag, 9. November 2010 01:43
An: Jesske, Roland; [e-mail]; [e-mail]
Cc: [e-mail]
Betreff: RE: [sipcore] Reason as a parameter rather than anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)

Hi,

Trying to show how RFC4244 was useless as it was designed (not for what it was imagined), I failed. So, I decided to do with the existing abilities with H-I and escaped Reason header...
Being involved in 3GPP debates on this topic (usage for CDIV service), I just want to say that, 3GPP is not using an other solution. 3GPP, exactly uses what is possible with RFC4244 and RFC 4458: a combination of both Reason header field parameter escaped a URI (associated to redirecting hi-entry) and cause URI parameter (associated to the retargeted-to hi-entry) ; both with a parameter named "cause=xxx" but not with the same values significations and not located in the same hi-entry (childlishly simple!). You can imagine misinterpretation...
If it is complicated only for CDIV service (Keith and Roland can confirm) what will be the future for enriched services??

Having a history header could m be usefull ONLY if simple solutions are offered to identify services's needs, select entries by types... For that, a parmeter, a header parameter, a URI parameter... Whatever, if it's clearly defined.

As I've often been told that H-I was already implemented, I choose to propose extensions based on the current header to show where the reasoning can leads. If H-I has to be re-designed, ok, I can re-design the extensions accordingly. But if there is not possibility to have application/services information, IMHO, H-I will stay at IETF.    
If we have the opportinity to fix inconsistencies, lack of clearness, even with no backward compatibility ; I'm in !

About the Reason escaped in the hi-targeted-to-uri parameter of the H-I header field, I'm not sure it has no sense to associate the Reason to the address applying the retargeting.
Beyond the break of backward compatibility, in ISUP, the redirecting reason is associated to the redirecting user (for Call Forwarding).

I see 2 possible interpretations:
1- It is the Reason why a new R-URI has been contacted unsuccessfully. What is the cause of this Retargeted-to destination failure.
2- The reason why the Retageting entity decides to modified the R-URI. eg. After receiving a SIP response, after an internal processing (see my drafts)...

Case 1: It could make sense for a 3xx response where the retargeting is invloved in the response (explicitly request a redirection). In an other situation, it is not the target destination answering with a 486 Busy Here that can determines that call has to be retargeted (it is the entity receiving that response = the Retargeting). In general, we need to know which entity do what. 


Whatever the one chosen, it has to be clearly mentionned, not only with "associated to the hi-retargeted-to-uri" not saying which one. 
 

Marianne

> -----Message d'origine-----
> De : [e-mail] 
> [mailto:[e-mail]] De la part de [e-mail]
> Envoyé : lundi 8 novembre 2010 15:53
> À : [e-mail]; [e-mail]
> Cc : [e-mail]
> Objet : Re: [sipcore] Reason as a parameter rather than 
> anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)
> 
> Hi,
> we have already a mechanism putting a "cause" into the URI 
> which is the target.
> RFC4458 describes this for diverting reasons. 
> So it is a own header used for History Info no new definition 
> is needed.
> And so this mechanism could be extended by the proposed 
> values in 
> http://tools.ietf.org/html/draft-mohali-sipcore-reason-extensi
> on-application-00 and other needed. 
> 
> So in final the Reason is included within the "retargeting" 
> URI based on the received response.
> And the cause as defined in RFC4458 is in the target URI.
> 
> Comments? 
> 
> Best Regards
> 
> Roland 
> 
> -----Ursprüngliche Nachricht-----
> Von: [e-mail] 
> [mailto:[e-mail]] Im Auftrag von Hadriel Kaplan
> Gesendet: Montag, 8. November 2010 07:32
> An: Shida Schubert
> Cc: [e-mail]
> Betreff: Re: [sipcore] Reason as a parameter rather than an 
> escapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)
> 
> 
> I know this is beating a dead horse, but breaking backwards 
> compatibility for Hist-Ifno may be a GOOD thing.
> Seriously.  Afaict, "legacy" H-I is broken.  It didn't solve 
> people's problems, in an interoperable fashion.  That's why 
> we needed 4244bis to begin with, ain't it?
> 
> In fact, start with a new header name, if need be.
> To be transparent, we can name the new header 
> "Possible-Targets-Lottery:" and if you guess the right "real" 
> target from the list, you win some award.  :)
> 
> -hadriel
> 
> On Nov 8, 2010, at 12:48 AM, Shida Schubert wrote:
> 
> > 
> > I don't agree. This is going to completely break backward 
> > compatibility.
> > 
> > Regards
> >  Shida
> > 
> > On Nov 8, 2010, at 1:55 PM, Elwell, John wrote:
> > 
> >> I agree with Paul's concerns, and I think we should use 
> bis as an opportunity to get this right, even if we have to 
> grandfather some existing mechanism. The Mohali draft is 
> evidence that the present mechanism causes further problems 
> down the line.
> >> 
> >> John
> >> 
> >>> -----Original Message-----
> >>> From: [e-mail]
> >>> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> >>> Sent: 08 November 2010 01:42
> >>> To: Mary Barnes
> >>> Cc: [e-mail]
> >>> Subject: Re: [sipcore] Comments on 
> draft-ietf-sipcore-rfc4244bis-02
> >>> 
> >>> 
> >>> 
> >>> On 11/7/2010 6:39 PM, Mary Barnes wrote:
> >>>> I think there is still some confusion here - the Reason is NOT a 
> >>>> URI parameter. It is a SIP header field that is escaped 
> in the URI 
> >>>> for compactness.
> >>> 
> >>> I don't think there is any real confusion. Its just that the 
> >>> terminology is awkward. We have parameters to headers, 
> and we have 
> >>> headers that are parameters to URIs.
> >>> 
> >>>> In earlier versions, we had a separate parameter in the SIP 
> >>>> History-Info header for Reason, but Rohan suggested to
> >>> just escape
> >>>> the existing Reason header in the URI so as not to 
> redefine Reason 
> >>>> parameters.
> >>> 
> >>> I even remember him making that suggestion. Too bad he 
> isn't around 
> >>> so we can wring his neck. I thought it was a hack at the 
> time, but 
> >>> didn't then realize how much trouble it would cause.
> >>> 
> >>>> The Reason header is intended to tag the Reason why the
> >>> hi-targeted-to
> >>>> URI was retargeted and thus it goes with the "old" hi-entry
> >>> versus the
> >>>> "new" one.
> >>> 
> >>> Just stating it that was exposes the problem.
> >>> The intent of the Reason header is specified in RFC3326.
> >>> Any use that isn't consistent with that is an abuse.
> >>> Its intended to indicate why a *request* is being sent.
> >>> 
> >>>> We originally had two URIs for each hi-entry (the old 
> and the new) 
> >>>> . The idea of capturing the "new" is so that you
> >>> already have
> >>>> the old entry when you do the retarget, noting that when 
> an entity 
> >>>> goes to process History-Info, the last entry isn't typically 
> >>>> useful, since it should always be the URI in the 
> received request.  
> >>>> So, logically, for each request that is retargeted, you have
> >>> the "old" and
> >>>> "new", so they really are related and .
> >>>> 
> >>>> Also, note that we cannot change this now even if it 
> were the right 
> >>>> thing to do due to backwards compatibility.
> >>> 
> >>> So then we allow it continue to metastasize, e.g. by defining new 
> >>> Reason values that aren't ever expected to be used in 
> requests, and 
> >>> that wouldn't make any sense if they were?
> >>> 
> >>>     Thanks,
> >>>     Paul
> >>> 
> >>>> Mary.
> >>>> 
> >>>> On Sun, Nov 7, 2010 at 9:05 AM, Paul
> >>> Kyzivat<[e-mail]>  wrote:
> >>>>> The following is giving me heartburn:
> >>>>> 
> >>>>> On 11/2/2010 3:25 PM, Mary Barnes wrote:
> >>>>> 
> >>>>>>> 2. There is some confusion concerning Reason - sometimes
> >>> it is referred
> >>>>>>> to as a parameter (e.g., 7.1 3rd bullet, 7.1 last
> >>> paragraph), sometimes as
> >>>>>>> reason header, sometimes as reason, sometimes as Reason
> >>> header, sometimes as
> >>>>>>> Reason...
> >>>>>> 
> >>>>>> [MB] Logically, Reason is a "parameter" for the
> >>> hi-entries. However,
> >>>>>> rather than redefine the "parameter", we reuse the Reason
> >>> header by
> >>>>>> escaping it in the URI - the term Reason header was used
> >>> for brevity.
> >>>>>> I did add text in the -02 to clarify that in cases where it is 
> >>>>>> confusing. I can change all instances to refer to "escape a 
> >>>>>> Reason header in the hi-targeted-uri" rather than just "add a
> >>> Reason header".
> >>>>>> [/MB]
> >>>>> 
> >>>>>>> 4. As another general comment, there are too many
> >>> normative statements
> >>>>>>> using the passive voice, and therefore hard to
> >>> understand. To quote one
> >>>>>>> example of the sort of ambiguity that can arise from
> >>> using passive, in
> >>>>>>> 7.3.2:
> >>>>>>> "For retargets that are the result of an explicit SIP 
> response, 
> >>>>>>> a  Reason MUST be associated with the hi-targeted-to-uri."
> >>>>>>> Is this saying that an entity that inserts History-Info
> >>> MUST include in
> >>>>>>> hi-targeted-uri an escaped Reason header field? Or is
> >>> this saying that a
> >>>>>>> recipient of Reason MUST associate it with an
> >>> hi-targeted-to-uri. I guess
> >>>>>>> the first interpretation is more plausible, but why not
> >>> say what is meant,
> >>>>>>> rather than fudging it?
> >>>>>> 
> >>>>>> [MB] The Reason header is added to the hi-entry whose 
> >>>>>> hi-targeted-to-URI is being retargeted due to the 
> response.  It 
> >>>>>> is added by the entity receiving the response.  Note that it
> >>> is added to
> >>>>>> the entry prior to the entry that is being added as a
> >>> result of the
> >>>>>> retargeting due to the response - i.e., it's not added to the 
> >>>>>> "current" hi-entry.  It's added to the previous.  The 
> sentences 
> >>>>>> following the one that you highlight are intended to say
> >>> just that.
> >>>>>> That's why the term "associated" is loosely used 
> because the next 
> >>>>>> sentences are the normative part. So, really, that 
> first sentence 
> >>>>>> shouldn't be "MUST be" and would be more accurate to say
> >>> "is". [/MB]
> >>>>> 
> >>>>> I guess this isn't a new concern - its been there all
> >>> along, but it seems
> >>>>> very wrong to me. (Warning - this is long.) Specifically,
> >>>>> 
> >>>>> There is a real difference between Reason as a parameter
> >>> of an H-I entry and
> >>>>> an H-I entry containing a URI that contains a Reason
> >>> header as a URI
> >>>>> parameter. A URI parameter has a specific meaning - it
> >>> specifies a Header
> >>>>> that is to be incorporated into a request that uses that
> >>> URI as an R-URI.
> >>>>> 
> >>>>> Depending on details of how H-I entries are constructed
> >>> during retargeting,
> >>>>> it may be that a retarget URI would contain URI
> >>> parameters, and those would
> >>>>> end up in an H-I entry. There could be a Reason header
> >>> included in the
> >>>>> retarget URI. I *think* the procedures for UAC and proxy
> >>> imply that the
> >>>>> retargeted request would be constructed first - thus
> >>> removing embedded
> >>>>> parameters and making them headers in the request -
> >>> *before* capturing the
> >>>>> R-URI for H-I, but I'm not certain of that. If not, then
> >>> there could be
> >>>>> ambiguity about the origin and meaning of a Reason header
> >>> in an H-I URI.
> >>>>> 
> >>>>> Even if that is not a problem, there are potential
> >>> problems if an H-I entry
> >>>>> is ever used to construct a new request. For instance, if
> >>> someone were to
> >>>>> analyze H-I to identify the URI of some entity (say the
> >>> caller) in order to
> >>>>> send a new request there, it would lift the URI from H-I
> >>> and put it into a
> >>>>> new request. Then the Reason URI parameter would,
> >>> according to 3261, be
> >>>>> removed and be added as a header to that new request. 
> That isn't 
> >>>>> catastrophic, but I think its at least misleading, because:
> >>>>> 
> >>>>> The reason is on the wrong URI. The Reason explains why
> >>> the retargeted URI
> >>>>> is being used, so it belongs in the message addressed to
> >>> that URI. It makes
> >>>>> no sense that it be in a request to the R-URI that, in
> >>> some prior usage, was
> >>>>> eventually retargeted.
> >>>>> 
> >>>>> Bottom line: the H-I use of Reason as a URI header
> >>> parameter is a hack and
> >>>>> an abuse of that mechanism. It might be benign and
> >>> forgivable if it were
> >>>>> consistent with the intended use of that mechanism. But it
> >>> seems it is not -
> >>>>> that it is at best the re-purposing of that mechanism in a
> >>> case where it,
> >>>>> arguably, might be thought not to conflict with legitimate
> >>> use of the URI
> >>>>> header parameter mechanism. I'll argue it isn't that
> >>> benign - that there are
> >>>>> overlaps where the uses overlap.
> >>>>> 
> >>>>> H-I should have had its own header field parameter for
> >>> this purpose - not
> >>>>> use the Reason header.
> >>>>> 
> >>>>> This has ripple effects. Now we have 
> >>>>> draft-mohali-sipcore-reason-call-forwarding which is
> >>> defining new reason
> >>>>> codes which are intended specifically for use with H-I, without 
> >>>>> any contemplation of their use in a real Reason header in a
> >>> request. This is
> >>>>> insanity - but not for the author who is just trying to
> >>> work within the
> >>>>> existing system. Its just an example of the mess created
> >>> by the abuse of
> >>>>> repurposing Reason within H-I.
> >>>>> 
> >>>>> I commented to the author of
> >>> draft-mohali-sipcore-reason-call-forwarding
> >>>>> that I felt any extensions to Reason needed to be
> >>> justified in their own
> >>>>> right, without reference to H-I. In fact what is proposed
> >>> there *does* make
> >>>>> sense in its own right, without regard to H-I *if* it is
> >>> used in the
> >>>>> retargeted request, rather than the request that is about
> >>> to be retargeted.
> >>>>> 
> >>>>> This could be fitted into H-I. When retargeting, it could
> >>> be specified that
> >>>>> a Reason header should be added to the new request,
> >>> explaining why it was
> >>>>> retargeted. Then whoever makes the H-I entry for that
> >>> could include in the
> >>>>> H-I entry for that request the R-URI of the request with
> >>> any Reason headers
> >>>>> in that request added to the entry as URI parameters.
> >>> However this would be
> >>>>> incompatible with 4244 because it would change which entry
> >>> contains the
> >>>>> reason.
> >>>>> 
> >>>>>       Thanks,
> >>>>>       Paul
> >>>>> _______________________________________________
> >>>>> sipcore mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>>> 
> >>>> 
> >>> _______________________________________________
> >>> sipcore mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/sipcore
> >>> 
> >> _______________________________________________
> >> sipcore mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/sipcore
> > 
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>