Subject: RE: [Sip] non-SUBSCRIBE subscriptions

From: "MANSOOR Usama RD-ILAB-LON" <[email-masked]>
Date: Wed, 3 Nov 2004 11:33:57 +0100

So will there no longer be such a thing as 'implicit subscriptions'?

- Usama

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Adam Roach
Sent: 02 November 2004 16:34
To: Paul D.Smith
Cc: SIP WG
Subject: Re: [Sip] non-SUBSCRIBE subscriptions

Paul D.Smith wrote:

>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.
>  
>

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

_______________________________________________
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

_______________________________________________
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