Subject: [sipcore] draft-sparks-sipcore-refer-clarifications-05: comments

From: Brett Tate <[email-masked]>
Date: Mon, 10 Nov 2014 13:28:39 -0500

Hi,

Draft-sparks-sipcore-refer-clarifications-05 section 3 indicates the
following:

"A UA that will accept a REFER request needs to include a GRUU in the
 Contact header field of all INVITE requests.  This ensures that out-
 of-dialog REFER requests corresponding to any resulting INVITE
 dialogs arrive at this UA.  Future extensions (such as
 [I-D.sparks-sipcore-refer-explicit-subscription]) might relax this
 requirement by defining a REFER request that cannot create an
 implicit subscription."

Concerning the first sentence, potentially should reword so that it isn't
just for INVITE.

Is there a reason why not relaxing the requirement for REFER notifiers
which only send NOTIFY with Subscription-State terminated?

For instance, RFC 6665 section 4.4.1 indicates that the NOTIFY does not
create a dialog usage.

"Dialogs usages are created upon completion of a NOTIFY transaction
 for a new subscription, unless the NOTIFY request contains a
 "Subscription-State" of "terminated.""

Thanks,
Brett

---

From: Robert Sparks <[email-masked]>
Date: Wed, 19 Nov 2014 14:05:33 -0600

> which only send NOTIFY with Subscription-State terminated?
Such a thing would be very unusual (you are required to send an immediate
NOTIFY - so you're talking about an endpoint that can always _immediately_
send a notify with subscription-state terminated. Unless it's lying 
about the
result of the referenced request, that means it's guaranteed to immediately
know the result of that request (usually an INVITE).

But even if you could guarantee such unique conditions, there is always
the possibility that the NOTIFY could be answered with a 503/Retry-After,
or any other response indicating that the NOTIFY needs to be reconditioned
and submitted again, during which time there is dialog reusage.

>   "Subscription-State" of "terminated.""
Sigh. I should have argued harder for "created and immediately destroyed"
when we were working on 6665 instead settling on this text, because of the
possibility pointed to above of getting a non-200 response that indicates
something should be changed (or delayed) and the request resubmitted.