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

[Hadriel Kaplan <[e-mail]>]

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