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

From: Brett Tate <[email-masked]>
Date: Tue, 2 Dec 2014 15:35:11 -0500

Hi,

Thanks for the response; reply is inline.

>> Is there a reason why not relaxing the requirement
>> for REFER notifiers which only send NOTIFY with
>> Subscription-State terminated?
>
> Such a thing would be very unusual

It is not unusual.  RFC 3515 explicitly discusses it.

"Note that agents accepting REFER and not wishing to hold
 subscription state can terminate the subscription with this initial
 NOTIFY."

"A minimal, but complete, implementation can respond with a single
 NOTIFY containing either the body:

    SIP/2.0 100 Trying"

> 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.

As far as I know, RFC 6665 indicates that the additional dialog usage has
not been created.

>> 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.""
>
> 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.

Concerning sigh, me too.  If I had known that the mandatory NOTIFY would
eventually lead to mandatory GRUU, I might have argued harder to remove the
mandate during the switch from BYE Also to REFER.

And sigh again because the issues raised by
draft-kaplan-dispatch-gruu-problematic still exist.

---

From: Andrew Allen <[email-masked]>
Date: Wed, 3 Dec 2014 19:27:26 +0000

Brett

We should focus next on solving the issues identified in draft-kaplan-dispatch-gruu-problematic.

Andrew

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Brett Tate
Sent: Tuesday, December 02, 2014 3:35 PM
To: [email-masked]; [email-masked]
Subject: Re: [sipcore] draft-sparks-sipcore-refer-clarifications-05: comments

Hi,

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

"Note that agents accepting REFER and not wishing to hold  subscription state can terminate the subscription with this initial  NOTIFY."

"A minimal, but complete, implementation can respond with a single  NOTIFY containing either the body:

    SIP/2.0 100 Trying"

> 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.

As far as I know, RFC 6665 indicates that the additional dialog usage has not been created.

>> For instance, RFC 6665 section 4.4.1 indicates that the NOTIFY does 
>> not create a dialog usage.
>>
> 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.

Concerning sigh, me too.  If I had known that the mandatory NOTIFY would eventually lead to mandatory GRUU, I might have argued harder to remove the mandate during the switch from BYE Also to REFER.

And sigh again because the issues raised by draft-kaplan-dispatch-gruu-problematic still exist.

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore