Re: Comment on draft-roach-sipcore-rfc3265bis-00

Adam,

Don't get me wrong. I think this is a problem any way you turn.

I was pretty heavily involved in gruu. It certainly intended to solve a 
problem, but it too ended up much more complex than anybody hoped it 
would - to the point that I suspect there is a lot of reluctance to 
implement it, and a fair amount of potential to implement it wrong. On 
top of that, I suspect many feel they haven't needed it so far, and can 
get away without it, because the magic of SBCs eliminates the need.

Also, I know of significant deployed uses of dialog sharing, that 
probably won't go away any time soon even after deprecation.

If we had it to do over, I would not include dialog sharing in 3261. But 
despite the potential problems with it, I think that horse is out of the 
barn and will not be put back in, especially since that barn is on fire.

IMO the more likely thing is to encourage everyone who can to put a ;gr 
on their contacts, and to make a best practice of using out-of-dialog 
subscriptions/refers, etc. whenever the target address has ;gr. But if 
it doesn't, then I think one should go ahead and use dialog sharing. Of 
course one is free to refrain from carrying out some feature rather than 
initiating it via dialog sharing, but if you are on the receiving end, 
then I think support is still expected.

	Thanks,
	Paul

Adam Roach wrote:
> Paul Kyzivat wrote:
>>
>>
>> Adam Roach wrote:
>>
>>> Because of the true interoperability nightmare that has resulted from 
>>> dialog sharing, my suggestion would be to disable notifier 
>>> functionality on those endpoints under such circumstances (perhaps 
>>> with an implementation option to fall back to 3265 behavior for the 
>>> truly masochistic).
>>
>> Can you say more about the "true interoperability nightmare that has 
>> resulted from dialog sharing"?
>>
>> I understand that there undoubtedly are interop issues due to some UAs 
>> not supporting dialog sharing. There are also interop issues due to 
>> the UAs not supporting an event package, or not supporting GRUU, or 
>> whatever. Is one more of a nightmare than another?
> 
> It's not lack of support that worries me -- it's mismatched views of 
> dialog and usage state between two endpoints who both think they've 
> implemented dialog sharing. The problem is not that things negotiate 
> down to a lesser set of capabilities -- it's that things act broken in a 
> way that exposes this mixed-up view of whether a dialog (and its 
> associated session/subscription) is active.
> 
>> Dialog sharing has been a legal possibility since 3261 was published. 
>> So it shouldn't be a surprise to anybody. If somebody didn't implement 
>> support, well, what can you say?
> 
> As one of the key perpetrators of that particular aspect of 3261, I'm 
> comfortable in saying that we added it in a slapdash fashion at the 11th 
> hour, without sufficient analysis (and I mean this in a self-deprecating 
> way, without intending to cast aspersions on any of 3261's editors). 
> Interactions between usages in a dialog were ridiculously 
> underspecified. Robert spent a long time trying to rationalize this 
> behavior after the fact, with the result being RFC 5057. And RFC 5057 
> really helps a lot for the minority of implementors who actually know it 
> exists. However, the issue is complicated enough that it takes 26 pages 
> to untangle it, and the rules are a tangle of exceptions. Go read 5057 
> again, and tell me that people are more likely to get that right than 
> they are to get confused.
> 
>> It was used primarily because contacts in dialogs often don't have the 
>> gruu property, and GRUU hasn't been widely implemented. Has that 
>> situation changed? Will 3265bis somehow result in widespread 
>> implementation of GRUU by registrars? 
> 
> 3265bis is less mature than GRUU (in that one is a -00 individual draft, 
> and the other is in the RFC editor queue). I think it's reasonable to 
> rely on predecessor technologies.
> 
> 
> /a
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip