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

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