Adam Roach wrote:
In 4.5.2, it seems to me to be unwise to allow the notifier to respond
403 to subscriptions within existing dialogs, as that is a significant
constriction of the current requirements.
In what way? Implementors are still allowed to accept such incoming
connections, but one of the key changes I think is necessary in this
revision is to free implementors from the morass of coding for dialog
sharing -- because MOST PEOPLE GET IT WRONG. I see little value with
maintaining backwards "compatibility" with a feature that, by and large,
wasn't compatible between multiple implementations in the first place.
I'd be interested in hearing in what ways "most people" get it wrong.
Getting the common cases of dialog sharing right isn't so difficult.
I expect that "most people" get corner cases wrong in lots of things.
This only frees implementors if:
- they are capable of creating their own gruus without registration
- or they ONLY work with registrars that support GRUU.
- and they only interact with other UAs that support 3265bis.
Notably, any phone that *might* be attached to a registrar that doesn't
support GRUU will need to support dialog sharing. And any UA that might
establish a dialog with somebody that doesn't implement 3265bis should
be prepared to have the other end initiate dialog sharing.
I guess the question is whether the bis should indicate what should be
done to maintain backward compatibility with 3265, or if that should
simply be left for implementors to figure out for themselves. I can see
the merit in leaving the old cruft out so that it *eventually* goes away.
Thanks,
Paul
_______________________________________________
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
