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 On Fri, 2007-06-15 at 12:58 +0300, Aki Niemi wrote: > Inline. > > ext Martin Hynar wrote: > > 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". > > 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. > > > 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. > > 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 > > meta information. > > Entity-tag for one. Added: > > ...meta-information related to a resource, e.g., its current > entity-tag value. > > > 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. > > Don't understand what you mean by "multiple documents". What use-case do > you have in mind? > > > 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? > > 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. > > > 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. > > 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 +-------------------------------------+ Martin Hynar Software Specialist TietoEnator Czech Software Center Phone: +420 597 459 713 Mobile: +420 724 432 817 E-mail: [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
