Subject: [sipcore] WGLC of draft-ietf-sipcore-rfc3265bis-03.txt

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Aug 2011 10:00:52 -0400

<as co-chair>

This is an announcement of a Working Group Last Call on 
draft-ietf-sipcore-rfc3265bis-03.txt:

http://www.ietf.org/id/draft-ietf-sipcore-rfc3265bis-03.txt

Please review and provide any comments you have on the document no later 
than Friday September 16, 2011.
Comments should be sent to the document authors and the SIPCORE WG 
mailing list.

     Thanks,
     Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Aug 2011 10:51:49 -0400

Howdy,
One of the changes made by 3265bis relative to 3265 is the deprecation of the 202 response.  I have two questions related to this change:

1) The current text for deprecation of 202 in 3265bis not only updates 3265 but also RFC 4660, since that also uses 202.  Should 3265bis also update RFC 5839, which uses 202 in example flows and notes?

2) The current draft does not say why the 202 response was deprecated.  Through some googling, I found this:
http://www.ietf.org/proceedings/75/minutes/sipcore.html#Open%20Issue:%20The%20Fate%20of%20202
And I went and listened to the audio archive for IETF 75 SIPCORE meeting.

3265bis-03 says this in section 8.3.1:
   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.  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 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.

-hadriel

On Aug 26, 2011, at 10:00 AM, Paul Kyzivat wrote:

> <as co-chair>
> 
> This is an announcement of a Working Group Last Call on draft-ietf-sipcore-rfc3265bis-03.txt:
> 
> Please review and provide any comments you have on the document no later than Friday September 16, 2011.
> Comments should be sent to the document authors and the SIPCORE WG mailing list.
> 
>     Thanks,
>     Paul
> <ATT00001..c>