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

[Christer Holmberg <[e-mail]>]

 
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