Subject: [SIP] New SUBSCRIBE/NOTIFY draft available

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 25 Oct 2000 10:57:28 -0500 (CDT)

For some reason, I haven't seen the I-D action go by for
the SUBSCRIBE/NOTIFY draft yet. Thanks to everyone who gave
input while I was putting this together. Further comments are
very welcome. If comments warrant and time permits, I may well
release a -02 version of this draft in time for the 49th
IETF meeting.

---------------------------------------------------------------------------
Abstract

     This document describes an extension to the Session Initiation
     Protocol (SIP) [1] . The purpose of this extension is to provide
     a generic and extensible framework by which SIP nodes can request
     notification from remote nodes indicating that certain events
     have occurred.

     Concrete uses of the mechanism described in this document may be
     standardized in the future.
---------------------------------------------------------------------------

http://search.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-01.txt

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: hammer michael <[email-masked]>
Date: Thu, 26 Oct 2000 14:14:55 -0700

A couple minor comments:

Sec 5.1.5, assume "must" = "MUST"

Sec 5.1.6, para 7:  Would immediate fetch while subscription pending be 
some type of 18x response?

Sec 5.1.6, para 8:  Implies that one must subscribe before one can 
subscribe, seems recursive.  Could one assume that the resource to which 
one would be subscribing would have already registered and that the 
registration would have already defined the basis for access, e.g. 
restricted list or promiscuous (open to anyone)?

Sec. 5.2.2, para 8:  If the assumption is that configuration is done out of 
band, why not assume that the subscribe will be static provisioned and 
would therefore submit the SUBSCRIBE before the NOTIFY.  That could obviate 
the need for Notify without Subscription.

Sec 5.2.3:  Could repeated non-ACK of Notifies be used before cancelling a 
subscription.  It seems the subscription would be rather fragile under 
unreliable network conditions.  That might be rather service-dependant.  I 
would not want a long-running subscription to a non-call-related service to 
terminate just because I turned my computer off.  In mobile environments, 
one could think of other cases where communications may be interrupted.

Mike

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 30 Oct 2000 11:20:12 -0600 (CST)

>Sec 5.1.5, assume "must" = "MUST"

Thanks. This is going away with the distinction beween third-party
and call-party subscriptions.

>some type of 18x response?

No. It would be a 200 response, as in a normal subscription refresh.

>restricted list or promiscuous (open to anyone)?

I'm not sure what you mean by this. If I have a client running, and
you want to subscribe to some state in it, I might expect it to
interactively ask me, for each subscription, if I wish to allow
the subscription to be processed.

I would assume you mean this paragraph:

  "Note that privacy concerns may require that notifiers either use 
   access lists or ask the user on a per-subscription basis whether 
   a particular remote node is allowed to subscribe to a certain set
   of events. If such authorization fails, the notifier should reply 
   to the request with a "403 Forbidden" request. See section 7."

Perhaps your confusion stems from what, exactly, is meant by "user."
In this context, I meant the owner of the node that is being asked
to act as a notifier. You may have read it such that it means the
owner of the node acting as a subscriber. I'll attempt to clarify
this text in the next draft.

>the need for Notify without Subscription.

This mechanism is based on the same concept as third-party REGISTER
messages. My client may never send a SUBSCRIBE, but might receive
NOTIFY responses. I'm merely pointing out that such a mechanism makes
sense.

>one could think of other cases where communications may be interrupted.

This is solved by periodic subscription refreshes, just like registrations.
In the situation you cite (turning your computer off), the subscription
will be re-instantiated by your client when you start it up again.

---

From: hammer michael <[email-masked]>
Date: Mon, 30 Oct 2000 13:41:49 -0800

See further comments.

Mike

>No. It would be a 200 response, as in a normal subscription refresh.

If you send a 200, then is your statement that the "subscription is 
pending" still valid?

>this text in the next draft.

I think is was the "per-subscription basis" that threw me.  I was thinking 
that you were deciding whether to allow the subscription based on the 
presence of a subscription list.  Re-reading it, you seem to say that the 
subscription determines whether to get more information or make the 
decision with the current information.

I was attempting to make some distinction between the purpose of the 
Register (which could contain out-of-band information, and which would by 
its presence be an offer to communications conditioned on events, albeit 
with some caveats or controls) and the Subscription which appears to be the 
agreement to the offer and request to be notified of those 
events.  Essentially, this appears to be a brokering type of 
arrangement.  I guess in the above instance you are either pre-approved or 
a "credit-check" is performed.

>NOTIFY responses. I'm merely pointing out that such a mechanism makes

