Subject: [Sip] Several notes to entity-tags for SIP Events

From: Martin Hynar <[email-masked]>
Date: Wed, 13 Jun 2007 13:32:35 +0200

Hello,

I read through the draft sip-subnot-etags-00 and I found several issues
that needs to be clarified.

1. typo in introduction
In sentence "Typically, a SUBSCRIBE request is issued whenever a
subscription is installed, periodically refreshed or terminated." shall
be probably "NOTIFY".

2. some kind of misleading in text when talking about SIP PUBLISH
message as an example of entity tags usage. When talking about PUBLISH I
think, there is slightly different usage scenario. In response to
initial PUBLISH message, server generates entity tag. Client is mandated
to use this entity tag if she wants to change state of that particular
presence source. If this entity tag is not used, PUBLISH message
installs new presence source and not overwrites the former state. For
purposes of presence notifications, these publications are then
composed. This usage is a bit different that supposed for SUBSCRIBE
messages, The text evokes feeling of something different.

3. What is exactly meant with "Meta-information-check"? What is this
meta information.

4. Besides RLS subscriptions there is one more problem, the
subscriptions to changes in documents. So extend the problem also on
notification about changes in multiple documents.

5. In my mind, there popped up an idea to move the SIP-Etag into the
response to SUBSCRIBE message. This way client can be informed about the
entity tag also without sending the NOTIFY message at all. Have you
considered this possibility?

6. What about situation when e.g. presentity has no presence document
installed and some body subscribes her. The the notifier sends empty
document, wouldn't be there some special handling? E.g. no entity tag.

br, Martin

+-------------------------------------+ 
  Martin Hynar 
  Software Specialist

  TietoEnator 
  Czech Software Center 
  Phone: +420 597 459 713 
  Mobile: +420 724 432 817 
  E-mail: [email-masked]

  Vystavni 292/13 
  CZ-709 16 Ostrava

www.tietoenator.com

Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, you are hereby notified
that any unauthorized use, distribution or copying of this communication
is strictly prohibited. If you have received this communication in
error, please notify us immediately by replying to the message and
deleting it from your computer. Thank You.
_______________________________________________
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: Aki Niemi <[email-masked]>
Date: Fri, 15 Jun 2007 12:58:49 +0300

Inline.

> subscription is installed, periodically refreshed or terminated." shall 

No, it really means SUBSCRIBE, but I think it's a little confusing. Perhaps:

	Typically, a SUBSCRIBE request is issued by the subscriber
         whenever it needs a subscription to be installed, periodically
         refreshed or terminated.

> messages, The text evokes feeling of something different.

Yes, the details in PUBLISH are a bit different. Do you have better 
wording in mind?

> 3. What is exactly meant with "Meta-information-check"? What is this 

Entity-tag for one. Added:

	...meta-information related to a resource, e.g., its current
  	entity-tag value.

> notification about changes in multiple documents.

Don't understand what you mean by "multiple documents". What use-case do 
you have in mind?

> considered this possibility?

Yes, this was considered, but rejected as there is currently no use for 
it in the 2xx. The way the "Suppress-Notify-If-Match" condition works is 
that a) the etag is the same and a 204 response is generated and b) the 
etag has changed and a NOTIFY is generated, which includes the new etag 
in SIP-ETag.

> document, wouldn't be there some special handling? E.g. no entity tag.

There is nothing specific to subnot-etags in this case.

The server basically has two choices. Either it generates an etag for 
the empty document, and as a publication is received, changes that etag 
to a new value; or the server treats the empty document as some sort of 
floor value, gives it a constant etag value, in which case a subscriber 
that fetched an empty document once, would never get an update in case 
it happened to fetch again when there was no active publication.

Either option is completely an implementation detail.

Cheers,
Aki

---

From: Martin Hynar <[email-masked]>
Date: Tue, 19 Jun 2007 10:10:45 +0200

Hello,

ad 1: Now I understand the meaning correctly.

ad 4: Here I have on mind subscription to changes in documents created
using mechanism described in sip-xcap-config (formerly
sipping-config-framework). This way, client might subscribe to changes
in multiple documents e.g. under one AUID:

Event:
ua-profile;profile-type=application;auid="rls-services";Vendor="v";Model="m";Version="v"

This way all documents owned by subscriber are subscribed for changes.
If changes in multiple documents occur, the server might notify about
these changes using one notification and format described in
simple-xcap-diff. However, this way the notification carries change in
two independent resources. And the problem, if subscriber includes
"Supported: subnot-etags" then server shall include SIP-ETag header
containing actual entity value of the resource in the notification body.
How this notification can carry entity values of multiple documents?

ad 2: At the moment I have no better wording in my mind but I will still
think about it.

br, Martin

  TietoEnator 
  Czech Software Center 
  Phone: +420 597 459 713 
  Mobile: +420 724 432 817 

  Vystavni 292/13 
  CZ-709 16 Ostrava

www.tietoenator.com