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

[Adam Roach <[e-mail]>]

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