Subject: [Sip] New draft about etags in subscribe/notify

From: Aki Niemi <[email-masked]>
Date: Fri, 27 Jan 2006 10:38:22 +0200

Hi All,

I just submitted a new draft defining extensions to SIP events for 
allowing conditional subscribes:

http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-00.txt

The issue this attempts to fix were documented in a sipping draft [1], 
and discussed in IETF 63. My impression of that discussion was moderate 
interest, so here's the mechanism proposal.

Comments are very welcome.

Cheers,
Aki

[1] 
http://www.softarmor.com/wgdb/docs/draft-niemi-sipping-subnot-issues-00.txt 
(expired)

_______________________________________________
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

---

From: "Nataraju A B" <[email-masked]>
Date: Mon, 30 Jan 2006 16:00:59 +0530

Dear Neimi, 

Please find some comments on the draft
"draft-niemi-sip-subnot-etags-00.txt"

1. If I understand correctly, if the e-tags match between the SUBSCRIBE
requests and the one available with NOTIFIER, then the notify request
need not carry the message body (carrying the current state of the
event). 
	But in section 4.3 Suppressing NOTIFY Bodies section, it's been
mentioned as if the entity-tags do not match, the notifier MUST
suppress the body of the resulting NOTIFY request... 

Suggestion 1:  when the suppression has to happen, can we suppress the
whole NOTIFY message instead of only body of the NOTIFY request... since
NOTIFY is not a mandatory request for each successful subscription... 

Suggestion 2: when the suppression has to happen, can we return a
success response (for instance 203 "Subscription extended" or some thing
similar reason phrase) instead or 412 response... ?

<<<<<<<<<
Suggestion 3: to fetch or poll for the subscription state, overload the
SUBSCRIBE header and add a parameter in event header which specifies
fetch the current state of the subscription. Similarly we can add one
more parameter value for poll operation also... 
			OR
Other option would be we can add one more header which specifies action
like fetch, poll, subscribe, terminate
	Subscribe-Action: "subscribe"/"fetch"/"poll"/"terminate"....

We also need to describe the notifier behavior for all these
operations....

Thanks & Regards,
Nataraju A.B.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Aki Niemi
Sent: Friday, January 27, 2006 2:08 PM
To: [email-masked]
Subject: [Sip] New draft about etags in subscribe/notify

Hi All,

Cheers,
Aki

[1] 
http://www.softarmor.com/wgdb/docs/draft-niemi-sipping-subnot-issues-00.
txt 
(expired)

---

From: Aki Niemi <[email-masked]>
Date: Mon, 30 Jan 2006 13:00:01 +0200

Hi Nataraju,

Thanks for the comments, please find my answers below.

> suppress the body of the resulting NOTIFY request... 

Uhh, it should say that if the condition fails, i.e., the entity-tags 
*do* match (since the condition was a if-none-match), then the NOTIFY is 
suppressed.

Thanks for catching this.

> NOTIFY is not a mandatory request for each successful subscription... 

Actually, the NOTIFY is mandatory after each successful subscribe. So 
that doesn't really work but...

> similar reason phrase) instead or 412 response... ?

...this is another alternative, and the next best one after suppressing 
just the NOTIFY body. That is, we definitely want a 2xx for the 
SUBSCRIBE, so that the expiry can be extended, even if the conditional 
request fails.

But the problem is that RFC3265 says a NOTIFY must always follow a 2xx 
to a SUBSCRIBE; the request also contains the Subscription-State header 
field, which contains relevant state information. So it seems the NOTIFY 
simply can't be suppressed totally, and we have to make due with 
suppressing just the body.

> more parameter value for poll operation also... 

I don't quite follow. This is the default operation anyway, i.e., a 
SUBSCRIBE with Expires: 0 fetches the current state without creating a 
subscription.

What the etags allow is to communicate which version of state the 
fetcher already has possession of, so that it need not be sent again.

> 	Subscribe-Action: "subscribe"/"fetch"/"poll"/"terminate"....

This is all there already, and depends on the Expires header field value 
of the SUBSCRIBE. Perhaps it could have been clearer to define specific 
methods for these operations, but this is the age-old debate about which 
is better:

	do(method, params)

vs.

	do_method(params)

Both work.

Cheers,
Aki