Subject: [Sip] non-SUBSCRIBE subscriptions

From: "Paul D.Smith" <[email-masked]>
Date: Tue, 2 Nov 2004 10:18:06 -0000

Adam,

Can I please ask for some clarification on one aspect of RFC3265, Session
Initiation Protocol (SIP)-Specific Event Notification"?  Section 3.2
contains
the following text.

  "If any non-SUBSCRIBE mechanisms are defined to create subscriptions..."

I have always interpreted this as being the "window" required to allow REFER
initiated subscriptions or (perish the thought) subscriptions created by a
new
and hitherto undefined SIP method.  However, we have encountered customers
who
view this text as implying that a subscription can also be created using any
out-of-band mechanism, and therefore that from a SIP perspective, a NOTIFY
can
arrive without any prior SIP exchanges.

We see this as a major source of future interoperability problems as people
create their own, ad-hoc out-of-band subscription creation systems so we
want
to clarify whether this was the intention.  If it were not, we would like to
see a clear statement on the WG and in future updates to RFC3265 clarifying
this situation.

Thanks,
Paul D Smith
Network Protocols Group 
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: [email-masked] 
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Adam Roach <[email-masked]>
Date: Tue, 02 Nov 2004 10:33:53 -0600

>arrive without any prior SIP exchanges.

Such was the intention. This text was a source of much contention during 
the development of this document, and it was repeatedly removed, 
re-added, and re-crafted to try to find a balance.

The paragraph that you cite is the final compromise. It defines some 
very strict guidelines about how any such mechanisms must behave. In 
particular:

>   Designers of such mechanisms are also
>   warned to make a distinction between sending a NOTIFY message to a
>   subscriber who is aware of the subscription, and sending a NOTIFY
>   message to an unsuspecting node.  The latter behavior is invalid, and
>   MUST receive a "481 Subscription does not exist" response.... 
>   In other words, knowledge of a subscription must exist in both the
>   subscriber and the notifier to be valid, even if installed via a
>   non-SUBSCRIBE mechanism.
>

To be clear:

    * It is a violation of the specification to send a NOTIFY to a node
      that you do not know for a fact is expecting that NOTIFY.
    * It is a violation of the specification to send a 200-class
      response to a NOTIFY if you were not told, via some mechanism, in
      advance, that such a NOTIFY would be arriving.

All of that is historical information at this point. For future 
revisions of the specification, it is highly likely that these 
provisions will be removed, as no published mechanisms have taken 
advantage of them (except for REFER, which will likely be revised to 
remove the implicit subscription in favor of an explicit subscription.)

/a