Subject: RE: [Simple] 200 vs. 202

From: [email-masked]
Date: Tue, 20 Nov 2001 15:18:10 -0600

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