SIP-Specific Event Notification
RFC 6665

Note: This ballot was opened for revision 07 and is now closed.

(Pete Resnick) Yes

Comment (2012-04-26 for -08)
No email
send info
This is an incredibly well-written protocol document, and so clear that I'm fine with a Yes ballot.

I can't convince myself any of these comments are DISCUSSion worthy, but I do think they all need addressing one way or the other.

1.2

   It is inappropriate to fail to comply with
   "SHOULD"-strength requirements whimsically or for ease of
   implementation.

I think that can be strengthened: "It is violation of a requirement of the specification to fail to comply with 'SHOULD' requirements whimsically or for ease of implementation."

3.1.1

Here and elsewhere, you say that something "MUST be defined by the event package". That's an odd use of MUST, since it's clearly not a protocol requirement for the implementer of the protocol, but rather a requirement for the protocol extension writer. I can see saying that "event packages will make such-and-so REQUIRED" to put implementers on notice that they will find the requirement in the event package, but I do wish you had a non-2119 way of expressing requirements for event package writers.

   A natural consequence of this scheme is that a SUBSCRIBE request with
   an "Expires" of 0 constitutes a request to unsubscribe from an event.

Maybe this is obvious and implicit for someone familiar with SIP, but you do mean "a SUBSCRIBE request *on the same dialog* with an 'Expires' of 0", right? You don't actually get to the fact that a SUBSCRIBE is dialog-creating until 4.1.2.1, but I think you can still make it clear here. Or you can just skip it, since it's covered in 4.1.2.3.

4.1.2.1

   The "Expires" header field in a 200-class response to SUBSCRIBE
   request indicates the actual duration for which the subscription will
   remain active (unless refreshed).

This implies to me (though it's not stated explicitly here) that the response MAY have a different Expires value than provided in the request. Is that true? You say something about this in 4.2.14, but not here.

4.1.3 For 'probation', you say "the client SHOULD retry at a later time". Is that really what you mean? What harm comes to me if I decide not to retry? Couldn't I decide to not retry? Do you mean "MAY retry at a later time", or perhaps "SHOULD NOT retry immediately". Some piece of information is missing here. I suspect this has some parallel to 'deactivitated' and migration, but I don't get it.

4.2.1 Why the out clause for 3515? If it's causing problems, why not just say MUST NOT and update 3515 to deprecate the use?

4.2.2 Seems to me that if a NOTIFY receives a failure response and the subscription is therefore removed, the notifier should *not* send an additional 'terminated' NOTIFY. But the state machine seems to indicate that it should. Was that the intention?

4.5.2 Dialog sharing seems like a mess. Why is this not a SHOULD NOT?

5 Generally: It seems like this entire section might work better as an appendix. It's not part of the protocol per se; it's extension documentation instructions. Also, the 2119 language in this section seems weird, especially in 5.4.1 and 5.4.12. Those seem like inappropriate uses of 2119. The only one I can make a case for is the one in 5.3.2, and even there I'm not convinced. (I notice that for some reason you *didn't* use 2119 language in 5.4.6 and 5.4.7, and *never* used MAY in this section.) Again, it would be nice if you could find a better way to express this. I'm not convinced 2119 is useful or appropriate here.

7.1 2119 language in IANA Considerations sections always worry me. When you say, "Registrations with the IANA MUST include...", are you putting a requirement on IANA? On the Expert Reviewer? I would rather see these removed and instead indicate that it is "required information in the template" or something like that.

7.1.1 s/initial IANA registration for event types will be empty/initial IANA registry for event types will be empty

7.2 Why is "Standards Action" required for this?

8.4

   token-nodot       =  1*( alphanum / "-"  / "!" / "%" / "*"
                            / "_" / "+" / "`" / "'" / "~" )

Do you really want to allow "***---***"? Are you sure you don't want:

   token-nodot       =  alphanum *( ( "-"  / "!" / "%" / "*"
                            / "_" / "+" / "`" / "'" / "~" ) alphanum )

instead?

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) No Objection

(Ralph Droms) (was Discuss) No Objection

Comment (2012-05-01)
No email
send info
Thanks for addressing my DISCUSS position.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-04-26 for -08)
No email
send info
Thanks for the detailed list of changes from 3265.

---

Does this also update 3261?

(Stephen Farrell) (was Discuss) No Objection

Comment (2012-04-25 for -08)
No email
send info
Clarified my questions in a call with Robert. Be nice if we can document
the reality sometime soon but this isn't the place to do it.

(Brian Haberman) No Objection

(Russ Housley) (was Discuss) No Objection

Barry Leiba No Objection

Comment (2012-04-25 for -08)
No email
send info
Many thanks to Paul for an excellent and thorough PROTO writeup.  A note here: the IPR and copyright stuff you note from the nits checklist is just the boilerplate that's automatically put in by xml2rfc (or manually put in otherwise; it's correct in this document).  We should update the checklist to have current references, and to reflect the current position of that boilerplate in the documents.

I also really like the "SHOULD" note in Section 1.2.

On the IANA Considerations, thanks for retaining the context here, so the original document can be properly obsoleted.  One suggestion:

In the base section 7:
OLD
   (This section is not applicable until this document is published as
   an RFC.)
NEW
   The subsections here are for current reference, carried over from
   the original specification.  The only IANA action requested here is
   to change all registry references that point to RFC 3265, and have
   them point to this RFC.

...or some such text, so that the registries now cite the new document.

(Martin Stiemerling) No Objection

Comment (2012-04-23 for -08)
No email
send info
Section 4.1.2.4., paragraph 4:

>    Due to the potential for both out-of-order messages and forking, the
>    subscriber MUST be prepared to receive NOTIFY requests before the
>    SUBSCRIBE transaction has completed.

+ packet loss which can also lead to NOTIFY requests arriving before the SUBSCRIBE transaction to be completed.

(Sean Turner) No Objection