Subject: [sipcore] 3265bis-02

From: Adam Roach <[email-masked]>
Date: Wed, 18 Aug 2010 16:31:51 -0500

[as an individual]

I have issued a new version of RFC3265bis, reflecting the changes 
discussed in Stockholm and Anaheim. This version closes all the formal 
open issues (although it has recently come to my attention that the 
document still needs to be updated to reflect the IANA registration 
policies detailed by sipchange).

New version:

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

Diffs from -01:

   http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc3265bis-02.txt

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Aug 2010 11:55:29 -0400

[as individual]

I have a couple of comments about this version:

First, I question some changes you made to the state model picture in 
4.1.2. Now Timer N expiry is a trigger for moving to Terminated from 
Pending or Active. How can that be right?

I think this would be right if it referenced the (unnamed) timer set 
from the expires value in the most recently received notify.

Second, section 8.2 is now entirely empty since the table 2/3 info was 
removed. Section 8.1 was similar, but now has a few words describing its 
new methods. Perhaps this section should have a few words about the new 
headers. Or else it can just be removed entirely.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 19 Aug 2010 17:05:27 -0500

[as individual]

> Pending or Active. How can that be right?

This is part of the change to make Timer N apply to subscription 
refreshes. When a subscription is in Active (and even Pending, if 
permission pends for longer than a refresh period), the subscriber 
periodically sends new SUBSCRIBE messages to refresh the expiration. The 
document *now* says that these refreshes cause Timer N to be set. If no 
NOTIFY arrives before Timer N expires, then the subscription will 
transition from Active (or Pending) to Terminated.

> removed.

Right. With this change, section 8.2 simply serves as a top-level 
container for sections 8.2.1, 8.2.2, and 8.2.3.

This is the same as is done for sections 3, 4, 4.1, 4.2, 4.4, 6, 7, 8.3, 
and 9.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Aug 2010 19:33:59 -0400

> transition from Active (or Pending) to Terminated.

I understand how Timer N should apply after sending a resubscribe.
But that is not how I read the diagram. The diagram says to me that the 
following is a common scenario:

- I send an initial subscribe and enter notify-wait
- I receive a NOTIFY with pending, and enter pending.
- If I don't get another notify within Timer N,
   I enter terminated state.
- To avoid that fate, before Timer N expires I can send a resubscribe,
   thus resetting Timer N and (I guess) going back into notify-wait.

If I send a subscribe that goes into pending, it could be hours or days 
until the notifier's user gets around to blessing me. The above analysis 
says that for all that time I'll be sending a new resubscribe every 
Timer N seconds. That doesn't seem desirable.

IIUC, the intended behavior is that when in pending or active, one is 
waiting for the *expires* timer to run down. (It of course gets updated 
with each notify received.) When it runs down enough, a new subscribe 
should be sent, and then timer N is set again for the first notify after 
that. But I don't get that behavior out of the existing diagram.

One way to show that would be:

 From pending and active,
- sending a resubscribe causes transition back to notify-wait.
- exhaustion of the expires timer causes transition to terminated.

> This is the same as is done for sections 3, 4, 4.1, 4.2, 4.4, 6, 7, 8.3, 

ok.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Aug 2010 11:05:27 +0200

Hi,

Some initial comments on 3265bis-02.

EDITORIAL:
==========

QE1: The docuements sometimes uses "message", sometimes "request", and sometimes nothing after the method name. We should be consistant.

QE2: There are many instances of "as defined in SIP [ref]", "as describe in SIP [ref]", etc. I think it is enough to only use the reference.

Example:

Section 3.1.3: "create a dialog as defined in SIP[3261]" -> "create a dialog[3261]"

Section 3.2: "target refresh request, as that term is defined in SIP[3261]" -> "target refresh request[3261]"

QE3: Expand GRUU abbreviation on first occurance.

QE4: Where the document talks about crating a dialog, should it be dialog usage instead?

QE5: Section 4.1.2.2: When reading the text regarding RFC 5839 it seems like it's mandatory to support. Also, if we want to talk about 5839 in specific sections I think we will need text elsewhere also. I would suggest to remove the text from 4.1.2.2, and have a specific section where we talk about compatibility with 5839.

QE6: Section 3.1.1: "the implied default is defined" -> "the implied default MUST be defined"

QE7: Section 3.2.1: "header fields will contain a single" -> "header fields MUST contain a single"

QE8: Section 4.1.2.3: "the final NOTIFY may or may not". Remove "or may not".

QE9: Section 4.1.2.4: "Documents which define new event packages MUST" -> "Event package specifications MUST"

FUNCTIONAL:
===========

QF1: Section 3.1.3 says that Event packages must define behavior for SUB requests without Accept header. 3261 says that, in case there is no Accept header, the default value is "application/sdp". I don't think 3265bis should change that.

QF2: The document contains lots of SHOULDs, without any explanation on when something applies, and when it doesn't. It makes it very difficult to specify and perform conformance tests, and in most of the 3265bis occurances it might also cause state unsynch among entities. So, I think we should have MUST - or explain when SHOULD applies, and when it doesn't.

QF2a: Section 4.1.2.2 says that if specific SUB responses are received, the subscriber should consider the subscription terminated.

QF2b: Section 4.1.2.4 says that the subscriber SHOULD reject a NOT after Timer N expireation. 

QF2c: Section 4.2.1.4 says that the notifier SHOULD send a NOT with "terminated" state.

QF2d: Section 4.2.2 says that the notifier SHOULD remove the subscription if NOT fails due to Timer F expireation.

QF2e: Section 4.2.3. I guess a notifier that doesn't support PINT MUST return 489 in case of SUB without an Event header field?

QF3: Section 4.3. Do we need to say that the Timer N expiration procedures etc also apply to stateless proxies? Or, is that supposed to be covered in 4.4? I am not sure I understand what "Common behavior" means, but I assume it refers to both UAs and proxies?

QF4: Section 4.4.1 says that a subscription is terminated after a notifier sends a NOT with "terminated". I think we should add ", or when Timer N expires.", to cover the case when there is no NOT.

Regards,

Christer