My point was that it might be just as easy to statically configure the 
subscriber as the notifier, as either could be done out-of-band.  One 
additional concern might be that blindly sending Notifies, when you are not 
even sure someone is there might be a waste of bandwidth.  How does one 
know when the subscriber is "present" on the network?  In a mobile network, 
the registration expires, the user de-registers, or a registration could be 
overwritten if it is the oldest.

>will be re-instantiated by your client when you start it up again.

The concern that a Notify is not ack'd could still terminate a subscription 
still holds.

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 30 Oct 2000 15:08:31 -0600 (CST)

>If you send a 200, then is your statement that the "subscription is 

By "pending," I meant "active." I'll change it to "active."

>decision with the current information.

I'm not sure if we have this straight yet, so I'll give a
concrete example.

Let's imagine that you are sitting in front of your PC, with a
SIP multimedia client running. You're talking to someone, and
have whatever call waiting feature that your client may have
turned off. I call and get a busy indication. I want to find
out when your terminal is free so that I may immediately ring
you back at that time.

My client sends yours a "SUBSCRIBE." Your client may:

a) Automatically accept the subscription,

b) Accept the subscription only if I appear on the list
   you have entered into your client of "people allowed to
   subscribe to my terminal state,"

c) Accept the subscription only if I do not appear on the list
   you have entered into your client of "people not allowed to
   subscribe to my terminal state," or

d) Pop up a dialog box saying "Adam Roach wants to subscribe
   to your terminal state. Is that OK?" and accept the subscription
   only if you click on "Yes."

It is situation (d) that I am trying to describe.

(Yes, there are other, more complicated criteria that allow/do-not-allow
lists that could be applied. In fact, the really useful ones probably
fall in this category).

>The concern that a Notify is not ack'd could still terminate a subscription 

No, it doesn't. If you aren't responding to NOTIFY messages, you
are obviously no longer online. Once you become available again,
you'll either immediatly send a SUBSCRIBE to put the subscription
in place (e.g. client reboot), or it will send another SUBSCRIBE
before the expiration of the current subscription.

And, yes, such behaviour can be service specific, as you point out.
Note that the cancellation of a subscription by a notifier when
he knows that the subscriber is offline is a MAY, not a MUST or 
even a SHOULD.

---

From: hammer michael <[email-masked]>
Date: Tue, 31 Oct 2000 11:06:45 -0800

Comments embedded.

Mike

>By "pending," I meant "active." I'll change it to "active."

Understood.

>lists that could be applied. In fact, the really useful ones probably

I would suggest saying:  "on a per SUBSCRIBE message basis"

>before the expiration of the current subscription.

Here, you seem to agree with me that it is repeated failure to respond to 
more than one (1) NOTIFY message rather than the failure to respond to a 
single NOTIFY message, which is what the draft says.  Using more than one 
failure would enable the time-scale of the NOTIFIES to be proportional to 
the time-scale of the subscription.  Using multiple NOTIFYs would also give 
the service more leeway in deciding when to cancel the subscription short 
of the expires time.

You seem to have some very specific scenarios in mind that are very call 
specific and very short timed.  I would only ask that you consider whether 
it is possible to have much longer-term standing subscriptions.  Also, in 
BW constrained, error prone environments (read mobile) you might want to 
consider the possible loss of a single message.  Also, if I have more than 
one standing subscription, I don't necessarily want to flood the local 
connection every time I re-establish contact.

>he knows that the subscriber is offline is a MAY, not a MUST or

In the last paragraph of 5.2.3 you say SHOULD.  The MAY refers to the 
decision whether to send the NOTIFY.
Enough said, there is wiggle room within the current wording.

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 31 Oct 2000 11:02:23 -0600 (CST)

hammer michael writes:

<SNIP about asking the user for permission before accepting
a subscription>

>I would suggest saying:  "on a per SUBSCRIBE message basis"

No, I really mean on a per-subscription basis. If you subscribe
to my terminal for terminal state, I want to be asked if you're
allowed to do so. However, if you refresh this subscription one
minute later, I don't want to be bothered with the same question.
I've already *given* you permission to subscribe.

>decision whether to send the NOTIFY.

Aha. We were looking at different paragraphs. Mine had to do with
out-of-band methods of determining that the client is unavailable;
yours had specifically to do with failure to respond to NOTIFY
requests.

>Enough said, there is wiggle room within the current wording.

Yes, but I'd still encourage dropping a subscription if a notify
fails -- allowing the SUBSCRIBE refresh to pick it back up
again in the case of a transient failure.

Remember that, like all other (non-INVITE, non-ACK) SIP methods,
NOTIFY will retransmit 11 times over the course of 35.5 seconds.
You'd have to have a network outage lasting more than half a
minute to inadvertantly remove a subscription for a host that
is arguably (although only weakly arguably) still connected.