[sipcore] Comments to draft-sparks-sipcore-refer-explicit-subscription-02.txt

[Ivo Sedlacek <[e-mail]>]

Hello,

I reviewed the draft-sparks-sipcore-refer-explicit-subscription-02.

Generally, I consider it in a good shape.

COMMENT 1:
---------------------
Abstract states: "
   The Session Initiation Protocol (SIP) REFER request, as defined by
   RFC3515, triggers an implicit SIP-Specific Event Notification
   framework subscription.
"
It would be good to also point out that RFC4488 tried to remove this trigger for creating implicit notification but did not do the work entirely so usage of RFC4488 may need to rely on application logic in UAS handling the REFER request.
---------------------

COMMENT 2:
---------------------
2. Introduction states: "
  REFER as defined by [RFC3515] triggers an implicit SIP-Specific Event
   Framework subscription.  Sending a REFER within a dialog established
   by an INVITE results in dialog reuse and the associated problems
   described in [RFC5057]."

Again, it would be good to also state that usage of RFC4488 together with application logic enables prevention of creation of implicit subscription. However, it would be good to have a protocol mechanism which do not need to rely on the application logic.
---------------------

COMMENT 3:
---------------------
6. Introduction states: "
UA MUST NOT include the
   'explicitsub' or 'nosub' option tag in the Require header field of
   any SIP response other than a 421 response to a REFER request."

IMO, this is against RFC3261 stating ("Any extensions applied to a non-421 response MUST be listed in a Require header field included in the response.").

I have seen that this has already been raised at http://www.ietf.org/mail-archive/web/sipcore/current/msg06338.html and I would be happy with resolution proposed there.
---------------------

COMMENT 4:
---------------------
Some of the security issues apply only to explicitsub, but the text does not make it clear.
---------------------

PROPOSED SOLUTION 4:
---------------------
it might be good to split the section 8.  Security Considerations to three subsections, 
	- 1st subsection focused on generic issues applicable to both explicitsub and nosub
	- 2nd subsection focused on issues applicable to explicitsub only
	- 3rd subsection focused on issues applicable to nosub only
---------------------

Kind regards

Ivo Sedlacek