Subject: [sipcore] 3265 Open Issue: 202 Response Code

From: Adam Roach <[email-masked]>
Date: Tue, 02 Mar 2010 17:22:50 -0600

[as a participant]

In Stockholm, we had a discussion of the open issues in the 3265bis One 
of the topics that we discussed was the utility of the 202 response code 
in RFC 3265. A summary of the conversation can be found in the minutes:

http://www.ietf.org/proceedings/75/minutes/sipcore.html#Open%20Issue:%20The%20Fate%20of%20202

There was no clear agreement in that conversation, and several 
participants seemed to hold very nuanced opinions on the topic.

In order to drive conversation on the topic, I will propose the 
following text as a starting point.

The key change is in Section 8.3.1, which I propose to be updated as 
follows:

    For historical purposes, the 202 (Accepted) response code is
    added to the "Success" header field definition.

    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 this
    specification MUST treat an incoming 202 response as identical
    to a 200 response, and MUST NOT generate 202 response codes to
    SUBSCRIBE or NOTIFY messages.

That is the change in policy that I am proposing. Several other changes 
in the document follow from this change; I list them below.

In section 4.1.2.1, the third paragraph will be truncated after the word 
"immedately." In its revised form, it will simply read:

    This SUBSCRIBE request will be confirmed with a final response.
    200- class responses indicate that the subscription has been
    accepted, and that a NOTIFY will be sent immediately.

In section 4.2.1.1, the 6th and 7th paragraphs (both starting wht "If 
the notifier...") will be combined into a single paragraph reading:

    Once the notifier determines that it has enough information to
    create the subscription (i.e., it understands the event package,
    the subscription pertains to a known resource, and there are no
    other barriers to creating the subscription), it creates the
    subscription and a dialog, and returns a 200 (OK) response.

In section 4.2.1.3, the fifth paragraph will replace "202 Accept"
with "200 OK", with the final result being:

    If the notifier owner is interactively queried to determine
    whether a subscription is allowed, a 200 (OK) response is returned
    immediately.  Note that a NOTIFY message is still formed and
    sent under these circumstances, as described in the previous
    section.

In section 5.4.6, the final sentance of the final paragraph will be 
removed, resulting in the following text:

    Information in this section includes details of how to authenticate
    subscribers and authorization issues for the package.

The first paragraph of section 6.2 will be updated to read:

    The mere act of returning certain 4xx and 6xx responses to
    SUBSCRIBE requests may, under certain circumstances, create
    privacy concerns by revealing sensitive policy information.  In
    these cases, the notifier SHOULD always return a 200 (OK) response.
    While the subsequent NOTIFY message may not convey true state,
    it MUST appear to contain a potentially correct piece of data
    from the point of view of the subscriber, indistinguishable from
    a valid response.  Information about whether a user is authorized
    to subscribe to the requested state is never conveyed back to
    the original user under these circumstances.

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 3 Mar 2010 03:01:19 +0100

Rather than change for change sake, what problem are we actually trying to fix here. The meeting notes refer to HERFP but that is hardly enlightening.

regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: Tuesday, March 02, 2010 11:23 PM
> To: SIPCORE
> Subject: [sipcore] 3265 Open Issue: 202 Response Code
> 
> [as a participant]
> 
> In Stockholm, we had a discussion of the open issues in the 
> 3265bis One of the topics that we discussed was the utility 
> of the 202 response code in RFC 3265. A summary of the 
> conversation can be found in the minutes:
> 
> There was no clear agreement in that conversation, and 
> several participants seemed to hold very nuanced opinions on 
> the topic.
> 
> In order to drive conversation on the topic, I will propose 
> the following text as a starting point.
> 
> That is the change in policy that I am proposing. Several 
> other changes in the document follow from this change; I list 
> them below.
> 
> In section 4.1.2.1, the third paragraph will be truncated 
> after the word "immedately." In its revised form, it will simply read:
> 
> In section 4.2.1.1, the 6th and 7th paragraphs (both starting 
> wht "If the notifier...") will be combined into a single 
> paragraph reading:
> 
> In section 5.4.6, the final sentance of the final paragraph 
> will be removed, resulting in the following text:
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Mar 2010 06:42:24 +0100

Hi,

I think this is a little related to one issue/question a raised a while ago, related to the new meaning of 200/202 for SUBSCRIBE.

I assume the 200/202 response would cease the re-transmission of the SUBSCRIBE request, but what is the *state* after 200/202 has been received and before the first NOTIFY has been received? 

If I remember correctly, dialogs won't be established until the NOTIFY requests arrive, so is there some "pre-dialog" state between the SUB 200/202 and the first NOTIFY? Or, is there a subscription dialog usage already after 200/202, eventhough it's not "used" for anything until the NOTIFY comes?

And, for how long will the UAC wait for the first NOTIFY, in case it for whatever reason does not arrive immedialtely? 

So, if the SUB 200/202 response doesn't do anything else than cease the SUB re-transmission, maybe 202 would be more appropriate then 200? It's not a suggestion at this point - just some loud thinking :)

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adam Roach [[email-masked]]
Sent: Wednesday, March 03, 2010 1:22 AM
To: SIPCORE
Subject: [sipcore] 3265 Open Issue: 202 Response Code

[as a participant]

/a

---

From: Robert Sparks <[email-masked]>
Date: Fri, 19 Mar 2010 13:52:15 -0500

The notes were pointing to why we ended up with 202 in the first place. We introduced it when we figured out QAUTH wouldn't work because of the fixed non-INVITE transaction length. Shortly after, because of HERFP, we realized that we had to require the immediate NOTIFY from each branch. When we added the Subscription-State header to the NOTIFY (including it's potential value of "pending"), all utility for 202 vs 200 went away.

The problem we are trying to solve is that we have interoperability issues with implementations trying to treat 202 and 200 as meaning something
different to the application that receives them. Because of the issues pointed to above, they _can't_ and whenever I've found someone trying to
do something differently on receipt of a 202, they really wanted to be using Subscription-State from the NOTIFY anyhow.

This has also been a honeypot for inducing bad implementation. I've seen early implementations that would terminate a dialog if they
got a 202 to the SUBSCRIBE and a NOTIFY with a state of active. I've seen people try to build "conformance tests" that would complain
if that happened. Both are not helpful behaviors.

This is a rough spot (even if it is a very small one). We have a chance to clean it up.

RjS

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 19 Mar 2010 15:34:46 -0400

> in the document follow from this change; I list them below.

My understanding is that the SIP convention is that all 2xx responses
are considered successful and must be accepted as such by all SIP
elements.  If there is further semantics attached to a particular 2xx
response, an element that knows those semantics may act on them.  The
above text suggests that a SIP element might legitimately not treat
certain 2xx responses as successful in certain circumstances.  I would
prefer something like this:

        Previous versions of the SIP Events Framework assigned specific
        semantics to the 202 response code as a response to a SUBSCRIBE
        request, viz., that the SUBSCRIBE request was understood but the
        subscription had not yet been approved by the notifier's policy.
        This version merges this meaning into the semantics of the 200
        response, and hence conforming implementations SHOULD respond to
        a SUBSCRIBE request with a 200 response rather than a 202
        response in this case (like all other success cases).  As is
        true in all circumstances where a UA receives a 2xx response
        that does not have specifically defined semantics, a conforming
        implementation that receives a 202 response MUST treat it as
        identical to a 200 response.

You can change that "SHOULD" to "MUST", but I like it as SHOULD, as
there might be special circumstances that dictate some other 2xx
response.  In any case, the subscriber will accept any 2xx as
successful.

Dale