Dale Worley wrote:
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.
That seems a reasonable approach, with the caveat that I'd call out the
circumstances surrounding the SHOULD explicitly. That is, I would phrase
it like "...MUST use GRUU as their contact URI for all dialogs unless
they cannot obtain a GRUU. Note that the only circumstances in which a
notifier cannot obtain a GRUU is when they don't meet the criteria for
creating self-made GRUUs and their registrar does not support GRUU."
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.)
I'm happy to rephrase this to be use RFC 2119 language.
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.
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.
The list you refer to is copied from various parts of the original text
(i.e., 3265). The intention is for this document to obsolete 3265, so
referring to 3265 for procedures would make no sense.
/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
