Subject: RE: [Simple] 200 vs. 202

From: "Brian Stucker" <[email-masked]>
Date: Wed, 21 Nov 2001 13:23:05 -0600

You bring up an important point about the watcher having to wait for the
response to the SUBSCRIBE before processing the NOTIFY. This could give us
problems if the 200 takes a long time getting back to the watcher, and the
NOTIFY, in the meantime, is just sitting there being retransmitted over and
over, waiting for a response. Depending on the T1 and T2 timers being used,
this could create a race condition that might cause a subscription to fail
because there was no response to the immediate NOTIFY.

In general, what happens when a NOTIFY to the inital SUBSCRIBE fails to be
acknowledged?  Does the subscription go away like it does for later NOTIFY
messages? The reason I ask, is because it would seem to leave the watcher in
an undefined state. What are the responsibilities of a watcher that sends a
SUBSCRIBE, gets a 200, and then no NOTIFY?

A possible solution would be to silently throw away and NOTIFY messages that
we have not gotten a response (200) on the request to create a dialogue for
(the SUBSCRIBE). If we do that, then we could wait for some period of time
(say the expires header in the 200 response). If that period of time elapses
without a NOTIFY, then we send the SUBSCRIBE again (if we got a 200).

Thoughts?

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 3:18 PM
To: simple
Subject: RE: [Simple] 200 vs. 202

While I disagree with Brian and Jonathan about the problems presented
by having multiple PAs in the network, I am willing to quit the topic
for the sake of moving forward.

I am very wary, however, of any discussions which use arguments about
the general case of forking of SUBSCRIBE requests instead of those
involving multiple PAs. I wouldn't have even entered the fray if the
arguments presented by several parties didn't attack the very notion
of SUBSCRIBE forking (instead of limiting themselves to presence in
particular).

So, with my capitulation, I'll attempt to enumerate what I think
we've all agreed on:

 1. SUBSCRIBE requests may fork.

 2. Subscribers may choose to accept zero or more of the
    NOTIFY requests that arrive by responding to them with
    a 200.

 3. Subscribers may choose to reject zero or more of the
    NOTIFY requests that arrive by responding to them with
    a 481.

 4. Subscribers _to_ _presence_ _information_ SHOULD or MUST (I
    don't personally care which) accept exactly one NOTIFY
    message with a 200, and reject all others with a 481.

 5. Subscribers _to_ _presence_ _information_ select which
    NOTIFY to accept based on the dialog information
    established by the 2xx response to the SUBSCRIBE.

Moving forward, then, I see two sets of problems to be addressed:

Forking SUBSCRIBE:
  - How do we perform authentication for forked SUBSCRIBE messages?
    This is actually a more general problem which can be phrased
    "How do we perform authentication for forked XXX messages?" where
    XXX includes INVITE. I would *really*, *really* like to see a
    more general solution to this problem before we start trying
    to cobble something together for SUBSCRIBE.

  - How do we protect against the DOS attacks that Robert describes?

Presence:
  - In a forking situation, it is likely (probable, even) that the
    NOTIFY requests will arrive at the subscriber before the 2xx
    reply to the SUBSCRIBE. Does that mean that the response to the
    NOTIFY requests will be suppressed until the SUBSCRIBE request
    completes? If so, this should be well documented in the
    presence event package.

  - Some of the arguments made against accepting multiple dialogs
    created by a single SUBSCRIBE were privacy based: an aggregation
    point must exist in the network to provide a consistent policy.
    Given that there is no way to enforce that only one dialog is
    accepted, are there any privacy concerns that can arise from
    rogue clients accepting all received NOTIFYs?

/a

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple