It seems that with a few adjustments we get to the point that the -bis- is quite reasonable and straightforward regarding "subscribe dialog re-use" issues.
Clearly, we have to moderate 4.5.1 to "Notifiers MUST implement GRUU and SHOULD use a GRUU as their contact URI for all dialogs (including non-subscription dialogs)." The reason for the SHOULD is that it means what we must say, "use a GRUU unless there is a very good reason that you can't", by which we mean, "unless you can't get a GRUU" -- there being no other reason that a notifier can't use a GRUU fairly easily. 4.5.1 already requires a subscriber to use a separate dialog if the destination of the subscription is a GRUU. Actually, that sentence doesn't contain MUST, so it should be rephrased "If so, the subscriber MUST create the subscription on a new dialog, using the GRUU as the request URI for the new SUBSCRIBE." (Leaving unspecified the possibility that the subscriber could add Route headers to cope with mandatory outbound proxies and other odd circumstances.) 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 the future, when -bis- has been implemented and subscribers can reasonably depend on all notifiers to implement it, then we can safely allow notifiers to be more particular. At least, we need to narrow the statement so that notifiers can only reject shared-dialog SUBSCRIBEs with 403 if the notifier always uses a GRUU as its contact URI. In regard to the long list following "To implement dialog sharing", is any of this material new? As far as I can tell, it is a summary of 3265/5057. If so, it should be explicitly labeled as such, and refer the reader to those RFCs as the normative text. If not, the relationship of this list with those RFCs needs to be made explicit. Dale _______________________________________________ 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
