Subject: [Sip] Open issue in subnot-etags: suppress body or entire NOFITY?

From: Aki Niemi <[email-masked]>
Date: Sun, 19 Mar 2006 18:50:15 +0200

The cases where etags should work are basically these:

1) Subscription refresh.

The expiry needs to be updated, so the conditional SUBSCRIBE will need
to succeed 2xx. Potentially, the entire NOTIFY could be suppressed,
since the Subscription-State ought to be known at that point already.

2) Subscription resume.

A new subscription that continues from a past, terminated subscription.
There, we can't suppress the entire first NOTIFY, since it is needed to
complete the dialog. Suppressing the body works fine.

3) Fetch

This SUBSCRIBE will ever only trigger one NOTIFY at most, so suppressing
that in case the state is know would work.

Out of these, #1 at least requires a 200-class response to the
SUBSCRIBE; #2 requires at least a 200-class response and the first
NOTIFY without a body; #3 could do with the HTTP-style If-None-Match in
SUBSCRIBE and a 412 response.

Proposal 1) Same machanism for all. Clearly, the lowest common
denominator is, as Adam suggests, a Suppress-Body-If-Match header field
in a SUBSCRIBE. If this condition succeeds, the NOTIFY is sent but with
an empty body. Proposal is to use this mechanism for all cases above.

Proposal 2) Differentiate subscriptions and fetches. All subscriptions
would use Suppress-Body-If-Match like above, and fetches/polls would use
another Notify-If-No-Match header field, and when that condition fails,
the SUBSCRIBE gets a 412 response, and no NOTIFY is sent.

Proposal 3) Differentiate all of the three cases. Subscription refreshes
would use Suppress-Notify-If-Match, as above; subscription resumes would
use Suppress-Body-If-Match, as above; fetches and polls would use
Notify-If-No-Match as above.

I'd personally go with proposal 1, simply to keep this sweet and simple.
But I don't think proposal 2 or 3 sound entirely unreasonable either.

COmments?

Cheers,
Aki

_______________________________________________
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