Subject: Re: [sipcore] 202 response in draft-ietf-sipcore-rfc3265bis-03

From: Adam Roach <[email-masked]>
Date: Tue, 18 Oct 2011 15:42:17 -0500

On 8/31/11 9:51 AM, Hadriel Kaplan wrote:
>
> I recommend that be changed to this, assuming it's correct:
>     This document does not specify the use of the 202 response code in
>     conjunction with the SUBSCRIBE or NOTIFY methods.  Previous versions
>     of the SIP Events Framework assigned specific semantics to the 202
>     response code.  Due to response handling in forking cases, a UAC may
>     not have received the response as a 202, and thus it could never have
>     been guaranteed to be received.  Furthermore, there was no actual use
>     difference for the 202 compared to a 200, given a NOTIFY is sent after
>     the subscription is processed and it conveys the correct state.  Since
>     it was found that implementations were handling 202 differently from 200,
>     the 202 response is being deprecated to make it clear there is no such
>     difference and they should not be handled differently.
>
>     Implementations conformant with the current
>     specification MUST treat an incoming 202 response as identical to a
>     200 response, and MUST NOT generate 202 response codes to SUBSCRIBE
>     or NOTIFY requests.
>

I like the additional text, and think it's an improvement. I've done a 
tiny bit of wordsmithing, and have added it to the -04 version of the 
document.

Given that this is the only last call comment received, I'll submit -04 
with this change, and ask Paul to request publication shortly.

/a

---

From: Brett Tate <[email-masked]>
Date: Wed, 19 Oct 2011 03:32:10 -0700

> with this change, and ask Paul to request publication shortly.

You also received the following comments/questions.

http://www.ietf.org/mail-archive/web/sipcore/current/msg04264.html

Concerning the following draft-ietf-sipcore-rfc3265bis-03 section 4.1.2.2 snippet indicating subscriber "MUST consider the subscription terminated", the draft should potentially better indicate that the MUST does not preempt the RFC 5057 notes (such as for 482 and 483) which indicate situations where the dialog would not be terminated.

Section 4.1.2.2: "If a SUBSCRIBE request to refresh a subscription receives a 404, 405, 410, 416, 480-485, 489, 501, or 604 response, the subscriber MUST consider the subscription terminated.  (See [RFC5057] for further details and notes about the effect of error codes on dialogs and usages within dialog, such as subscriptions)."

Do the RFC 5057 notes for 482 edge condition still apply?  It indicates an RFC 3263 advancing situation which might trigger a 482 response and allow the subscription to remain.  If the RFC 5057 notes for 482 edge condition still apply, is it adequately indicated within the above snippet?

Thanks,
Brett

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Oct 2011 17:16:02 -0500

> You also received the following comments/questions.

Sorry! I missed this when I searched through the archives.

> Concerning the following draft-ietf-sipcore-rfc3265bis-03 section 4.1.2.2 snippet indicating subscriber "MUST consider the subscription terminated", the draft should potentially better indicate tha…

I guess they do apply, so we probably ought to give them some 
consideration. I'd hate to reiterate all the relevant notes in this 
document, since most of them are pretty baroque, and would only serve to 
confuse the topic under discussion. How about:

    If a SUBSCRIBE request to refresh a subscription receives a 404, 405,
    410, 416, 480-485, 489, 501, or 604 response, the subscriber MUST
    consider the subscription terminated unless extenuating circumstances
    exist that would otherwise keep the dialog alive. See [RFC5057  <http://tools.ietf.org/html/rfc5057>] for
    further details and notes about the effect of error codes on dialogs
    and usages within dialog, such as subscriptions.

/a

---

From: Brett Tate <[email-masked]>
Date: Thu, 20 Oct 2011 06:23:45 -0700

The proposed change addresses my concern and questions.

Thanks,
Brett

From: Adam Roach [mailto:[email-masked]]
Sent: Wednesday, October 19, 2011 6:16 PM
To: Brett Tate
Cc: [email-masked]
Subject: Re: [sipcore] 202 response in draft-ietf-sipcore-rfc3265bis-03

document.

I guess they do apply, so we probably ought to give them some consideration. I'd hate to reiterate all the relevant notes in this document, since most of them are pretty baroque, and would only serve to confuse the topic under discussion. How about:

   exist that would otherwise keep the dialog alive. See [RFC5057<http://tools.ietf.org/html/rfc5057>] for

/a