Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?

[<[e-mail]>]

Hi,

The objective of draft-mohali-sipcore-reason-extension-application is to know why and, more exactly, which application has influenced the session.
4244bis do not cover the need but is necessary to meet the need.

3 Use-cases for application-specific Reason:
1. in accordance with RFC3326, in a BYE or CANCEL to explain why a session has been released/canceled (general use-case) 
2. in accordance with 4244bis, escaped in the History-Info header (2 sub-cases)
    2.1. When the call is retargeted (R-URI changed), explaining that it is because of an application-specific internal decision.
    2.2. When there is no retargeting (R-URI unchanged), just to mark in the session history that this application has been invocated.

Work on RFC4244bis has to be concluded and this draft has a different scope. I don't see any interaction issues.

Why not finish RFC4244bis and use this draft both to enrich Reason header in general and to meet the needs using History-Info (already covering the use of Reason)?

Hadriel, you said "When I read Marianne's draft, it sounds like the use-case she's trying to cover is call-forwarding" 
but the presented draft has really NO link with Call Forwarding (it is an other draft ;-).

Marianne

> -----Message d'origine-----
> De : [e-mail] 
> [mailto:[e-mail]] De la part de Hadriel Kaplan
> Envoyé : vendredi 12 novembre 2010 04:32
> À : Adam Roach
> Cc : [e-mail] WG
> Objet : Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
> 
> 
> I'd like a clarification. 
> You said:
> > "limit bis
> > changes to [those necessary to] satisfy target uri requirements."
> 
> 
> If by that you mean literally just to enable GRUU delivery, 
> we've already exceeded that.  You don't need an "mp" tag for 
> that, for example, afaict.
> 
> But I'm also not sure it's fair to be that restrictive in 
> your interpretation of what the bis can change.  Obviously we 
> have to constrain the scope, to actually get anywhere.
> But there's no point in publishing a document if it doesn't 
> solve a problem people actually have, just for the sake of 
> publishing a document. 
> 
> [soapbox]
> An RFC is not an end goal in itself - it's a means to an end, 
> namely for enabling interoperable protocols people will 
> *actually use*.
> [/soapbox]
> (I know we all agree on this, I'm just venting)
> 
> BTW, I'm not sure Marianne's use-case requires *ANY* 
> normative changes to rfc4244bis.  I was just commenting that 
> it would have been nice to really understand if rfc4244bis 
> did not cover it.  This is similar to Cullen's concern about 
> use-cases/application-examples.  We need to make sure the 
> changes we're making are actually useful. (I think they 
> *are*, or are as close as we can get, but that doesn't mean 
> we shouldn't go through the exercise... using H-I just isn't 
> that simple/obvious)
> 
> -hadriel
> 
> On Nov 11, 2010, at 9:53 PM, Adam Roach wrote:
> 
> > [as chair]
> > 
> > On 11/12/10 10:06 AM, Hadriel Kaplan wrote:
> >> When I read Marianne's draft, it sounds like the use-case 
> she's trying to cover is call-forwarding, for things like 
> voicemail systems to be able to detect/process.  So what 
> really confuses me is I thought one of the basic applications 
> 4244bis was trying to enable was exactly that one.  Right?  
> If it's not sufficient to achieve that, I think we've screwed 
> up somewhere... or at least need to make sure it's not 
> something we can fix in 4244bis, because now would be a 
> really good time to fix it.  :)
> > 
> > At IETF 75, when we were discussing the applicability of 
> 4244bis to the 
> > SIPCORE charter (as opposed to simply developing a new 
> document that was 
> > limited to describing how to use 4244 to deliver URI 
> parameters), one of 
> > the rather important points that was made was that we would 
> "limit bis 
> > changes to [those necessary to] satisfy target uri requirements."
> > 
> > If the RAI community at large wants to expand this to 
> include a general 
> > tune-up and/or kitchen-sinking of 4244, then we need to 
> figure out a way 
> > to put the SIPCORE milestone to rest and then send the rest of the 
> > changes to DISPATCH. I have no interest in letting this 
> milestone drag 
> > on as people come up with new things they'd like to see 
> added or changed.
> > 
> > /a
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>