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

[Mary Barnes <[e-mail]>]

Response inline below [MB].

Mary.

On Thu, Nov 11, 2010 at 9:32 PM, Hadriel Kaplan <[e-mail]>wrote:

>
> 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)
>

[MB] Correct, I also do not believe that Marianne's use cases require
normative changes to RFC 4244bis, which is really agnostic in terms of the
Reason header value.  I can certainly see that History-Info header provides
necessary functionality for the use case, however, the use cases also
require extensions to Reason header values that are normative.  For this
same reason, we are removing the sub-addressing use case since it requires
new functionality beyond what is provided by 4244bis.  [/MB]

>
> -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
>