Subject: Re: [sipcore] Comments on 3265bis-02 (CHH)

From: Adam Roach <[email-masked]>
Date: Thu, 30 Jun 2011 15:56:16 -0500

On 8/23/10 4:05 AM, Christer Holmberg wrote:
>
> QE1: The docuements sometimes uses "message", sometimes "request", and sometimes nothing after the method name. We should be consistant.

I changed them all to "request."

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

Fixed.

>
> QE3: Expand GRUU abbreviation on first occurance.

Done.

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

In a few places, yes. Fixed.

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

There's nothing to be done for compatibility with 5839, except for not 
running timer N when you get a 204. I don't believe the document 
warrants an entire new section to say this one thing.

I have added the word "optional" to the sentence to remove any 
implication that 5839 is mandatory to implement: "...such as the 204 
response defined for use with the optional extension described in 
[RFC5839]..."

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

Okay.

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

Okay.

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

I think both possibilities are as important as each other, and I 
wouldn't want to de-emphasize either of them.

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

Okay.

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

That text is from 3265, and I'm certain that implementations are out in 
the field that count on such a behavior. What you propose isn't 
backwards compatible.

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

The vast, vast majority of these predate 3265bis. Blindly taking 
normative statements from SHOULD to MUST will arbitrarily make legacy 
implementations noncompliant -- and, in some cases, incompatible.

Your alternate suggestion steps on one of the things that I think has 
gone very wrong with RAI in the past few years. Please bear with me 
while I vent my spleen for a moment on that topic.

In terms of explaining when SHOULD-level normative statements can be 
violated -- I strongly disagree with the current (RAI-only) cultural 
bent that requires all SHOULD normative requirements to be accompanied 
by enumerated lists. Such an approach effectively removes "SHOULD" and 
"SHOULD NOT" completely from the lexicon, replacing them with "MUST... 
unless..." and "MUST NOT... unless...".

If you go back 10 years, or step outside of RAI, there's a culture of 
*allowing* those things that don't break interoperability. All of the 
SHOULD-level statements in 3265/3265bis are statements of things that 
make the system work *better*; none of them are required for the system 
to *work*.

I understand that some implementors will do profoundly stupid things, 
cut corners, and intentionally misread portions of specifications to 
suit their level of skill, motivation, and timelines. And I know that 
using "SHOULD" appears to give them some kind of a moral "out" to do so. 
But there's nothing we can say here that will change that kind of 
behavior: failing to implement a MUST is just as easy as failing to 
implement a SHOULD, and there's no armed force that's going to police 
the difference.

But it's insulting to implementors and constraining to future extensions 
to place hard prohibitions in protocol specifications where they aren't 
necessary. Good implementors can determine when circumstances warrant 
violation of SHOULD-strength requirements, even if they fall outside 
circumstances we can presently enumerate.

That said, I'm not opposed to adding *examples* of exceptions to 
SHOULD-strength statements. I just don't think they're necessary. So, if 
you'd like to see such examples added: send text.

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

In this particular instance, I agree that a change may be helpful. I 
think it really should be a normative "MUST".

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

This is a good example where failing to implement the SHOULD won't cause 
interop problems. I don't think a change is warranted.

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

This is a good example of legacy behavior that we can't change without 
potentially making existing deployment non-interoperable. Additionally, 
since both ends are running the same timers, this NOTIFY is really just 
a safety net. Failing to send it won't cause any problems unless 
something *else* has been mis-implemented.

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

Again, no interop issues here. There's non-normative text that tells 
implementors why they *want* to do this. But failing to do it doesn't 
break the system.

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

What's really important here, from an interop perspective, is that the 
transaction fails. Exactly *how* it fails isn't important. And what's 
cool is that there's no hope of it succeeding, since there's no event 
package specified. So it's really just a Nice Thing [tm] for 
troubleshooting.

> QF3: Section 4.3. Do we need to say that the Timer N expiration procedures etc also apply to stateless proxies?

I'm confused. Stateless proxies don't maintain state. They don't need to 
run timer N.

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

The statement wasn't meant to be exhaustive, but I can see how it might 
be confusing. Of course, those aren't the only two circumstances that 
can result in a subscription going away -- there are a wide variety of 
error situations that can cause that. I've added text:

   A subscription is destroyed after a notifier sends a NOTIFY request
   with a "Subscription-State" of "terminated," or in certain error 
situations.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 30 Jun 2011 16:26:23 -0500

On 8/19/10 6:33 PM, Paul Kyzivat wrote:
>
>
> Adam Roach wrote:
>>
>> [as individual]
>>
>> On 8/19/10 10:55 AM, Paul Kyzivat wrote:
>>> 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?
>>
>> 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.
>
> 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.

The issue with that approach is that it causes confusion with regards to 
RFC 3857 (winfo) handling. I'm hesitant to take the subscription out of 
"pending" and "active," since it will almost certainly confuse people 
trying to implement winfo. ("But RFC XXXX says that you leave 'active' 
state when you send a re-SUBSCRIBE, so don't we need to change the value 
in the winfo doc?").

That said, I can see why the diagram is wrong, since Timer N is still 
actually running. So what we really need to say for the exit from 
"pending" and "active" is something like "Timer N fires before receiving 
a NOTIFY for a subscription refresh." That's a bit long for the diagram. 
Perhaps "Re-subscription times out," with an explanation below? 
Something like:

                        +-------------+
                        |    init     |<-----------------------+
                        +-------------+                        |
                               |                           Retry-after
                         Send SUBSCRIBE                    expires
                               |                               |
                               V          Timer N Fires;       |
                        +-------------+   SUBSCRIBE failure    |
           +------------| notify_wait |-- response; --------+  |
           |            +-------------+   or NOTIFY,        |  |
           |                   |          state=terminated  |  |
           |                   |                            |  |
++========|===================|============================|==|====++
||        |                   |                            V  |    ||
||  Receive NOTIFY,    Receive NOTIFY,             +-------------+ ||
||  state=active       state=pending               | terminated  | ||
||        |                   |                    +-------------+ ||
||        |                   |          Re-subscription     A  A  ||
||        |                   V          times out;          |  |  ||
||        |            +-------------+   Receive NOTIFY,     |  |  ||
||        |            |   pending   |-- state=terminated; --+  |  ||
||        |            +-------------+   or 481 response        |  ||
||        |                   |          to SUBSCRIBE           |  ||
||        |            Receive NOTIFY,   refresh                |  ||
||        |            state=active                             |  ||
||        |                   |          Re-subscription        |  ||
||        |                   V          times out;             |  ||
||        |            +-------------+   Receive NOTIFY,        |  ||
||        +----------->|   active    |-- state=terminated; -----+  ||
||                     +-------------+   or 481 response           ||
||                                       to SUBSCRIBE              ||
|| Subscription                          refresh                   ||
++=================================================================++

             In the state diagram, "Re-subscription times out" means
             that an attempt to refresh or update the subscription
             using a new SUBSCRIBE request does not result in a
             NOTIFY request before the corresponding Timer N expires.

What do you think?

/a