From simple-admin@mailman.dynamicsoft.com Sat Dec 1 05:01:12 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09207 for ; Sat, 1 Dec 2001 05:01:11 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB19xE7x002480 for ; Sat, 1 Dec 2001 04:59:14 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23403 for ; Sat, 1 Dec 2001 05:01:05 -0500 (EST) Date: Sat, 1 Dec 2001 05:01:05 -0500 (EST) Message-Id: <200112011001.FAA23403@mailman.dynamicsoft.com> Subject: mailman.dynamicsoft.com mailing list memberships reminder From: mailman-owner@mailman.dynamicsoft.com To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk This is a reminder, sent out once a month, about your mailman.dynamicsoft.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@mailman.dynamicsoft.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@mailman.dynamicsoft.com. Thanks! Passwords for simple-archive@lists.ietf.org: List Password // URL ---- -------- simple@mailman.dynamicsoft.com ifheto http://mailman.dynamicsoft.com/mailman/options/simple/simple-archive%40lists.ietf.org From simple-admin@mailman.dynamicsoft.com Mon Dec 3 12:38:15 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16255 for ; Mon, 3 Dec 2001 12:38:15 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB3HYH4I002286; Mon, 3 Dec 2001 12:34:20 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01747; Mon, 3 Dec 2001 12:36:05 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00987 for ; Mon, 3 Dec 2001 08:38:50 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29173; Mon, 3 Dec 2001 08:38:23 -0500 (EST) Message-Id: <200112031338.IAA29173@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-04.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 03 Dec 2001 08:38:22 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Presence Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-04.txt Pages : 39 Date : 30-Nov-01 This document proposes an extension to SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. Subscriptions and notifications of user presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence and Instant Messaging (CPIM) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011130161204.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011130161204.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Dec 3 15:57:19 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00006 for ; Mon, 3 Dec 2001 15:57:19 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB3KsD4I003724; Mon, 3 Dec 2001 15:54:13 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02356; Mon, 3 Dec 2001 15:56:02 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02345 for ; Mon, 3 Dec 2001 15:55:39 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB3Krj4I003714; Mon, 3 Dec 2001 15:53:45 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Dec 2001 15:55:14 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E866@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Robert Sparks , "'simple@mailman.dynamicsoft.com'" Cc: "Jon' 'Peterson (E-mail)" , Jonathan Rosenberg Subject: RE: [Simple] WGLC - watcherinfo MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 3 Dec 2001 15:55:12 -0500 There's been one (1) response to this so far - if you have a comment get it in before 12/7. Please drop a note if you think the draft is good to go as is so we don't misinterpret silence as lack of consideration. RjS > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Wednesday, November 28, 2001 3:50 PM > To: 'simple@mailman.dynamicsoft.com' > Cc: Jon' 'Peterson (E-mail); Jonathan Rosenberg > Subject: [Simple] WGLC - watcherinfo > > > There's been very little response to the > request for discussion on watcherinfo. > Hopefully, that means the drafts are ready > to go. > > This is the last call for comments on these drafts: > draft-ietf-simple-winfo-package-00.txt > draft-ietf-simple-winfo-format-00.txt > > This call will close on 12/21, but please have > comments on technical deficiencies in by 12/7 > so that we can discuss them at IETF 52. > > RjS > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 4 01:07:10 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02584 for ; Tue, 4 Dec 2001 01:07:10 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB462F4I005845; Tue, 4 Dec 2001 01:02:15 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03968; Tue, 4 Dec 2001 01:04:02 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03957 for ; Tue, 4 Dec 2001 01:03:47 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB461r4I005839; Tue, 4 Dec 2001 01:01:53 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 01:03:21 -0500 Message-ID: From: Jonathan Rosenberg To: Sean Olson , Robert Sparks , "'simple@mailman.dynamicsoft.com'" Cc: "Jon' 'Peterson (E-mail)" , Jonathan Rosenberg Subject: RE: [Simple] WGLC - watcherinfo MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 4 Dec 2001 01:03:17 -0500 -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Wednesday, November 28, 2001 5:21 PM To: 'Robert Sparks'; 'simple@mailman.dynamicsoft.com' Cc: Jon' 'Peterson (E-mail); Jonathan Rosenberg Subject: RE: [Simple] WGLC - watcherinfo >Well, if you insist. I don't see the need for the "event" >in the XML winfo format. The "status" seems to carry >everything that is needed. No, and for much the same reason we have asked for various reason phrases in the Subscription-Expires header for sip-events. If a subscriptions state goes to terminated, the reason it went there (rejected vs. deactivated) makes a difference in the subsequent processing. > The "first-subscribed" element >also seems a bit odd. Either this requires the PA to >maintain information that lasts longer than a subscription >(a bad idea) or it is a mislabelled and probably useless >piece of information. Good point. I don't know what I was thinking here. I think its useful to know when they first subscribed, but as soon as the subscription expires, this data would be lost, and a new subscription would result in a new "first-subscribed" value. >What is the purpose of providing >(optionally) the "notify-address" in the winfo? If there was a reason, it slips my mind at this time.... I'm happy to remove it. -Jonathan R. >-----Original Message----- >From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >Sent: Wednesday, November 28, 2001 3:50 PM >To: 'simple@mailman.dynamicsoft.com' >Cc: Jon' 'Peterson (E-mail); Jonathan Rosenberg >Subject: [Simple] WGLC - watcherinfo > > >There's been very little response to the >request for discussion on watcherinfo. >Hopefully, that means the drafts are ready >to go. > >This is the last call for comments on these drafts: >draft-ietf-simple-winfo-package-00.txt >draft-ietf-simple-winfo-format-00.txt > >This call will close on 12/21, but please have >comments on technical deficiencies in by 12/7 >so that we can discuss them at IETF 52. > >RjS > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple > --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 4 01:36:04 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05221 for ; Tue, 4 Dec 2001 01:36:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB46XC4I006006; Tue, 4 Dec 2001 01:33:12 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04091; Tue, 4 Dec 2001 01:35:03 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04076 for ; Tue, 4 Dec 2001 01:34:35 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB46Wg4I005998; Tue, 4 Dec 2001 01:32:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 01:34:10 -0500 Message-ID: From: Jonathan Rosenberg To: "'salvatore.loreto@libero.it'" , Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: Event header in the Register request Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 4 Dec 2001 01:34:09 -0500 > -----Original Message----- > From: salvatore.loreto@libero.it [mailto:salvatore.loreto@libero.it] > Sent: Friday, November 30, 2001 4:18 AM > To: jdrosen@dynamicsoft.com > Cc: simple@mailman.dynamicsoft.com > Subject: Event header in the Register request > > > Hi all, > > In the Scenario "Presence Server with Client > notifications",there isn't > an Event header in the Register Request. REGISTER doesn't use Event header, only SUBSCRIBE. > I suppose isn't necessary > because will be the client to inform the watcher if he > support(in which > case he send a 200 OK)or not(in which case he send a 489)a particular > event,like Presence for example. > In the Scenario "Presence Server with Server notifications",in the > registration phase,i think its mandatory including an Event header, > otherwise it is impossible for the server to understand if the > registration is for Presence,for example, or other event. We've discussed this previously. There is no way, when you REGISTER with caller-preferences indicating support for a method (like SUBSCRIBE) to indicate packages you support. In such a case, the client would simply reject subscriptions for packages it didn't support with a 489. SHould this become a real problem, we could always add a caller preferences parameter for packages, but I think this is a problem in theory only at this time. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 4 01:39:34 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05516 for ; Tue, 4 Dec 2001 01:39:34 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB46aA4I006059; Tue, 4 Dec 2001 01:36:10 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04124; Tue, 4 Dec 2001 01:38:02 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04108 for ; Tue, 4 Dec 2001 01:37:38 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB46ZU4I006055; Tue, 4 Dec 2001 01:35:30 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 01:36:58 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brian Stucker'" , Torrey Searle , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Watcher Information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 4 Dec 2001 01:36:56 -0500 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Wednesday, November 28, 2001 1:26 PM To: Torrey Searle; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Watcher Information > >Why can't the scheme in the -01 events draft be used? It gives you an overall expiration >time and the client should already know it from the presence subscription messages. I have argued that I thik there should be a unification between these two, as they do the same thing. The only difference is that one is "in-band", and this one is "out of band". However, I agree that in either case, knowing the expiration time would be useful. I will add an attribute for that. Thanks, Jonathan R. -----Original Message----- From: Torrey Searle [mailto:tsearle@antihe.ro] Sent: Wednesday, November 28, 2001 12:07 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] Watcher Information Would it be possible to add an attribute to the watcher info for expiration? It seems like being told how long a pending or active subscription could be usefull information. Torrey Searle _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 4 01:56:12 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07088 for ; Tue, 4 Dec 2001 01:56:11 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB46rB4I006154; Tue, 4 Dec 2001 01:53:12 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04211; Tue, 4 Dec 2001 01:55:03 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04196 for ; Tue, 4 Dec 2001 01:54:44 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB46qo4I006146; Tue, 4 Dec 2001 01:52:50 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 01:54:18 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brian Stucker'" , Jonathan Rosenberg , "'Michael Hammer'" Cc: "'adam.roach@ericsson.com'" , simple , Alex Nava , Patrick Sollee , Sanjoy Sen Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 4 Dec 2001 01:54:10 -0500 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Wednesday, November 28, 2001 1:15 AM To: Jonathan Rosenberg; 'Michael Hammer' Cc: 'adam.roach@ericsson.com'; simple; Alex Nava; Patrick Sollee; Sanjoy Sen Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. > >Good idea (HTTP url)... Thanks. >The thought had occurred to me briefly, but I really hadn't >thought it out much. > >Actually, would it be possible to simply throw a request URI into a presence notification >for any sort of a transfer? Huh? The request URI of the NOTIFY is determine through standard Route header processing. > >i.e. to get around problems with message length and firewall/NAT issues, is it important >that we actually include the cpim-xpidf+xml document in the NOTIFY, or could we simply add >that you might get an application/cpim-xpidf-url document, that the client can go grab >using HTTP. Solves all of the problems in one tidy package. I see no need to define a URL format for each document type. You could either: 1. subscribe to Event: presence.alert, and the Accept header has type application/uri-list. The NOTIFY would contain URLs to get at the presence doc, presumably with HTTP URLs. This is the proposal below. 2. subscribe to Event: presence, and the Accept header has type application/uri-list, which becomes a valid type for NOTIFY. The NOTIFY comes with the URL list. This is similar to what I have suggested below, but uses the same package. >That way clients initiate the transfer of the presence document, and can choose TCP if >they wish (likely), or if they suspect they're behind a firewall/NAT. When they make the >subscription, they could include an accept with the application/cpim-xpidf-url content >type which would simply be an HTTP or HTTPS url to where to grab the presence document. > >Another added advantage would be that you could use a "cheap" transport like UDP to send >the notification, and then let the client initiate an "expensive" transport like TCP or >TLS, on demand, to go get the document when it needs to. That would allow established >secure HTTP transfers to take place when retrieving the data that we're trying to pull. Right. This is exactly what I have proposed below. -Jonathan R. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, November 26, 2001 2:03 PM To: 'Michael Hammer'; Jonathan Rosenberg Cc: 'adam.roach@ericsson.com'; Stucker, Brian [NGB:B635:EXCH]; simple; Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy [NGB:B692:EXCH] Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, November 21, 2001 10:11 AM > To: Jonathan Rosenberg > Cc: 'adam.roach@ericsson.com'; 'Brian Stucker'; simple; Alex Nava; > Patrick Sollee; Sanjoy Sen > Subject: RE: [Simple] RE: Question regarding NOTIFY messages > using UDP. > > > Jonathan, > > While not favoring any fragmentation mechanism for SIP, does > this preclude > any implementation (higher level application using SIP) from > choosing to > send the body of the Notifies as incremental parts? It would > seem that the > SIP-level mechanisms would be unaware of the full nature of > the body which > it carries and should place no restrictions on that body. > > That is, it provides no mechanism nor precludes use of such a > mechanism. The spec assumes full-state, and talks about using CSeq to determine the most recent document, which wouldn't make sense for partial documents as you have described. An extension could in principle override this, and you could define a document format that supports partial information. However, I still assert that: 1. this is a problem in theory only 2. if the docs do become large, delta encoding is better Honestly, the problem is more for other event packages that may convey larger amounts of state. Brian later writes: > Ok, here's a thought... > If we're in a position where we think we're going to need to use TCP (or some other > connection-oriented protocol) to notify the watcher (in this example, a presence > subscriber), but it's difficult to keep up a bunch of TCP connections, we use the > following general mechanism. > > 1. We send the watcher a NOTIFY that says in effect "you need to fetch the current state > of this resource" (in this case, probably using UDP). > > 2. The watcher responds to the NOTIFY with a 200 OK however it chooses. > > 3. The watcher sends a SUBSCRIBE in to fetch the current state of the resource (in this > case a presentity) using the transport of it's choosing. If it knows it's behind a > firewall, or a NAT, then it can pick TCP, for instance. Actually, we've been toying with the idea of not even using SUBSCRIBE for this. An HTTP request is just fine for synchronously fetching a document; thats what its designed to do. One could think of this as another sub-package, say "alert". If you subscribe to foo.alert, you get a NOTIFY when foo changes, but the NOTIFY contains a body type that is always short - providing a URL for actually retrieving the thing that has changed. In fact, the default could be as simple as application/uri-list. So: SUBSCRIBE sip:user@domain.com SIP/2.0 Event: presence.alert Accept: application/uri-list then the NOTIFY: NOTIFY sip:subscriber@school.edu SIP/2.0 Event: presence.alert Content-Type: application/uri-list http://school.edu/user/current-pres-doc.pl One might even have multipel URI there of several schemes, supporting a variety of pulls. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 4 10:58:25 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28890 for ; Tue, 4 Dec 2001 10:58:23 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4FtE4I007894; Tue, 4 Dec 2001 10:55:15 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05936; Tue, 4 Dec 2001 10:57:04 -0500 (EST) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05925 for ; Tue, 4 Dec 2001 10:56:41 -0500 (EST) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA04604 for ; Tue, 4 Dec 2001 09:56:13 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 4 Dec 2001 09:49:01 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 09:54:27 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E010C49FB@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Jonathan Rosenberg , Jonathan Rosenberg , "'Michael Hammer'" Cc: "'adam.roach@ericsson.com'" , simple , "Alex Nava" , "Patrick Sollee" , "Sanjoy Sen" Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17CDB.F2B2A300" X-Orig: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 4 Dec 2001 09:54:25 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17CDB.F2B2A300 Content-Type: text/plain; charset="iso-8859-1" Great. So, we'll have the ability to specify application/url-list in the SUBSCRIBE for presence events in the -05 draft? Regards, Brian -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, December 04, 2001 12:54 AM To: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'Michael Hammer' Cc: 'adam.roach@ericsson.com'; simple; Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy [NGB:B692:EXCH] Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. > >Good idea (HTTP url)... Thanks. >The thought had occurred to me briefly, but I really hadn't >thought it out much. > >Actually, would it be possible to simply throw a request URI into a presence notification >for any sort of a transfer? Huh? The request URI of the NOTIFY is determine through standard Route header processing. > >i.e. to get around problems with message length and firewall/NAT issues, is it important >that we actually include the cpim-xpidf+xml document in the NOTIFY, or could we simply add >that you might get an application/cpim-xpidf-url document, that the client can go grab >using HTTP. Solves all of the problems in one tidy package. I see no need to define a URL format for each document type. You could either: 1. subscribe to Event: presence.alert, and the Accept header has type application/uri-list. The NOTIFY would contain URLs to get at the presence doc, presumably with HTTP URLs. This is the proposal below. 2. subscribe to Event: presence, and the Accept header has type application/uri-list, which becomes a valid type for NOTIFY. The NOTIFY comes with the URL list. This is similar to what I have suggested below, but uses the same package. >That way clients initiate the transfer of the presence document, and can choose TCP if >they wish (likely), or if they suspect they're behind a firewall/NAT. When they make the >subscription, they could include an accept with the application/cpim-xpidf-url content >type which would simply be an HTTP or HTTPS url to where to grab the presence document. > >Another added advantage would be that you could use a "cheap" transport like UDP to send >the notification, and then let the client initiate an "expensive" transport like TCP or >TLS, on demand, to go get the document when it needs to. That would allow established >secure HTTP transfers to take place when retrieving the data that we're trying to pull. Right. This is exactly what I have proposed below. -Jonathan R. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, November 26, 2001 2:03 PM To: 'Michael Hammer'; Jonathan Rosenberg Cc: 'adam.roach@ericsson.com'; Stucker, Brian [NGB:B635:EXCH]; simple; Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy [NGB:B692:EXCH] Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, November 21, 2001 10:11 AM > To: Jonathan Rosenberg > Cc: 'adam.roach@ericsson.com'; 'Brian Stucker'; simple; Alex Nava; > Patrick Sollee; Sanjoy Sen > Subject: RE: [Simple] RE: Question regarding NOTIFY messages > using UDP. > > > Jonathan, > > While not favoring any fragmentation mechanism for SIP, does > this preclude > any implementation (higher level application using SIP) from > choosing to > send the body of the Notifies as incremental parts? It would > seem that the > SIP-level mechanisms would be unaware of the full nature of > the body which > it carries and should place no restrictions on that body. > > That is, it provides no mechanism nor precludes use of such a > mechanism. The spec assumes full-state, and talks about using CSeq to determine the most recent document, which wouldn't make sense for partial documents as you have described. An extension could in principle override this, and you could define a document format that supports partial information. However, I still assert that: 1. this is a problem in theory only 2. if the docs do become large, delta encoding is better Honestly, the problem is more for other event packages that may convey larger amounts of state. Brian later writes: > Ok, here's a thought... > If we're in a position where we think we're going to need to use TCP (or some other > connection-oriented protocol) to notify the watcher (in this example, a presence > subscriber), but it's difficult to keep up a bunch of TCP connections, we use the > following general mechanism. > > 1. We send the watcher a NOTIFY that says in effect "you need to fetch the current state > of this resource" (in this case, probably using UDP). > > 2. The watcher responds to the NOTIFY with a 200 OK however it chooses. > > 3. The watcher sends a SUBSCRIBE in to fetch the current state of the resource (in this > case a presentity) using the transport of it's choosing. If it knows it's behind a > firewall, or a NAT, then it can pick TCP, for instance. Actually, we've been toying with the idea of not even using SUBSCRIBE for this. An HTTP request is just fine for synchronously fetching a document; thats what its designed to do. One could think of this as another sub-package, say "alert". If you subscribe to foo.alert, you get a NOTIFY when foo changes, but the NOTIFY contains a body type that is always short - providing a URL for actually retrieving the thing that has changed. In fact, the default could be as simple as application/uri-list. So: SUBSCRIBE sip:user@domain.com SIP/2.0 Event: presence.alert Accept: application/uri-list then the NOTIFY: NOTIFY sip:subscriber@school.edu SIP/2.0 Event: presence.alert Content-Type: application/uri-list http://school.edu/user/current-pres-doc.pl One might even have multipel URI there of several schemes, supporting a variety of pulls. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com ------_=_NextPart_001_01C17CDB.F2B2A300 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] RE: Question regarding NOTIFY messages using UDP.

Great.

So, we'll have the ability to specify application/url-list in the SUBSCRIBE for presence events in the -05 draft?

Regards,

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, December 04, 2001 12:54 AM
To: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'Michael Hammer'
Cc: 'adam.roach@ericsson.com'; simple; Nava, Alex [NGC:B634:EXCH];
Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy [NGB:B692:EXCH]
Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP.

>
>Good idea (HTTP url)...

Thanks.

>The thought had occurred to me briefly, but I really hadn't
>thought it out much.
>
>Actually, would it be possible to simply throw a request URI into a
presence notification
>for any sort of a transfer?

Huh? The request URI of the NOTIFY is determine through standard Route
header processing.


>
>i.e. to get around problems with message length and firewall/NAT issues, is
it important
>that we actually include the cpim-xpidf+xml document in the NOTIFY, or
could we simply add
>that you might get an application/cpim-xpidf-url document, that the client
can go grab
>using HTTP. Solves all of the problems in one tidy package.

I see no need to define a URL format for each document type. You could
either:

1. subscribe to Event: presence.alert, and the Accept header has type
application/uri-list. The NOTIFY would contain URLs to get at the presence
doc, presumably with HTTP URLs. This is the proposal below.

2. subscribe to Event: presence, and the Accept header has type
application/uri-list, which becomes a valid type for NOTIFY. The NOTIFY
comes with the URL list. This is similar to what I have suggested below, but
uses the same package.




>That way clients initiate the transfer of the presence document, and can
choose TCP if
>they wish (likely), or if they suspect they're behind a firewall/NAT. When
they make the
>subscription, they could include an accept with the
application/cpim-xpidf-url content
>type which would simply be an HTTP or HTTPS url to where to grab the
presence document.
>
>Another added advantage would be that you could use a "cheap" transport
like UDP to send
>the notification, and then let the client initiate an "expensive" transport
like TCP or
>TLS, on demand, to go get the document when it needs to. That would allow
established
>secure HTTP transfers to take place when retrieving the data that we're
trying to pull.

Right. This is exactly what I have proposed below.

-Jonathan R.
-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Monday, November 26, 2001 2:03 PM
To: 'Michael Hammer'; Jonathan Rosenberg
Cc: 'adam.roach@ericsson.com'; Stucker, Brian [NGB:B635:EXCH]; simple;
Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy
[NGB:B692:EXCH]
Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP.




 
> -----Original Message-----
> From: Michael Hammer [mailto:mhammer@cisco.com]
> Sent: Wednesday, November 21, 2001 10:11 AM
> To: Jonathan Rosenberg
> Cc: 'adam.roach@ericsson.com'; 'Brian Stucker'; simple; Alex Nava;
> Patrick Sollee; Sanjoy Sen
> Subject: RE: [Simple] RE: Question regarding NOTIFY messages
> using UDP.
>
>
> Jonathan,
>
> While not favoring any fragmentation mechanism for SIP, does
> this preclude
> any implementation (higher level application using SIP) from
> choosing to
> send the body of the Notifies as incremental parts?  It would
> seem that the
> SIP-level mechanisms would be unaware of the full nature of
> the body which
> it carries and should place no restrictions on that body.
>
> That is, it provides no mechanism nor precludes use of such a
> mechanism.
The spec assumes full-state, and talks about using CSeq to determine the
most recent document, which wouldn't make sense for partial documents as you

have described.
An extension could in principle override this, and you could define a
document format that supports partial information.
However, I still assert that:
1. this is a problem in theory only
2. if the docs do become large, delta encoding is better
Honestly, the problem is more for other event packages that may convey
larger amounts of state.


Brian later writes:
> Ok, here's a thought...
> If we're in a position where we think we're going to need to use TCP (or
some other
> connection-oriented protocol) to notify the watcher (in this example, a
presence
> subscriber), but it's difficult to keep up a bunch of TCP connections, we
use the
> following general mechanism.
>
> 1. We send the watcher a NOTIFY that says in effect "you need to fetch the

current state
> of this resource" (in this case, probably using UDP).
>
> 2. The watcher responds to the NOTIFY with a 200 OK however it chooses.
>
> 3. The watcher sends a SUBSCRIBE in to fetch the current state of the
resource (in this
> case a presentity) using the transport of it's choosing. If it knows it's
behind a
> firewall, or a NAT, then it can pick TCP, for instance.
Actually, we've been toying with the idea of not even using SUBSCRIBE for
this. An HTTP request is just fine for synchronously fetching a document;
thats what its designed to do.
One could think of this as another sub-package, say "alert". If you
subscribe to foo.alert, you get a NOTIFY when foo changes, but the NOTIFY
contains a body type that is always short - providing a URL for actually
retrieving the thing that has changed. In fact, the default could be as
simple as application/uri-list. So:
SUBSCRIBE sip:user@domain.com SIP/2.0
Event: presence.alert
Accept: application/uri-list
then the NOTIFY:
NOTIFY sip:subscriber@school.edu SIP/2.0
Event: presence.alert
Content-Type: application/uri-list
http://school.edu/user/current-pres-doc.pl


One might even have multipel URI there of several schemes, supporting a
variety of pulls.


-Jonathan R.


---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

------_=_NextPart_001_01C17CDB.F2B2A300-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 4 11:07:07 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29721 for ; Tue, 4 Dec 2001 11:07:06 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4G494I008024; Tue, 4 Dec 2001 11:04:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06017; Tue, 4 Dec 2001 11:06:03 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06006 for ; Tue, 4 Dec 2001 11:05:50 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4G3j4I008016; Tue, 4 Dec 2001 11:03:45 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 11:05:14 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brian Stucker'" , Jonathan Rosenberg , Jonathan Rosenberg , "'Michael Hammer'" Cc: "'adam.roach@ericsson.com'" , simple , Alex Nava , Patrick Sollee , Sanjoy Sen Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 4 Dec 2001 11:05:12 -0500 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Tuesday, December 04, 2001 10:54 AM To: Jonathan Rosenberg; Jonathan Rosenberg; 'Michael Hammer' Cc: 'adam.roach@ericsson.com'; simple; Alex Nava; Patrick Sollee; Sanjoy Sen Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. >Great. >So, we'll have the ability to specify application/url-list in the SUBSCRIBE for presence >events in the -05 draft? Well, we need to decide whether thats really a separate package, or just a different data format for an existing package. We also need a few more opinions on this subject, since the list has been faily quiet of late. -Jonathan R. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, December 04, 2001 12:54 AM To: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'Michael Hammer' Cc: 'adam.roach@ericsson.com'; simple; Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy [NGB:B692:EXCH] Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. > >Good idea (HTTP url)... Thanks. >The thought had occurred to me briefly, but I really hadn't >thought it out much. > >Actually, would it be possible to simply throw a request URI into a presence notification >for any sort of a transfer? Huh? The request URI of the NOTIFY is determine through standard Route header processing. > >i.e. to get around problems with message length and firewall/NAT issues, is it important >that we actually include the cpim-xpidf+xml document in the NOTIFY, or could we simply add >that you might get an application/cpim-xpidf-url document, that the client can go grab >using HTTP. Solves all of the problems in one tidy package. I see no need to define a URL format for each document type. You could either: 1. subscribe to Event: presence.alert, and the Accept header has type application/uri-list. The NOTIFY would contain URLs to get at the presence doc, presumably with HTTP URLs. This is the proposal below. 2. subscribe to Event: presence, and the Accept header has type application/uri-list, which becomes a valid type for NOTIFY. The NOTIFY comes with the URL list. This is similar to what I have suggested below, but uses the same package. >That way clients initiate the transfer of the presence document, and can choose TCP if >they wish (likely), or if they suspect they're behind a firewall/NAT. When they make the >subscription, they could include an accept with the application/cpim-xpidf-url content >type which would simply be an HTTP or HTTPS url to where to grab the presence document. > >Another added advantage would be that you could use a "cheap" transport like UDP to send >the notification, and then let the client initiate an "expensive" transport like TCP or >TLS, on demand, to go get the document when it needs to. That would allow established >secure HTTP transfers to take place when retrieving the data that we're trying to pull. Right. This is exactly what I have proposed below. -Jonathan R. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, November 26, 2001 2:03 PM To: 'Michael Hammer'; Jonathan Rosenberg Cc: 'adam.roach@ericsson.com'; Stucker, Brian [NGB:B635:EXCH]; simple; Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy [NGB:B692:EXCH] Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, November 21, 2001 10:11 AM > To: Jonathan Rosenberg > Cc: 'adam.roach@ericsson.com'; 'Brian Stucker'; simple; Alex Nava; > Patrick Sollee; Sanjoy Sen > Subject: RE: [Simple] RE: Question regarding NOTIFY messages > using UDP. > > > Jonathan, > > While not favoring any fragmentation mechanism for SIP, does > this preclude > any implementation (higher level application using SIP) from > choosing to > send the body of the Notifies as incremental parts? It would > seem that the > SIP-level mechanisms would be unaware of the full nature of > the body which > it carries and should place no restrictions on that body. > > That is, it provides no mechanism nor precludes use of such a > mechanism. The spec assumes full-state, and talks about using CSeq to determine the most recent document, which wouldn't make sense for partial documents as you have described. An extension could in principle override this, and you could define a document format that supports partial information. However, I still assert that: 1. this is a problem in theory only 2. if the docs do become large, delta encoding is better Honestly, the problem is more for other event packages that may convey larger amounts of state. Brian later writes: > Ok, here's a thought... > If we're in a position where we think we're going to need to use TCP (or some other > connection-oriented protocol) to notify the watcher (in this example, a presence > subscriber), but it's difficult to keep up a bunch of TCP connections, we use the > following general mechanism. > > 1. We send the watcher a NOTIFY that says in effect "you need to fetch the current state > of this resource" (in this case, probably using UDP). > > 2. The watcher responds to the NOTIFY with a 200 OK however it chooses. > > 3. The watcher sends a SUBSCRIBE in to fetch the current state of the resource (in this > case a presentity) using the transport of it's choosing. If it knows it's behind a > firewall, or a NAT, then it can pick TCP, for instance. Actually, we've been toying with the idea of not even using SUBSCRIBE for this. An HTTP request is just fine for synchronously fetching a document; thats what its designed to do. One could think of this as another sub-package, say "alert". If you subscribe to foo.alert, you get a NOTIFY when foo changes, but the NOTIFY contains a body type that is always short - providing a URL for actually retrieving the thing that has changed. In fact, the default could be as simple as application/uri-list. So: SUBSCRIBE sip:user@domain.com SIP/2.0 Event: presence.alert Accept: application/uri-list then the NOTIFY: NOTIFY sip:subscriber@school.edu SIP/2.0 Event: presence.alert Content-Type: application/uri-list http://school.edu/user/current-pres-doc.pl One might even have multipel URI there of several schemes, supporting a variety of pulls. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 4 11:11:05 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29900 for ; Tue, 4 Dec 2001 11:11:04 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4G8B4I008103; Tue, 4 Dec 2001 11:08:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06059; Tue, 4 Dec 2001 11:10:03 -0500 (EST) Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA06046 for ; Tue, 4 Dec 2001 11:09:22 -0500 (EST) Message-ID: <20011204160857.76457.qmail@web11603.mail.yahoo.com> Received: from [208.237.135.21] by web11603.mail.yahoo.com via HTTP; Tue, 04 Dec 2001 08:08:57 PST From: Sean Olson Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. To: Jonathan Rosenberg , "'Brian Stucker'" , "'Michael Hammer'" Cc: "'adam.roach@ericsson.com'" , simple , Alex Nava , Patrick Sollee , Sanjoy Sen In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 4 Dec 2001 08:08:57 -0800 (PST) This is a great idea. I don't see the need to make this a different package, however. There are good mechanisms in SIP to negotiate payloads. This should be sufficient for this purpose. /sean --- Jonathan Rosenberg wrote: > > > > -----Original Message----- > From: Brian Stucker > [mailto:bstucker@nortelnetworks.com] > Sent: Tuesday, December 04, 2001 10:54 AM > To: Jonathan Rosenberg; Jonathan Rosenberg; 'Michael > Hammer' > Cc: 'adam.roach@ericsson.com'; simple; Alex Nava; > Patrick Sollee; Sanjoy Sen > Subject: RE: [Simple] RE: Question regarding NOTIFY > messages using UDP. > > > >Great. > >So, we'll have the ability to specify > application/url-list in the SUBSCRIBE > for presence > >events in the -05 draft? > > Well, we need to decide whether thats really a > separate package, or just a > different data format for an existing package. > > We also need a few more opinions on this subject, > since the list has been > faily quiet of late. > > -Jonathan R. > > -----Original Message----- > From: Jonathan Rosenberg > [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, December 04, 2001 12:54 AM > To: Stucker, Brian [NGB:B635:EXCH]; Jonathan > Rosenberg; 'Michael Hammer' > Cc: 'adam.roach@ericsson.com'; simple; Nava, Alex > [NGC:B634:EXCH]; > Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy > [NGB:B692:EXCH] > Subject: RE: [Simple] RE: Question regarding NOTIFY > messages using UDP. > > > >Good idea (HTTP url)... > Thanks. > >The thought had occurred to me briefly, but I > really hadn't > >thought it out much. > > > >Actually, would it be possible to simply throw a > request URI into a > presence notification > >for any sort of a transfer? > Huh? The request URI of the NOTIFY is determine > through standard Route > header processing. > > > > > >i.e. to get around problems with message length and > firewall/NAT issues, is > > it important > >that we actually include the cpim-xpidf+xml > document in the NOTIFY, or > could we simply add > >that you might get an application/cpim-xpidf-url > document, that the client > can go grab > >using HTTP. Solves all of the problems in one tidy > package. > I see no need to define a URL format for each > document type. You could > either: > 1. subscribe to Event: presence.alert, and the > Accept header has type > application/uri-list. The NOTIFY would contain URLs > to get at the presence > doc, presumably with HTTP URLs. This is the proposal > below. > 2. subscribe to Event: presence, and the Accept > header has type > application/uri-list, which becomes a valid type for > NOTIFY. The NOTIFY > comes with the URL list. This is similar to what I > have suggested below, but > > uses the same package. > > > > > >That way clients initiate the transfer of the > presence document, and can > choose TCP if > >they wish (likely), or if they suspect they're > behind a firewall/NAT. When > they make the > >subscription, they could include an accept with the > > application/cpim-xpidf-url content > >type which would simply be an HTTP or HTTPS url to > where to grab the > presence document. > > > >Another added advantage would be that you could use > a "cheap" transport > like UDP to send > >the notification, and then let the client initiate > an "expensive" transport > > like TCP or > >TLS, on demand, to go get the document when it > needs to. That would allow > established > >secure HTTP transfers to take place when retrieving > the data that we're > trying to pull. > Right. This is exactly what I have proposed below. > -Jonathan R. > -----Original Message----- > From: Jonathan Rosenberg > [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, November 26, 2001 2:03 PM > To: 'Michael Hammer'; Jonathan Rosenberg > Cc: 'adam.roach@ericsson.com'; Stucker, Brian > [NGB:B635:EXCH]; simple; > Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick > [NGC:B680:EXCH]; Sen, Sanjoy > [NGB:B692:EXCH] > Subject: RE: [Simple] RE: Question regarding NOTIFY > messages using UDP. > > > > > > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Wednesday, November 21, 2001 10:11 AM > > To: Jonathan Rosenberg > > Cc: 'adam.roach@ericsson.com'; 'Brian Stucker'; > simple; Alex Nava; > > Patrick Sollee; Sanjoy Sen > > Subject: RE: [Simple] RE: Question regarding > NOTIFY messages > > using UDP. > > > > > > Jonathan, > > > > While not favoring any fragmentation mechanism for > SIP, does > > this preclude > > any implementation (higher level application using > SIP) from > > choosing to > > send the body of the Notifies as incremental > parts? It would > > seem that the > > SIP-level mechanisms would be unaware of the full > nature of > > the body which > > it carries and should place no restrictions on > that body. > > > > That is, it provides no mechanism nor precludes > use of such a > > mechanism. > The spec assumes full-state, and talks about using > CSeq to determine the > most recent document, which wouldn't make sense for > partial documents as you > > have described. > An extension could in principle override this, and > you could define a > document format that supports partial information. > However, I still assert that: > 1. this is a problem in theory only > 2. if the docs do become large, delta encoding is > better > Honestly, the problem is more for other event > packages that may convey > larger amounts of state. > > > Brian later writes: > > Ok, here's a thought... > > If we're in a position where we think we're going > to need to use TCP (or > some other > > connection-oriented protocol) to notify the > watcher (in this example, a > presence > > subscriber), but it's difficult to keep up a bunch > of TCP connections, we > use the > > following general mechanism. > > > === message truncated === ===== -- Sean Olson This is from me. Assume nothing else. __________________________________________________ Do You Yahoo!? Buy the perfect holiday gifts at Yahoo! Shopping. http://shopping.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 4 11:34:49 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00732 for ; Tue, 4 Dec 2001 11:34:49 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4GVC4I008346; Tue, 4 Dec 2001 11:31:12 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06157; Tue, 4 Dec 2001 11:33:02 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06144 for ; Tue, 4 Dec 2001 11:32:28 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fB4GVwT28231; Tue, 4 Dec 2001 17:31:58 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id RAA24562; Tue, 4 Dec 2001 17:31:56 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xma024099; Tue, 4 Dec 01 17:31:38 +0100 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 17:31:33 +0100 Message-ID: From: Brazier Lachlan To: "'Jonathan Rosenberg'" , "'Brian Stucker'" , "'Michael Hammer'" Cc: "'adam.roach@ericsson.com'" , simple , Alex Nava , Patrick Sollee , Sanjoy Sen Subject: AW: [Simple] RE: Question regarding NOTIFY messages using UDP. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 4 Dec 2001 17:31:31 +0100 Hello, > > >Great. > >So, we'll have the ability to specify application/url-list > in the SUBSCRIBE > for presence > >events in the -05 draft? > > Well, we need to decide whether thats really a separate > package, or just a > different data format for an existing package. > > We also need a few more opinions on this subject, since the > list has been > faily quiet of late. > does this mean that in the NOTIFY there is no cpim-xpidf+xml document but a URI or a list of URI's where the client can get the cpim-xpidf+xml document with HTTP or whatever is specified? I this correct? If yes, sounds beautiful. Haven't thought about the packages yet. Lachlan _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 4 11:35:05 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00744 for ; Tue, 4 Dec 2001 11:35:05 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4GW94I008404; Tue, 4 Dec 2001 11:32:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06178; Tue, 4 Dec 2001 11:34:03 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06153 for ; Tue, 4 Dec 2001 11:33:02 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4GV64I008340; Tue, 4 Dec 2001 11:31:06 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 11:32:35 -0500 Message-ID: From: Jonathan Rosenberg To: "'Paul Kyzivat'" , adam.roach@ericsson.com Cc: Jonathan Rosenberg , "'Brian Stucker'" , simple Subject: RE: [Simple] 200 vs. 202 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 4 Dec 2001 11:32:27 -0500 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, November 27, 2001 8:40 AM > To: adam.roach@ericsson.com > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; simple > Subject: Re: [Simple] 200 vs. 202 > > > OK. Thanks for the tutorial - I think I get it now. > > But, all the complexity and loose ends suggests to me that there is > something fundamentally wrong with the mechanism here. Well, the problem is that we are trying to add forking capabilities into a method thats not ideally suited for it. Given the frequency that I realistically expect to see forking SUBSCRIBE, I am not too worried. > As you > say, this > is really an events issue, not a SIMPLE issue. Do we have consensus though? I'd like to declare this issue resolved. Adam's proposal was to accept the first NOTIFY, and ignore the 2xx. I'd like to suggest a mild variant to that that I think is even simpler. My proposal is to accept whatever comes first. If you get a 2xx to SUBSCRIBE first, that establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes first, you accept that. Any other NOTIFY are 481'd. The 2xx to SUBSCRIBE may or may not be for the dialog that was accepted; it doesn't really matter. Agreement? -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > > Paul > > adam.roach@ericsson.com wrote: > > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > > Sorry if I was pointing out the obvious. > > > > > > But if you have to save state from the subscribe in order to > > > decide what > > > notify to accept, and if, once you accept a notify, you > are going to > > > establish a long lasting dialog and even refresh it > periodically by > > > sending new subscribe requests, do you save anything by not > > > establishing > > > the dialog as part of the initial subscription? > > > > The issue being discussed is that the NOTIFY can arrive > > before the response to the SUBSCRIBE. In fact, if the > > SUBSCRIBE is forked, this is the most common scenario. > > > > One of my early (strawman) proposals was to wait until the > > SUBSCRIBE completed before responding to the NOTIFY. This > > is really rather complex to implement correctly. > > > > An improvement on this scheme was proposed by Jonathan: > > accept the NOTIFYs that arrive while the SUBSCRIBE is > > pending, and then un-subscribe to any that do not match > > the SUBSCRIBE response. > > > > After some analysis, I determined that this could > > probably be simplified (from an implementation point of view) > > further by simply accepting the first NOTIFY that could > > reasonably belong to the pending SUBSCRIBE, and reject the > > rest with 481s. The logic behind this simplification is > > that the SUBSCRIBE response isn't special; it just represents > > the response that happened to race to the forking proxy > > the fastest. It's not "better" than any of the other > > potential dialogs in any way. > > > > Sorry for continuing this discussion on the SIMPLE list; > > as Jonathan has pointed out a couple of times, this really > > has turned more into a sip-events issue than a SIMPLE issue. > > > > /a > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 4 11:41:58 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00918 for ; Tue, 4 Dec 2001 11:41:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4Gd94I008514; Tue, 4 Dec 2001 11:39:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06236; Tue, 4 Dec 2001 11:41:02 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06224 for ; Tue, 4 Dec 2001 11:40:25 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fB4GdeV22207; Tue, 4 Dec 2001 11:39:41 -0500 (EST) Message-ID: <3C0CFC4C.F7D6E86B@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Brazier Lachlan CC: "'Jonathan Rosenberg'" , "'Brian Stucker'" , "'Michael Hammer'" , "'adam.roach@ericsson.com'" , simple , Alex Nava , Patrick Sollee , Sanjoy Sen Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using UDP. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 04 Dec 2001 11:39:40 -0500 Content-Transfer-Encoding: 7bit Brazier Lachlan wrote: > > does this mean that in the NOTIFY there is no cpim-xpidf+xml document but a > URI or a list of URI's where the client can get the cpim-xpidf+xml document > with HTTP or whatever is specified? > > I this correct? > If yes, sounds beautiful. Haven't thought about the packages yet. As long as you consider the practical problems. For example, you now need to have the ability to "reach back" to the web server of the notifier. You need to coordinate authentication. If you used hop-by-hop transitive trust, that won't work any more and you'll have to resort to a shared secret, either via TLS from the notified party or standard HTTP Digest, making sure that the passwords are properly aligned. Also, how long is the URL valid? Forever? Until the subscription expires? I'm not against coupling protocols, but one shouldn't ignore the practical complications that arise. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 4 11:42:59 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00962 for ; Tue, 4 Dec 2001 11:42:59 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4Ge94I008579; Tue, 4 Dec 2001 11:40:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06270; Tue, 4 Dec 2001 11:42:03 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06249 for ; Tue, 4 Dec 2001 11:41:24 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4GdS4I008563; Tue, 4 Dec 2001 11:39:28 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 11:40:57 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brazier Lachlan'" , Jonathan Rosenberg , "'Brian Stucker'" , "'Michael Hammer'" Cc: "'adam.roach@ericsson.com'" , simple , Alex Nava , Patrick Sollee , Sanjoy Sen Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 4 Dec 2001 11:40:57 -0500 > -----Original Message----- > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > Sent: Tuesday, December 04, 2001 11:32 AM > To: 'Jonathan Rosenberg'; 'Brian Stucker'; 'Michael Hammer' > Cc: 'adam.roach@ericsson.com'; simple; Alex Nava; Patrick > Sollee; Sanjoy > Sen > Subject: AW: [Simple] RE: Question regarding NOTIFY messages > using UDP. > > > Hello, > > > > > >Great. > > >So, we'll have the ability to specify application/url-list > > in the SUBSCRIBE > > for presence > > >events in the -05 draft? > > > > Well, we need to decide whether thats really a separate > > package, or just a > > different data format for an existing package. > > > > We also need a few more opinions on this subject, since the > > list has been > > faily quiet of late. > > > > does this mean that in the NOTIFY there is no cpim-xpidf+xml > document but a > URI or a list of URI's where the client can get the > cpim-xpidf+xml document > with HTTP or whatever is specified? > > I this correct? Yes. > If yes, sounds beautiful. Haven't thought about the packages yet. Let me state the proposal for those who haven't been following the thread. The current proposal on the table is to allow the SUBSCRIBE to have an Accept header that contains application/uri-list as a valid type for NOTIFY. So: SUBSCRIBE sip:user@domain SIP/2.0 Event: presence Accept: application/cpim-pidf+xml;q=0.5, application/uri-list;q=1.0 This would ask for notifications preferably as URLs. A NOTIFY would have: NOTIFY sip:subscriber@domain SIP/2.0 Event: presence Content-Type: application/uri-list Content-Length: 23 http://www.domain.com/user/pdoc.xml And then you would use HTTP to fetch the document. This way, you could have arbitrarily large documents that would not need to be transferred with SIP. We would probably need to define a baseline url scheme (presumably http) to guarantee interop. Certainly, other URLs, even LDAP say, could be provided. This is not presence specific, to be honest, and is more useful for event types with large data formats. I don't expect presence docs to be that large in general. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 4 11:47:58 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01057 for ; Tue, 4 Dec 2001 11:47:58 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4GjA4I008667; Tue, 4 Dec 2001 11:45:10 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06327; Tue, 4 Dec 2001 11:47:03 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06316 for ; Tue, 4 Dec 2001 11:46:17 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4Ghk4I008653; Tue, 4 Dec 2001 11:43:46 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 11:45:15 -0500 Message-ID: From: Jonathan Rosenberg To: "'Henning G. Schulzrinne'" , Brazier Lachlan Cc: Jonathan Rosenberg , "'Brian Stucker'" , "'Michael Hammer'" , "'adam.roach@ericsson.com'" , simple , Alex Nava , Patrick Sollee , Sanjoy Sen Subject: RE: AW: [Simple] RE: Question regarding NOTIFY messages using UDP . MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 4 Dec 2001 11:45:11 -0500 > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, December 04, 2001 11:40 AM > To: Brazier Lachlan > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; 'Michael Hammer'; > 'adam.roach@ericsson.com'; simple; Alex Nava; Patrick Sollee; > Sanjoy Sen > Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using > UDP. > > > Brazier Lachlan wrote: > > > > > does this mean that in the NOTIFY there is no > cpim-xpidf+xml document but a > > URI or a list of URI's where the client can get the > cpim-xpidf+xml document > > with HTTP or whatever is specified? > > > > I this correct? > > If yes, sounds beautiful. Haven't thought about the packages yet. > > As long as you consider the practical problems. For example, you now > need to have the ability to "reach back" to the web server of the > notifier. You need to coordinate authentication. If you used > hop-by-hop > transitive trust, that won't work any more and you'll have to > resort to > a shared secret, either via TLS from the notified party or > standard HTTP > Digest, making sure that the passwords are properly aligned. Good point. If you've been using transitive trust, though, the URL in the NOTIFY may have been encrypted at each hop, so merely using that URL (so long as it has sufficient randomness encoded in it) provides some amount of authentication. Not perfect, for sure. > Also, how > long is the URL valid? Forever? Until the subscription expires? We would need to specify that. I would argue that the URL fetches the current presence doc until the subscription expires. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 4 11:56:58 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01419 for ; Tue, 4 Dec 2001 11:56:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB4Gs94I008815; Tue, 4 Dec 2001 11:54:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06408; Tue, 4 Dec 2001 11:56:03 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06396 for ; Tue, 4 Dec 2001 11:55:33 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fB4Gt7V23093; Tue, 4 Dec 2001 11:55:07 -0500 (EST) Message-ID: <3C0CFFEB.2ECE561C@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using UDP. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 04 Dec 2001 11:55:07 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, December 04, 2001 11:40 AM > > To: Brazier Lachlan > > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; 'Michael Hammer'; > > 'adam.roach@ericsson.com'; simple; Alex Nava; Patrick Sollee; > > Sanjoy Sen > > Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using > > UDP. > > > > > > Brazier Lachlan wrote: > > > > > > > > does this mean that in the NOTIFY there is no > > cpim-xpidf+xml document but a > > > URI or a list of URI's where the client can get the > > cpim-xpidf+xml document > > > with HTTP or whatever is specified? > > > > > > I this correct? > > > If yes, sounds beautiful. Haven't thought about the packages yet. > > > > As long as you consider the practical problems. For example, you now > > need to have the ability to "reach back" to the web server of the > > notifier. You need to coordinate authentication. If you used > > hop-by-hop > > transitive trust, that won't work any more and you'll have to > > resort to > > a shared secret, either via TLS from the notified party or > > standard HTTP > > Digest, making sure that the passwords are properly aligned. > > Good point. > > If you've been using transitive trust, though, the URL in the NOTIFY may > have been encrypted at each hop, so merely using that URL (so long as it has > sufficient randomness encoded in it) provides some amount of authentication. > Not perfect, for sure. It also means that the notified party has to support TLS to prevent disclosure of the presence document. In the pure SIP case, it's viable to have the "WAN" hops use TLS, while the last hop, hopefully on a more trusted network, may not. > > > Also, how > > long is the URL valid? Forever? Until the subscription expires? > > We would need to specify that. I would argue that the URL fetches the > current presence doc until the subscription expires. > Plus caching behavior. I suspect the biggest problem will be the "get back to notifier" issue. Effectively, you now have to have a public-Internet web server that the notifier can control. Since you need to not just create documents but also delete them after expiration, you need WebDAV or some proprietary cgi interface, or also implement ftp (and know the file structure of the server). (Updating the authorization table on the public-Internet web server will be even messier, since there's no published protocol for doing that.) Thus, what seems like a simple proposal ("just include the URL") becomes just a tad more complicated if you consider all the things that can go wrong. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 5 08:43:40 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20610 for ; Wed, 5 Dec 2001 08:43:40 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB5DeS4I013612; Wed, 5 Dec 2001 08:40:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10155; Wed, 5 Dec 2001 08:42:05 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10142; Wed, 5 Dec 2001 08:41:27 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id OAA13936; Wed, 5 Dec 2001 14:41:00 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB5DfIt98078; Wed, 5 Dec 2001 14:41:18 +0100 To: "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , simple , simple-admin@mailman.dynamicsoft.com MIME-Version: 1.0 Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using UDP. X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/12/2001 15:41:13, Serialize complete at 05/12/2001 15:41:13 Content-Type: multipart/alternative; boundary="=_alternative 004B28DDC2256B19_=" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 5 Dec 2001 15:41:03 +0200 This is a multipart message in MIME format. --=_alternative 004B28DDC2256B19_= Content-Type: text/plain; charset="us-ascii" I agree with Henning. It will become very difficult to deploy. Maybe the SUBSCRIBE request can contain an hint whether the subscribing UA would accept notifies with URLs. This way domains that took the trouble to deploy the web server etc. will be able to optimize it only for clients that can support fetching the URL. ------------------------ Avshalom Houri Lotus Sametime IBM Software Group Building 18/D, Science Park Kiryat Weizmann, P.O. Box 2523 Rehovot 76123 Israel Email: avshalom@il.ibm.com Office: +972-8-9409761 X123 Fax: +972-8-9409768 Mobile: +972-54-686021 "Henning G. Schulzrinne" Sent by: simple-admin@mailman.dynamicsoft.com 04/12/2001 18:55 To: Jonathan Rosenberg cc: simple Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using UDP. Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, December 04, 2001 11:40 AM > > To: Brazier Lachlan > > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; 'Michael Hammer'; > > 'adam.roach@ericsson.com'; simple; Alex Nava; Patrick Sollee; > > Sanjoy Sen > > Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using > > UDP. > > > > > > Brazier Lachlan wrote: > > > > > > > > does this mean that in the NOTIFY there is no > > cpim-xpidf+xml document but a > > > URI or a list of URI's where the client can get the > > cpim-xpidf+xml document > > > with HTTP or whatever is specified? > > > > > > I this correct? > > > If yes, sounds beautiful. Haven't thought about the packages yet. > > > > As long as you consider the practical problems. For example, you now > > need to have the ability to "reach back" to the web server of the > > notifier. You need to coordinate authentication. If you used > > hop-by-hop > > transitive trust, that won't work any more and you'll have to > > resort to > > a shared secret, either via TLS from the notified party or > > standard HTTP > > Digest, making sure that the passwords are properly aligned. > > Good point. > > If you've been using transitive trust, though, the URL in the NOTIFY may > have been encrypted at each hop, so merely using that URL (so long as it has > sufficient randomness encoded in it) provides some amount of authentication. > Not perfect, for sure. It also means that the notified party has to support TLS to prevent disclosure of the presence document. In the pure SIP case, it's viable to have the "WAN" hops use TLS, while the last hop, hopefully on a more trusted network, may not. > > > Also, how > > long is the URL valid? Forever? Until the subscription expires? > > We would need to specify that. I would argue that the URL fetches the > current presence doc until the subscription expires. > Plus caching behavior. I suspect the biggest problem will be the "get back to notifier" issue. Effectively, you now have to have a public-Internet web server that the notifier can control. Since you need to not just create documents but also delete them after expiration, you need WebDAV or some proprietary cgi interface, or also implement ftp (and know the file structure of the server). (Updating the authorization table on the public-Internet web server will be even messier, since there's no published protocol for doing that.) Thus, what seems like a simple proposal ("just include the URL") becomes just a tad more complicated if you consider all the things that can go wrong. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple --=_alternative 004B28DDC2256B19_= Content-Type: text/html; charset="us-ascii"
I agree with Henning. It will become very difficult to deploy. Maybe the SUBSCRIBE request can contain an hint whether
the subscribing UA would accept notifies with URLs. This way domains that took the trouble to deploy the web server etc.
will be able to optimize it only for clients that can support fetching the URL.

------------------------
Avshalom Houri
Lotus Sametime
IBM Software Group

Building 18/D, Science Park
Kiryat Weizmann, P.O. Box 2523
Rehovot 76123 Israel

Email: avshalom@il.ibm.com
Office: +972-8-9409761 X123
Fax: +972-8-9409768
Mobile: +972-54-686021




"Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Sent by: simple-admin@mailman.dynamicsoft.com

04/12/2001 18:55

       
        To:        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
        cc:        simple <simple@mailman.dynamicsoft.com>
        Subject:        Re: AW: [Simple] RE: Question regarding NOTIFY messages using UDP.

       


Jonathan Rosenberg wrote:
>
>
>
> > -----Original Message-----
> > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Tuesday, December 04, 2001 11:40 AM
> > To: Brazier Lachlan
> > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; 'Michael Hammer';
> > 'adam.roach@ericsson.com'; simple; Alex Nava; Patrick Sollee;
> > Sanjoy Sen
> > Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using
> > UDP.
> >
> >
> > Brazier Lachlan wrote:
> > >
> >
> > > does this mean that in the NOTIFY there is no
> > cpim-xpidf+xml document but a
> > > URI or a list of URI's where the client can get the
> > cpim-xpidf+xml document
> > > with HTTP or whatever is specified?
> > >
> > > I this correct?
> > > If yes, sounds beautiful. Haven't thought about the packages yet.
> >
> > As long as you consider the practical problems. For example, you now
> > need to have the ability to "reach back" to the web server of the
> > notifier. You need to coordinate authentication. If you used
> > hop-by-hop
> > transitive trust, that won't work any more and you'll have to
> > resort to
> > a shared secret, either via TLS from the notified party or
> > standard HTTP
> > Digest, making sure that the passwords are properly aligned.
>
> Good point.
>
> If you've been using transitive trust, though, the URL in the NOTIFY may
> have been encrypted at each hop, so merely using that URL (so long as it has
> sufficient randomness encoded in it) provides some amount of authentication.
> Not perfect, for sure.

It also means that the notified party has to support TLS to prevent
disclosure of the presence document.

In the pure SIP case, it's viable to have the "WAN" hops use TLS, while
the last hop, hopefully on a more trusted network, may not.

>
> > Also, how
> > long is the URL valid? Forever? Until the subscription expires?
>
> We would need to specify that. I would argue that the URL fetches the
> current presence doc until the subscription expires.
>

Plus caching behavior.

I suspect the biggest problem will be the "get back to notifier" issue.
Effectively, you now have to have a public-Internet web server that the
notifier can control. Since you need to not just create documents but
also delete them after expiration, you need WebDAV or some proprietary
cgi interface, or also implement ftp (and know the file structure of the
server). (Updating the authorization table on the public-Internet web
server will be even messier, since there's no published protocol for
doing that.)

Thus, what seems like a simple proposal ("just include the URL") becomes
just a tad more complicated if you consider all the things that can go
wrong.
--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple

--=_alternative 004B28DDC2256B19_=-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 5 10:27:08 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23668 for ; Wed, 5 Dec 2001 10:27:08 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB5FOA4I014357; Wed, 5 Dec 2001 10:24:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10504; Wed, 5 Dec 2001 10:26:03 -0500 (EST) Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id KAA10485 for ; Wed, 5 Dec 2001 10:25:23 -0500 (EST) Message-ID: <20011205152457.64783.qmail@web11606.mail.yahoo.com> Received: from [208.237.135.21] by web11606.mail.yahoo.com via HTTP; Wed, 05 Dec 2001 07:24:57 PST From: Sean Olson Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using UDP. To: Avshalom Houri , "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , simple , simple-admin@mailman.dynamicsoft.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 5 Dec 2001 07:24:57 -0800 (PST) We call this the "Accept" header. It is very straightforward. I don't think this is any more difficult to deploy than a pure SIP solution and it very nicely solves the problem of large messages. /sean --- Avshalom Houri wrote: > I agree with Henning. It will become very difficult > to deploy. Maybe the > SUBSCRIBE request can contain an hint whether > the subscribing UA would accept notifies with URLs. > This way domains that > took the trouble to deploy the web server etc. > will be able to optimize it only for clients that > can support fetching the > URL. > > ------------------------ > Avshalom Houri > Lotus Sametime > IBM Software Group > > Building 18/D, Science Park > Kiryat Weizmann, P.O. Box 2523 > Rehovot 76123 Israel > > Email: avshalom@il.ibm.com > Office: +972-8-9409761 X123 > Fax: +972-8-9409768 > Mobile: +972-54-686021 > > > > > > > "Henning G. Schulzrinne" > Sent by: simple-admin@mailman.dynamicsoft.com > 04/12/2001 18:55 > > > To: Jonathan Rosenberg > > cc: simple > > Subject: Re: AW: [Simple] RE: > Question regarding NOTIFY messages using UDP. > > > > Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Henning G. Schulzrinne > [mailto:hgs@cs.columbia.edu] > > > Sent: Tuesday, December 04, 2001 11:40 AM > > > To: Brazier Lachlan > > > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; > 'Michael Hammer'; > > > 'adam.roach@ericsson.com'; simple; Alex Nava; > Patrick Sollee; > > > Sanjoy Sen > > > Subject: Re: AW: [Simple] RE: Question regarding > NOTIFY messages using > > > UDP. > > > > > > > > > Brazier Lachlan wrote: > > > > > > > > > > > does this mean that in the NOTIFY there is no > > > cpim-xpidf+xml document but a > > > > URI or a list of URI's where the client can > get the > > > cpim-xpidf+xml document > > > > with HTTP or whatever is specified? > > > > > > > > I this correct? > > > > If yes, sounds beautiful. Haven't thought > about the packages yet. > > > > > > As long as you consider the practical problems. > For example, you now > > > need to have the ability to "reach back" to the > web server of the > > > notifier. You need to coordinate authentication. > If you used > > > hop-by-hop > > > transitive trust, that won't work any more and > you'll have to > > > resort to > > > a shared secret, either via TLS from the > notified party or > > > standard HTTP > > > Digest, making sure that the passwords are > properly aligned. > > > > Good point. > > > > If you've been using transitive trust, though, the > URL in the NOTIFY may > > have been encrypted at each hop, so merely using > that URL (so long as it > has > > sufficient randomness encoded in it) provides some > amount of > authentication. > > Not perfect, for sure. > > It also means that the notified party has to support > TLS to prevent > disclosure of the presence document. > > In the pure SIP case, it's viable to have the "WAN" > hops use TLS, while > the last hop, hopefully on a more trusted network, > may not. > > > > > > Also, how > > > long is the URL valid? Forever? Until the > subscription expires? > > > > We would need to specify that. I would argue that > the URL fetches the > > current presence doc until the subscription > expires. > > > > Plus caching behavior. > > I suspect the biggest problem will be the "get back > to notifier" issue. > Effectively, you now have to have a public-Internet > web server that the > notifier can control. Since you need to not just > create documents but > also delete them after expiration, you need WebDAV > or some proprietary > cgi interface, or also implement ftp (and know the > file structure of the > server). (Updating the authorization table on the > public-Internet web > server will be even messier, since there's no > published protocol for > doing that.) > > Thus, what seems like a simple proposal ("just > include the URL") becomes > just a tad more complicated if you consider all the > things that can go > wrong. > -- > Henning Schulzrinne > http://www.cs.columbia.edu/~hgs > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > ===== -- Sean Olson This is from me. Assume nothing else. __________________________________________________ Do You Yahoo!? Buy the perfect holiday gifts at Yahoo! Shopping. http://shopping.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 5 11:03:16 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25586 for ; Wed, 5 Dec 2001 11:03:16 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB5G0B4I014720; Wed, 5 Dec 2001 11:00:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10647; Wed, 5 Dec 2001 11:02:02 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10636 for ; Wed, 5 Dec 2001 11:01:16 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB5Fwo4I014708; Wed, 5 Dec 2001 10:58:50 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Dec 2001 11:00:20 -0500 Message-ID: From: Jonathan Rosenberg To: "'Henning G. Schulzrinne'" , Jonathan Rosenberg Cc: simple Subject: RE: AW: [Simple] RE: Question regarding NOTIFY messages using UDP . MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 5 Dec 2001 11:00:19 -0500 > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, December 04, 2001 11:55 AM > To: Jonathan Rosenberg > Cc: simple > Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using > UDP. > > > > Also, how > > > long is the URL valid? Forever? Until the subscription expires? > > > > We would need to specify that. I would argue that the URL > fetches the > > current presence doc until the subscription expires. > > > > Plus caching behavior. > > I suspect the biggest problem will be the "get back to > notifier" issue. > Effectively, you now have to have a public-Internet web > server that the > notifier can control. Since you need to not just create documents but > also delete them after expiration, you need WebDAV or some proprietary > cgi interface, or also implement ftp (and know the file > structure of the > server). (Updating the authorization table on the public-Internet web > server will be even messier, since there's no published protocol for > doing that.) Sure; this will require a system with some HTTP/SIP integration. That does exist already in some products. The whole thing is optional, of course; you still have to support the presence doc. But, if the server supports this capability, and the client indicates that they do as well, it can be used. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 5 14:56:14 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07124 for ; Wed, 5 Dec 2001 14:56:13 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB5JqF4I015982; Wed, 5 Dec 2001 14:52:16 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11380; Wed, 5 Dec 2001 14:54:03 -0500 (EST) Received: from localhost.localdomain (dsl081-118-200.dfw1.dsl.speakeasy.net [64.81.118.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11369 for ; Wed, 5 Dec 2001 14:53:06 -0500 (EST) Received: from rocinante (rocinante [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fB5JoxA02547; Wed, 5 Dec 2001 13:50:59 -0600 Subject: RE: [Simple] WGLC - watcherinfo From: Ben Campbell To: jdrosen@dynamicsoft.com, Robert Sparks Cc: simple@mailman.dynamicsoft.com In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F338E866@DYN-TX-EXCH-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F338E866@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Message-Id: <1007581859.1876.13.camel@rocinante> Mime-Version: 1.0 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 05 Dec 2001 13:50:58 -0600 Content-Transfer-Encoding: 7bit OK after re-reading this, I have a couple of comments on section 3.6.1 (the FSM section.) 1) [tiny nit] The state diagram shows a timeout transition between and . I don't find anything about that in the text treatment. 2) Some of the FSM description really seems more a description of the authorization FSM rather than the watcher info notification FSM. In particular, the treatment of pending vs. waiting suggests behavior on the part of the SIP-event service beyond that of watcher reporting. This section seems more descriptive than normative, so that is probably okay. 3) I know this has come up many times before, and I don't remember the resolution. Apologies if I am beating a dead horse: I have some concern about the concept of keeping state around indefinitely for pending watchers. Could this not be used as a DoS against the server? It's not nearly so bad as keeping state for denied users, but the threat may still be there. On Mon, 2001-12-03 at 14:55, Robert Sparks wrote: > There's been one (1) response to this so far - > if you have a comment get it in before 12/7. > > Please drop a note if you think the draft is > good to go as is so we don't misinterpret silence > as lack of consideration. > > RjS > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Wednesday, November 28, 2001 3:50 PM > > To: 'simple@mailman.dynamicsoft.com' > > Cc: Jon' 'Peterson (E-mail); Jonathan Rosenberg > > Subject: [Simple] WGLC - watcherinfo > > > > > > There's been very little response to the > > request for discussion on watcherinfo. > > Hopefully, that means the drafts are ready > > to go. > > > > This is the last call for comments on these drafts: > > draft-ietf-simple-winfo-package-00.txt > > draft-ietf-simple-winfo-format-00.txt > > > > This call will close on 12/21, but please have > > comments on technical deficiencies in by 12/7 > > so that we can discuss them at IETF 52. > > > > RjS > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 5 15:10:21 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08058 for ; Wed, 5 Dec 2001 15:10:16 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB5K7A4I016199; Wed, 5 Dec 2001 15:07:10 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11479; Wed, 5 Dec 2001 15:09:03 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11464 for ; Wed, 5 Dec 2001 15:08:54 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB5JvT4I016058; Wed, 5 Dec 2001 14:57:30 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Dec 2001 14:59:00 -0500 Message-ID: From: Jonathan Rosenberg To: "'Fairlie-Cuninghame, Robert'" , "'Brian Stucker'" , Jonathan Rosenberg , "'Bert Culpepper'" , adam.roach@ericsson.com Cc: "'sip@ietf.org'" , "'simple@mailman.dynamicsoft.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: [Sipping] Immediate NOTIFIES change in sip-events-01 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 5 Dec 2001 14:58:59 -0500 I'm cc'ing SIMPLE since this is a joint issue that affects both the watcherinfo work and sip-events. Also, sip-events is a sip work item, not sipping, so I am changing the list to sip. > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Wednesday, November 28, 2001 2:00 PM > To: 'Brian Stucker'; Jonathan Rosenberg; 'Bert Culpepper'; > adam.roach@ericsson.com > Cc: sipping@ietf.org > Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01 > > > This sounds like a good suggestion to me Brian. > > I would like to suggest the watherinfo reason codes are > expanded a little. > For instance, the watcherinfo assumes that the pending states > is waiting for > authorization. It could however be pending while waiting for > the subscribed > object to become active (note: I am not referring to the > subscribed Event > package here). This sort of behavior may be typical/useful > when you are > trying to subscribe to an event that has not started yet (and > yet you desire > to have the subscription in place _before_ the event begins). OK, but in this case, the subscription itself is not pending, its the state of the object that is effectively "TBD". This should be reflected in the presence document delivered in the first NOTIFY, not in the state of the subscription, IMHO. > I also think > the rejection/termination reasons could be expanded a little more. Suggestions? Brian Stucker wrote: > > I can't see much use in including the > event field since > (presumably) the watcher will know what event triggered the > NOTIFY, and if > they can't, they can use watcherinfo to get it. No, these are not events of the presentity, they are events of the subscription. These events correspond quite closely to the "reason" parameters Adam has currently specified. In fact, for the rejecttion events, here is the mapping: sip-events watcherinfo ---------- ----------- migration <-> deactivated maint <-> ? refused <-> rejected timeout <-> expired ? <-> timeout Clearly, these should be aligned, and should be present in both the SUbscription-Expires and the watcherinfo format. Its not clear to me what the semantics of maint are; should the client retry after some period? Presuming we can define it conciesely, we should add it to the watcherinfo package. So, here would be my proposal for the unified set: deactivated: subscription is terminated, but client SHOULD retry immediately with a new subscription. This handles migration plus other cases potentially. probation: subscription is terminated; but client SHOULD retry at some later time (we could include a Retry-After header in the case of presence in the Subscription-Expires header) rejected: subscription terminated due to change in authorization policy. Retrying will not help. timeout: subscription terminated because it was not refreshed. giveup: could not obtain authorization in a timely fashion, and so the pending subscription is being terminated. The client can retry and will likely get put back into pending state. THanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Dec 6 17:05:21 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14177 for ; Thu, 6 Dec 2001 17:05:21 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB6M1R4I023434; Thu, 6 Dec 2001 17:01:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16147; Thu, 6 Dec 2001 17:03:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16135 for ; Thu, 6 Dec 2001 17:02:24 -0500 (EST) Received: from cannonat.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fB6M23c13826; Thu, 6 Dec 2001 17:02:03 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannonat.cisco.com (Mirapoint) with ESMTP id AAF37188 (AUTH pkyzivat); Thu, 6 Dec 2001 17:03:21 -0500 (EST) Message-ID: <3C0FEA08.1EB987FB@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: adam.roach@ericsson.com, "'Brian Stucker'" , simple Subject: Re: [Simple] 200 vs. 202 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 06 Dec 2001 16:58:32 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, November 27, 2001 8:40 AM > > To: adam.roach@ericsson.com > > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; simple > > Subject: Re: [Simple] 200 vs. 202 > > > > > > OK. Thanks for the tutorial - I think I get it now. > > > > But, all the complexity and loose ends suggests to me that there is > > something fundamentally wrong with the mechanism here. > > Well, the problem is that we are trying to add forking capabilities into a > method thats not ideally suited for it. Can't argue with that. It's unfortunate that we have a forking mechanism that really only works for INVITE even though it is defined for other methods and (as we see here) is potentially wanted/needed for them as well. > Given the frequency that I > realistically expect to see forking SUBSCRIBE, I am not too worried. As devices are deployed that support presence, it seems like there could develop a problem with undesired forking. You want forking for invites, and perhaps don't have any simple way to prevent forking of subscribes as well. This won't be a problem if the presence function is combined with the registrar function and driven off registrations. But it will be a problem with devices that want to handle presence themselves, like the MS endpoint. All you need is people with both a desktop and laptop machine that try to maintain one identity for both. > > > As you > > say, this > > is really an events issue, not a SIMPLE issue. > > Do we have consensus though? I'd like to declare this issue resolved. Adam's > proposal was to accept the first NOTIFY, and ignore the 2xx. I'd like to > suggest a mild variant to that that I think is even simpler. My proposal is > to accept whatever comes first. If you get a 2xx to SUBSCRIBE first, that > establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes first, > you accept that. Any other NOTIFY are 481'd. The 2xx to SUBSCRIBE may or may > not be for the dialog that was accepted; it doesn't really matter. > > Agreement? I don't have a preference between those two alternatives. I won't stop progress by continuing to argue, but I don't find either solution very appealing. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 04:47:57 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17089 for ; Fri, 7 Dec 2001 04:47:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB79i84I025645; Fri, 7 Dec 2001 04:44:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18280; Fri, 7 Dec 2001 04:46:02 -0500 (EST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18269 for ; Fri, 7 Dec 2001 04:45:46 -0500 (EST) Received: from attrh2i.attrh.att.com ([135.37.94.56]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fB79jJW19070 for ; Fri, 7 Dec 2001 04:45:19 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh2i.attrh.att.com (5.5.029) id 3C06942A001DFBFA; Fri, 7 Dec 2001 04:44:48 -0500 Received: from mail pickup service by occlust04evs1.ugd.att.com with Microsoft SMTPSVC; Fri, 7 Dec 2001 04:44:40 -0500 Received: from occlust02evs1.ugd.att.com ([135.71.164.9]) by occlust04evs1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Dec 2001 17:19:02 -0500 Received: from attrh2i.attrh.att.com ([135.37.94.56]) by mo3980bh3.ems.att.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YJB1AS9A; Wed, 5 Dec 2001 14:10:18 -0600 Received: from wsscan.att.com (135.37.94.53) by attrh2i.attrh.att.com (5.5.029) id 3C06942A0013905C for rrroy@ems.att.com; Wed, 5 Dec 2001 15:10:16 -0500 Received: by wsscan.att.com; id PAA24192; Wed, 5 Dec 2001 15:14:46 -0500 (EST) Received: from almsi1.proxy.att.com(192.168.109.69) by cyrus5.wsscan.att.com via csmap (V4.1) id srcAAAtia4pV; Wed, 5 Dec 01 15:14:45 -0500 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by almsi1.proxy.att.com (AT&T IPNS/MSI-3.0) with ESMTP id fB5KAFG09686 for ; Wed, 5 Dec 2001 15:10:15 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB5K7J4S016205; Wed, 5 Dec 2001 15:08:43 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11483; Wed, 5 Dec 2001 15:09:05 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11464 for ; Wed, 5 Dec 2001 15:08:54 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB5JvT4I016058; Wed, 5 Dec 2001 14:57:30 -0500 (EST) MIME-Version: 1.0 Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Dec 2001 14:59:00 -0500 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary content-class: urn:content-classes:message Subject: [Simple] RE: [Sipping] Immediate NOTIFIES change in sip-events-01 Message-ID: X-MS-TNEF-Correlator: Thread-Topic: [Simple] RE: [Sipping] Immediate NOTIFIES change in sip-events-01 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Thread-Index: AcF9yNxQnMe8SOm7EdWjbgCQJ60IGQ== From: "Jonathan Rosenberg" To: "Fairlie-Cuninghame, Robert" , "Brian Stucker" , "Jonathan Rosenberg" , "Bert Culpepper" , Cc: , X-OriginalArrivalTime: 05 Dec 2001 22:19:02.0728 (UTC) FILETIME=[D83CA480:01C17DDA] Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 5 Dec 2001 14:58:59 -0500 Content-Transfer-Encoding: binary xŸ>"&äè€€Ñ :;o €Ñ  19 €!47BCC79CBBE9D511A36E009027AD0819;|0:'Fairlie-Cuninghame, Robert'0 SMTP0&rfairlie@nuera.com0 @:  0SMTP:RFAIRLIE@NUERA.COM ::'Fairlie-Cuninghame, Robert'0 'Brian Stucker'0 SMTP08bstucker@nortelnetworks.com0 @:   0!SMTP:BSTUCKER@NORTELNETWORKS.COM : 'Brian Stucker'0&Jonathan Rosenberg0 SMTP00jdrosen@dynamicsoft.com0 @:A  0SMTP:JDROSEN@DYNAMICSOFT.COM :&Jonathan Rosenberg0"'Bert Culpepper'0 SMTP0Hbert.culpepper@intervoice-brite.com0 @:  0)SMTP:BERT.CULPEPPER@INTERVOICE-BRITE.COM :"'Bert Culpepper'00adam.roach@ericsson.com0 SMTP00adam.roach@ericsson.com0 @:FO  0SMTP:ADAM.ROACH@ERICSSON.COM :0adam.roach@ericsson.com0'sip@ietf.org'0 SMTP0sip@ietf.org0 @:  0SMTP:SIP@IETF.ORG :'sip@ietf.org'0B'simple@mailman.dynamicsoft.com'0 SMTP0>simple@mailman.dynamicsoft.com0 @:FO  0$SMTP:SIMPLE@MAILMAN.DYNAMICSOFT.COM :B'simple@mailman.dynamicsoft.com'A ¸'IPM.NOTE&67„[Simple] RE: [Sipping] Immediate NOTIFIES change in sip-events-01@9€ƒ9GÇ}Á=p„[Simple] RE: [Sipping] Immediate NOTIFIES change in sip-events-01qÁ}ÈÜPœÇ¼Hé»Õ£n'­ &Jonathan Rosenberg„[Simple] RE: [Sipping] Immediate NOTIFIES change in sip-events-01   OLZFuíu6ü rcpg125â2CtexA÷ÿ €¤ä€óPV?U²%Qchá Àset2Ã%ö3F·0,3ï ÷¶;05" `cPó d36P ¦ ã €€I'm cc' €gIMPLE nce th ña jo €@× PÁa@a ^t àÐÁeôw— PÐqn w°k@ndap-ev ð Ð.Àlso^,#)#1"”i°mÝ$0n!ô#1pÁ$1ý"€I@qàÐÂ!Ql l@t"€#1.Gôåô> -*ÂO(!@ÐsagÖe*Ã*FFa:,Ð pær(°,CuÐà·€$0b@[À#):rf-T@n‘ Pra. m]*FW`0- W €ndäay$0No#€ÐL28$0Ð012°:Q3 PM*FT/P L'B! StÐká'; J P'ñëñn.¡g5p4€.²q-Àlpe&ð5B*Fa™1àm.`Ðh@qžc 0R*FCc- ­&Õ@0.°g0§˜ubj ±- RE- T[S&ä]'€m€d0°°OTIFI¾Eð'ã° €#)-3 »*F@.Tâ$-Ðd g(°50Agop`uvg+ð(Ði (ò€ ÿ4“)e@ˆ'" 7@#Bc¿)C4(c!á"& a9aÿ€q1 @—À °#O €A(°@leD‡Fÿ± €(Ðp $0G"ÿH ð‚ 3(r7`#ÂÿK‘°!*Uñ!à%àÂ5r7çuаiz÷ PC‘#ÐI@ EÒQ Þw#qÀ. NwàJ€ïOº@—(rðbò.  1ÿ*d.#Y&#w¦N£]²!Wçh*$0HO)e)ì'‘ó$ÂnkTÊ ¸PûNðàÖVÝãScÿ’Xâ!`7P{û¯5ä_ågÿWAPðˆ¢@!àdY!vŸ!` ±)ê( #€up- ÿRXâ.æßðò²sÿ/€sð{c"óYÓu•N6×ýÿ. (3Κƒ¿¦’¢ÚÅ#ß‚ôBbs”plQ×`Ÿ5 ?)N+{ûTHp¾k¢ö5˜{ÿ§cüÍD#Ðc6'$0Ph.M7½@E+àSÑú1A#€ý)eCà Ãá—‘(Ñk¿IFx3F°PVdþy+`9@]À¯ ?p(Ñüa2Ar2J 0Ì79 °´jd€6Až@™0R OCAX- !¦(973Œ 95ð2-50࣢@ïà¨//wð. .1°ë?¦P{ÐN<±J3÷/ °´_ÿÚ&v~mÔP¤SÀÂ(²ê@/½¡Ÿ:O$v/[(²"R/D°´}!à5CzDö,Eú, òó[Simple] RE%3A [Sipping] Immediate NOTIFIES change in sip-events-01.EML ô õ ö@0z'PÜÈ}Á@0l Ë—Ñ}ÁÞ?¯oß?ÿÿÿÿñ?ø?DInternet Mail Service (MO3980BH3)ù?qܧ@ÈÀB´¹+/á‚/O=ATT/OU=EMS/CN=CONFIGURATION/CN=CONNECTIONS/CN=INTERNET MAIL CONNECTOR (MO3980BH3)ú?DInternet Mail Service (MO3980BH3)û?qܧ@ÈÀB´¹+/á‚/O=ATT/OU=EMS/CN=CONFIGURATION/CN=CONNECTIONS/CN=INTERNET MAIL CONNECTOR (MO3980BH3)ý?ä@@0@0jdrosen@dynamicsoft.com1@0jdrosen@dynamicsoft.com8@HINTERNET MAIL CONNECTOR (MO3980BH3)9@0jdrosen@dynamicsoft.com ) #H{ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 06:17:18 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18833 for ; Fri, 7 Dec 2001 06:17:18 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7BFA4I025893; Fri, 7 Dec 2001 06:15:10 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18773; Fri, 7 Dec 2001 06:17:03 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18762 for ; Fri, 7 Dec 2001 06:16:48 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fB7BGKT08287; Fri, 7 Dec 2001 12:16:20 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id MAA25344; Fri, 7 Dec 2001 12:16:19 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xma022225; Fri, 7 Dec 01 12:14:21 +0100 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 12:14:18 +0100 Message-ID: From: Brazier Lachlan To: "'Paul Kyzivat '" , "'Jonathan Rosenberg '" Cc: "'adam.roach@ericsson.com '" , "''Brian Stucker' '" , "'simple '" Subject: AW: [Simple] 200 vs. 202 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 12:14:17 +0100 Hello, I believe the subscriber SHOULD keep all NOTIFY messages which arrive before the response to the SUBSCRIBE arives. After receiving the response the subscriber can decide which way to handle the NOTIFY's. 1) Only accept NOTIFY's which fit to the response 2) Accept all NOTIFY's (problem with DoS? - Is it one with firewalls?) 3) Accept only a subset of the NOTIFY's (based on some local policy) If the subscriber doesn't want to wait for the response to the SUBSCRIBE, and NOTIFY's arrive before the response, it has the possibilities: 1) Accept the first NOTIFY and ignore the response 2) Accept all NOTIFY's and ignore the response 3) Accept only a subset of the NOTIFY's 4) Accept no NOTIFY. When the response to the SUBSCRIBE arrives, subscribe again, but then accept the NOTIFY from the sender from the first SUBSCRIBE. ( NOTE: I DON'T propose that) There was the proposal to accept the dialog which arrives first, be it response or NOTIFY. Did I forget another possibility? I think all of them work. Basically all of them depend on a kind of local policy and on the kind of application, which shouldn't be controlled anyway by the protocol. So I vote for 1) as default procedure. Lachlan -----Originalnachricht----- Von: Paul Kyzivat An: Jonathan Rosenberg Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple Gesendet: 06.12.01 22:58 Betreff: Re: [Simple] 200 vs. 202 [SNIP] > > Do we have consensus though? I'd like to declare this issue resolved. Adam's > proposal was to accept the first NOTIFY, and ignore the 2xx. I'd like to > suggest a mild variant to that that I think is even simpler. My proposal is > to accept whatever comes first. If you get a 2xx to SUBSCRIBE first, that > establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes first, > you accept that. Any other NOTIFY are 481'd. The 2xx to SUBSCRIBE may or may > not be for the dialog that was accepted; it doesn't really matter. > > Agreement? I don't have a preference between those two alternatives. I won't stop progress by continuing to argue, but I don't find either solution very appealing. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 11:19:58 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23495 for ; Fri, 7 Dec 2001 11:19:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7GGC4I027389; Fri, 7 Dec 2001 11:16:12 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19708; Fri, 7 Dec 2001 11:18:03 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19697 for ; Fri, 7 Dec 2001 11:17:39 -0500 (EST) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id fB7GGaH03496; Fri, 7 Dec 2001 10:16:37 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fB7GGa609114; Fri, 7 Dec 2001 10:16:36 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id KAA21923; Fri, 7 Dec 2001 10:16:35 -0600 (CST) Reply-To: To: "'Christian Huitema'" , "Brazier Lachlan" , "Paul Kyzivat " , "Jonathan Rosenberg " Cc: , "'Brian Stucker' " , "simple " Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66CF1@eamrcnt717.exu.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 10:16:34 -0600 Content-Transfer-Encoding: 7bit > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > So, It seems that much boils down to the expectations of the > subscriber, > and its ability to sort out the mess created by a forking proxy. Do we > want to add a header line in SIP, such as: > > Fork-with-me: Don't you dare > > This would clearly tell proxies to not fork around... On a more serious note, I often lament the absence of a "Forking-Proxy-Require" header in the base spec. But I guess it's too late to do anything about that. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 11:32:14 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23683 for ; Fri, 7 Dec 2001 11:32:14 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7GT74I027546; Fri, 7 Dec 2001 11:29:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19772; Fri, 7 Dec 2001 11:31:02 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19761 for ; Fri, 7 Dec 2001 11:30:48 -0500 (EST) From: adam.roach@ericsson.com Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fB7GDaY18328; Fri, 7 Dec 2001 10:13:36 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fB7GDaS19701; Fri, 7 Dec 2001 10:13:36 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id KAA21629; Fri, 7 Dec 2001 10:13:35 -0600 (CST) Reply-To: To: "'Brazier Lachlan'" , "'Paul Kyzivat '" , "'Jonathan Rosenberg '" Cc: , "''Brian Stucker' '" , "'simple '" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66CF0@eamrcnt717.exu.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 10:13:33 -0600 Content-Transfer-Encoding: 7bit Brian: I can't tell what you're proposing, since you have two points labelled as "1)." I like the second "1)" just fine, and the variant in which the first dialog-establishing message (2xx or NOTIFY) just as well. /a > -----Original Message----- > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > Sent: Friday, December 07, 2001 5:14 AM > To: 'Paul Kyzivat '; 'Jonathan Rosenberg ' > Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple ' > Subject: AW: [Simple] 200 vs. 202 > > > Hello, > > I believe the subscriber SHOULD keep all NOTIFY messages > which arrive before > the response to the SUBSCRIBE arives. After receiving the response the > subscriber can decide which way to handle the NOTIFY's. > > 1) Only accept NOTIFY's which fit to the response > > 2) Accept all NOTIFY's (problem with DoS? - Is it one with firewalls?) > > 3) Accept only a subset of the NOTIFY's (based on some local policy) > > If the subscriber doesn't want to wait for the response to > the SUBSCRIBE, > and NOTIFY's arrive before the response, it has the possibilities: > > 1) Accept the first NOTIFY and ignore the response > > 2) Accept all NOTIFY's and ignore the response > > 3) Accept only a subset of the NOTIFY's > > 4) Accept no NOTIFY. When the response to the SUBSCRIBE > arrives, subscribe > again, but then accept the NOTIFY from the sender from the > first SUBSCRIBE. > ( NOTE: I DON'T propose that) > > There was the proposal to accept the dialog which arrives first, be it > response or NOTIFY. > > > Did I forget another possibility? I think all of them work. > Basically all of > them depend on a kind of local policy and on the kind of > application, which > shouldn't be controlled anyway by the protocol. > > So I vote for 1) as default procedure. > > Lachlan > > > -----Originalnachricht----- > Von: Paul Kyzivat > An: Jonathan Rosenberg > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple > Gesendet: 06.12.01 22:58 > Betreff: Re: [Simple] 200 vs. 202 > > [SNIP] > > > > > Do we have consensus though? I'd like to declare this issue > resolved. > Adam's > > proposal was to accept the first NOTIFY, and ignore the > 2xx. I'd like > to > > suggest a mild variant to that that I think is even simpler. My > proposal is > > to accept whatever comes first. If you get a 2xx to SUBSCRIBE first, > that > > establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes > first, > > you accept that. Any other NOTIFY are 481'd. The 2xx to > SUBSCRIBE may > or may > > not be for the dialog that was accepted; it doesn't really matter. > > > > Agreement? > > I don't have a preference between those two alternatives. > > I won't stop progress by continuing to argue, but I don't find either > solution very appealing. > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 11:40:03 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23835 for ; Fri, 7 Dec 2001 11:40:02 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7Gb84I027667; Fri, 7 Dec 2001 11:37:08 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19830; Fri, 7 Dec 2001 11:39:03 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19819 for ; Fri, 7 Dec 2001 11:38:10 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fB7GZ5903705; Fri, 7 Dec 2001 08:37:28 -0800 (PST) Received: from oranlt ([161.44.238.54]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ABP08767; Fri, 7 Dec 2001 08:35:09 -0800 (PST) From: "David R. Oran" To: , "'Christian Huitema'" , "'Brazier Lachlan'" , "'Paul Kyzivat '" , "'Jonathan Rosenberg '" Cc: "''Brian Stucker' '" , "'simple '" Subject: RE: [Simple] 200 vs. 202 Organization: Cisco Systems Message-ID: <017501c17f3d$2048a950$36ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 In-reply-to: <61D824C63B99D311975E00508B0CC98502C66CF1@eamrcnt717.exu.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 11:35:02 -0500 Content-Transfer-Encoding: 7bit There's a set of caller preferences to control forking. From draft-ietf-caller-pref-04.txt: fork-feature: This feature indicates whether a proxy should fork a request, or proxy to only a single address. If the server is requested not to fork, the server SHOULD proxy the request to the "best" address (generally the one with the highest q value). The feature is ignored if "redirect" has been requested. There's also: recurse-feature: This feature indicates whether a proxy server receiving a 300-class response should send requests to the addresses listed in the response (i.e., recurse), or forward the list of addresses upstream towards the caller. The feature is ignored if "redirect" has been requested. parallel-feature: For a forking proxy server, this feature indicates whether the caller would like the proxy server to proxy the request to all known addresses at once, or go through them sequentially, contacting the next address only after it has received a non-200 or non-600 final response for the previous one. The feature is ignored if "redirect" has been requested. Dave. > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > adam.roach@ericsson.com > Sent: Friday, December 07, 2001 11:17 AM > To: 'Christian Huitema'; Brazier Lachlan; Paul Kyzivat ; > Jonathan Rosenberg > Cc: adam.roach@ericsson.com; 'Brian Stucker' ; simple > Subject: RE: [Simple] 200 vs. 202 > > > > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > > > So, It seems that much boils down to the expectations of the > > subscriber, > > and its ability to sort out the mess created by a forking > proxy. Do we > > want to add a header line in SIP, such as: > > > > Fork-with-me: Don't you dare > > > > This would clearly tell proxies to not fork around... > > On a more serious note, I often lament the absence of a > "Forking-Proxy-Require" header in the base spec. > > But I guess it's too late to do anything about that. > > /a > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinf> o/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 11:46:12 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24004 for ; Fri, 7 Dec 2001 11:46:12 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7Gh94I027803; Fri, 7 Dec 2001 11:43:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19879; Fri, 7 Dec 2001 11:45:04 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19866 for ; Fri, 7 Dec 2001 11:44:48 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fB7GiLT13250; Fri, 7 Dec 2001 17:44:21 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id RAA03477; Fri, 7 Dec 2001 17:44:19 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xma003286; Fri, 7 Dec 01 17:44:09 +0100 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 17:44:07 +0100 Message-ID: From: Brazier Lachlan To: "'adam.roach@ericsson.com '" , Brazier Lachlan , "''Paul Kyzivat ' '" , "''Jonathan Rosenberg ' '" Cc: "'''Brian Stucker' ' '" , "''simple ' '" Subject: AW: [Simple] 200 vs. 202 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 17:44:05 +0100 Ups, sorry, I meant 1) Only accept NOTIFY's which fit to the response Lachlan -----Originalnachricht----- Von: adam.roach@ericsson.com An: 'Brazier Lachlan'; 'Paul Kyzivat '; 'Jonathan Rosenberg ' Cc: adam.roach@ericsson.com; ''Brian Stucker' '; 'simple ' Gesendet: 07.12.01 17:13 Betreff: RE: [Simple] 200 vs. 202 Brian: I can't tell what you're proposing, since you have two points labelled as "1)." I like the second "1)" just fine, and the variant in which the first dialog-establishing message (2xx or NOTIFY) just as well. /a > -----Original Message----- > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > Sent: Friday, December 07, 2001 5:14 AM > To: 'Paul Kyzivat '; 'Jonathan Rosenberg ' > Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple ' > Subject: AW: [Simple] 200 vs. 202 > > > Hello, > > I believe the subscriber SHOULD keep all NOTIFY messages > which arrive before > the response to the SUBSCRIBE arives. After receiving the response the > subscriber can decide which way to handle the NOTIFY's. > > 1) Only accept NOTIFY's which fit to the response > > 2) Accept all NOTIFY's (problem with DoS? - Is it one with firewalls?) > > 3) Accept only a subset of the NOTIFY's (based on some local policy) > > If the subscriber doesn't want to wait for the response to > the SUBSCRIBE, > and NOTIFY's arrive before the response, it has the possibilities: > > 1) Accept the first NOTIFY and ignore the response > > 2) Accept all NOTIFY's and ignore the response > > 3) Accept only a subset of the NOTIFY's > > 4) Accept no NOTIFY. When the response to the SUBSCRIBE > arrives, subscribe > again, but then accept the NOTIFY from the sender from the > first SUBSCRIBE. > ( NOTE: I DON'T propose that) > > There was the proposal to accept the dialog which arrives first, be it > response or NOTIFY. > > > Did I forget another possibility? I think all of them work. > Basically all of > them depend on a kind of local policy and on the kind of > application, which > shouldn't be controlled anyway by the protocol. > > So I vote for 1) as default procedure. > > Lachlan > > > -----Originalnachricht----- > Von: Paul Kyzivat > An: Jonathan Rosenberg > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple > Gesendet: 06.12.01 22:58 > Betreff: Re: [Simple] 200 vs. 202 > > [SNIP] > > > > > Do we have consensus though? I'd like to declare this issue > resolved. > Adam's > > proposal was to accept the first NOTIFY, and ignore the > 2xx. I'd like > to > > suggest a mild variant to that that I think is even simpler. My > proposal is > > to accept whatever comes first. If you get a 2xx to SUBSCRIBE first, > that > > establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes > first, > > you accept that. Any other NOTIFY are 481'd. The 2xx to > SUBSCRIBE may > or may > > not be for the dialog that was accepted; it doesn't really matter. > > > > Agreement? > > I don't have a preference between those two alternatives. > > I won't stop progress by continuing to argue, but I don't find either > solution very appealing. > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 11:52:01 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24221 for ; Fri, 7 Dec 2001 11:52:00 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7Gn74I027905; Fri, 7 Dec 2001 11:49:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19928; Fri, 7 Dec 2001 11:51:02 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19911 for ; Fri, 7 Dec 2001 11:50:08 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7GmB4I027887 for ; Fri, 7 Dec 2001 11:48:12 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 11:49:43 -0500 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , Jonathan Rosenberg , Robert Sparks Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] WGLC - watcherinfo MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 11:49:40 -0500 > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Wednesday, December 05, 2001 2:51 PM > To: jdrosen@dynamicsoft.com; Robert Sparks > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] WGLC - watcherinfo > > > > OK after re-reading this, I have a couple of comments on section 3.6.1 > (the FSM section.) > > 1) [tiny nit] The state diagram shows a timeout transition between > and . I don't find anything about that > in the text > treatment. It is in there: Of course, policy may never be specified for the subscription. As a result, the server can timeout the waiting subscription. The value for this timeout is system dependent. It SHOULD be several times larger than the default expiration time for the package being watched. Its not clear that this is the timeout event. I've reworded to: Of course, policy may never be specified for the subscription. As a result, the server can generate a timeout event to move the waiting subscription to the terminated state. The value for this timeout is system dependent. It {\SHOULD} be several times larger than the default expiration time for the package being watched. > > 2) Some of the FSM description really seems more a description of the > authorization FSM rather than the watcher info notification FSM. In > particular, the treatment of pending vs. waiting suggests behavior on > the part of the SIP-event service beyond that of watcher > reporting. This > section seems more descriptive than normative, so that is > probably okay. The section heading is a misnomer. You are right that this FSM is NOT the description of the winfo FSM. Its a descrption of the FSM for sip-events in general, or at least a model of that FSM, as a well-defined model is needed for the watcherinfo package to work. That definitely needs to be clarified. I updated the text at the top of 3.6 to say: Notifications may be generated for watcher information on package foo, when the subscription state for a user on package foo changes. The watcher information package therefore needs a model of subscription state. This is accomplished by specifying a subscription state machine, described below, which governs the subscription state of a user in any package. Notifications are generated on transitions in this state machine. Its important to note that this FSM is just a model of the subscription state machinery maintained by a server. An implementation would map its own state machines to this one in an implementation-specific manner. and I changed the title of 3.6.1 to "The Subscription State Machine" > > 3) I know this has come up many times before, and I don't remember the > resolution. Apologies if I am beating a dead horse: I have > some concern > about the concept of keeping state around indefinitely for pending > watchers. Could this not be used as a DoS against the server? It's not > nearly so bad as keeping state for denied users, but the threat may > still be there. I don't recall what conclusions were made from past discussions. I do think that it needs to be a policy decision. Remember, we are talking about authenticated, but not authorized, subscriptions, so that the room for DoS attacks is narrowed. Of course they can still happen. So, you want the server to be able to make a policy decision. It should be allowed to move the subscription to terminated at any time. The "timeout" event exists from the waiting state to terminated for this reason, but also needs to exist at the "pending" to "terminated" transition as an allowed event. I will add that. The spec also says that the server SHOULD set the timeout interval to be much larger than the refresh interval for subscriptions; i will temper that to discuss making it shorter to handle potential dos attacks. So, I added the following text: The ``timeout'' event is generated in either the waiting or pending states to destroy resources associated with unauthorized subscriptions. Servers need to exercise care in selecting this value. It needs to be large in order to provide a useful user experience; a presentity should be able to log in days later and see that someone tried to subscribe to them. However, allocating state to unauthorized subscriptions can be used as a source of DoS attacks. Therefore, it is RECOMMENDED that servers which retain state for unauthorized subscriptions add policies which prohibit a particular subscriber from having more than some number of pending or waiting subscriptions. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 11:57:25 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24406 for ; Fri, 7 Dec 2001 11:57:24 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7GsS4I028025; Fri, 7 Dec 2001 11:54:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19994; Fri, 7 Dec 2001 11:55:04 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19975 for ; Fri, 7 Dec 2001 11:54:07 -0500 (EST) From: adam.roach@ericsson.com Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id fB7Gq7H01091; Fri, 7 Dec 2001 10:52:07 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fB7Gq7S14220; Fri, 7 Dec 2001 10:52:07 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id KAA25742; Fri, 7 Dec 2001 10:52:06 -0600 (CST) Reply-To: To: "'Brazier Lachlan'" , , "''Paul Kyzivat ' '" , "''Jonathan Rosenberg ' '" Cc: "'''Brian Stucker' ' '" , "''simple ' '" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66CF3@eamrcnt717.exu.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 10:52:06 -0600 Content-Transfer-Encoding: 7bit Ah. In that case, I'm going to have to disagree for the exact same reasons that I objected when Jonathan proposed this: it's more complicated to implement, and the NOTIFY that corresponds to the final response doesn't have any special meaning. It's no better than any other NOTIFY. Keep it simple. (No pun intended). /a > -----Original Message----- > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > Sent: Friday, December 07, 2001 10:44 AM > To: 'adam.roach@ericsson.com '; Brazier Lachlan; ''Paul Kyzivat ' '; > ''Jonathan Rosenberg ' ' > Cc: '''Brian Stucker' ' '; ''simple ' ' > Subject: AW: [Simple] 200 vs. 202 > > > Ups, sorry, > > I meant > 1) Only accept NOTIFY's which fit to the response > > Lachlan > > -----Originalnachricht----- > Von: adam.roach@ericsson.com > An: 'Brazier Lachlan'; 'Paul Kyzivat '; 'Jonathan Rosenberg ' > Cc: adam.roach@ericsson.com; ''Brian Stucker' '; 'simple ' > Gesendet: 07.12.01 17:13 > Betreff: RE: [Simple] 200 vs. 202 > > Brian: > > I can't tell what you're proposing, since you have two points > labelled as "1)." I like the second "1)" just fine, and the > variant in which the first dialog-establishing message (2xx > or NOTIFY) just as well. > > /a > > > -----Original Message----- > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > Sent: Friday, December 07, 2001 5:14 AM > > To: 'Paul Kyzivat '; 'Jonathan Rosenberg ' > > Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple ' > > Subject: AW: [Simple] 200 vs. 202 > > > > > > Hello, > > > > I believe the subscriber SHOULD keep all NOTIFY messages > > which arrive before > > the response to the SUBSCRIBE arives. After receiving the > response the > > subscriber can decide which way to handle the NOTIFY's. > > > > 1) Only accept NOTIFY's which fit to the response > > > > 2) Accept all NOTIFY's (problem with DoS? - Is it one with > firewalls?) > > > > 3) Accept only a subset of the NOTIFY's (based on some local policy) > > > > If the subscriber doesn't want to wait for the response to > > the SUBSCRIBE, > > and NOTIFY's arrive before the response, it has the possibilities: > > > > 1) Accept the first NOTIFY and ignore the response > > > > 2) Accept all NOTIFY's and ignore the response > > > > 3) Accept only a subset of the NOTIFY's > > > > 4) Accept no NOTIFY. When the response to the SUBSCRIBE > > arrives, subscribe > > again, but then accept the NOTIFY from the sender from the > > first SUBSCRIBE. > > ( NOTE: I DON'T propose that) > > > > There was the proposal to accept the dialog which arrives > first, be it > > response or NOTIFY. > > > > > > Did I forget another possibility? I think all of them work. > > Basically all of > > them depend on a kind of local policy and on the kind of > > application, which > > shouldn't be controlled anyway by the protocol. > > > > So I vote for 1) as default procedure. > > > > Lachlan > > > > > > -----Originalnachricht----- > > Von: Paul Kyzivat > > An: Jonathan Rosenberg > > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple > > Gesendet: 06.12.01 22:58 > > Betreff: Re: [Simple] 200 vs. 202 > > > > [SNIP] > > > > > > > > Do we have consensus though? I'd like to declare this issue > > resolved. > > Adam's > > > proposal was to accept the first NOTIFY, and ignore the > > 2xx. I'd like > > to > > > suggest a mild variant to that that I think is even simpler. My > > proposal is > > > to accept whatever comes first. If you get a 2xx to > SUBSCRIBE first, > > that > > > establishes a dialog. All other NOTIFYs are 481d. If a > NOTIFY comes > > first, > > > you accept that. Any other NOTIFY are 481'd. The 2xx to > > SUBSCRIBE may > > or may > > > not be for the dialog that was accepted; it doesn't really matter. > > > > > > Agreement? > > > > I don't have a preference between those two alternatives. > > > > I won't stop progress by continuing to argue, but I don't > find either > > solution very appealing. > > > > Paul > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 12:13:38 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24867 for ; Fri, 7 Dec 2001 12:13:33 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7H384I028168; Fri, 7 Dec 2001 12:03:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20094; Fri, 7 Dec 2001 12:05:03 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20081 for ; Fri, 7 Dec 2001 12:04:44 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7H2l4I028162; Fri, 7 Dec 2001 12:02:47 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 12:04:18 -0500 Message-ID: From: Jonathan Rosenberg To: "'Paul Kyzivat'" , Jonathan Rosenberg Cc: adam.roach@ericsson.com, "'Brian Stucker'" , simple Subject: RE: [Simple] 200 vs. 202 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 12:04:14 -0500 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, December 06, 2001 4:59 PM > To: Jonathan Rosenberg > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple > Subject: Re: [Simple] 200 vs. 202 > > > > > Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Tuesday, November 27, 2001 8:40 AM > > > To: adam.roach@ericsson.com > > > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; simple > > > Subject: Re: [Simple] 200 vs. 202 > > > > > > > > > OK. Thanks for the tutorial - I think I get it now. > > > > > > But, all the complexity and loose ends suggests to me > that there is > > > something fundamentally wrong with the mechanism here. > > > > Well, the problem is that we are trying to add forking > capabilities into a > > method thats not ideally suited for it. > > Can't argue with that. It's unfortunate that we have a > forking mechanism > that really only works for INVITE even though it is defined for other > methods and (as we see here) is potentially wanted/needed for them as > well. Well, there are some who think it doesn't work for INVITE all that well either ;) Its not clear that you really want it in this scenario, to be honest. If you did, I might argue that we would need to define a "session presence" model that used INVITE to establish a presence session with a peer, with the SDP containing a place to send notifies..... I am not proposing that, mind you. > > > Given the frequency that I > > realistically expect to see forking SUBSCRIBE, I am not too worried. > > As devices are deployed that support presence, it seems like there > could develop a problem with undesired forking. You want forking > for invites, and perhaps don't have any simple way to prevent > forking of subscribes as well. > > This won't be a problem if the presence function is combined with the > registrar function and driven off registrations. It has nothing to do with being driven off of registrations; it has to do with whether the PA function is network or UA located. > But it will be a > problem with devices that want to handle presence themselves, like the > MS endpoint. All you need is people with both a desktop and laptop > machine that try to maintain one identity for both. Well, I have argued that for these cases, you just need to impose the restriction that if you want multiple end system based-PA, you need to have an aggregation point somewhere in the network. No system today allows for multiple independent clients to generate presence data for a single identity, LET ALONE having them do it without a server. So, user and network admin. expectations are already far below what we can do. > I won't stop progress by continuing to argue, but I don't find either > solution very appealing. I welcome an alternative workable proposal, as always.... -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 12:21:07 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25048 for ; Fri, 7 Dec 2001 12:21:06 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7HIC4I028309; Fri, 7 Dec 2001 12:18:12 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20181; Fri, 7 Dec 2001 12:20:04 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20168 for ; Fri, 7 Dec 2001 12:19:32 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7H7P4I028212; Fri, 7 Dec 2001 12:07:25 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 12:08:54 -0500 Message-ID: From: Jonathan Rosenberg To: "'adam.roach@ericsson.com'" , "'Brazier Lachlan'" , "''Paul Kyzivat ' '" , Jonathan Rosenberg Cc: "'''Brian Stucker' ' '" , "''simple ' '" Subject: RE: [Simple] 200 vs. 202 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 12:08:49 -0500 What was the problem with my proposal to accept what comes first (200 or NOTIFY)? Seems to consistently work and be really simple... -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Friday, December 07, 2001 11:52 AM > To: 'Brazier Lachlan'; adam.roach@ericsson.com; ''Paul Kyzivat ' '; > ''Jonathan Rosenberg ' ' > Cc: '''Brian Stucker' ' '; ''simple ' ' > Subject: RE: [Simple] 200 vs. 202 > > > Ah. In that case, I'm going to have to disagree for the > exact same reasons that I objected when Jonathan proposed > this: it's more complicated to implement, and the NOTIFY > that corresponds to the final response doesn't have any > special meaning. It's no better than any other NOTIFY. > > Keep it simple. (No pun intended). > > /a > > > -----Original Message----- > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > Sent: Friday, December 07, 2001 10:44 AM > > To: 'adam.roach@ericsson.com '; Brazier Lachlan; ''Paul Kyzivat ' '; > > ''Jonathan Rosenberg ' ' > > Cc: '''Brian Stucker' ' '; ''simple ' ' > > Subject: AW: [Simple] 200 vs. 202 > > > > > > Ups, sorry, > > > > I meant > > 1) Only accept NOTIFY's which fit to the response > > > > Lachlan > > > > -----Originalnachricht----- > > Von: adam.roach@ericsson.com > > An: 'Brazier Lachlan'; 'Paul Kyzivat '; 'Jonathan Rosenberg ' > > Cc: adam.roach@ericsson.com; ''Brian Stucker' '; 'simple ' > > Gesendet: 07.12.01 17:13 > > Betreff: RE: [Simple] 200 vs. 202 > > > > Brian: > > > > I can't tell what you're proposing, since you have two points > > labelled as "1)." I like the second "1)" just fine, and the > > variant in which the first dialog-establishing message (2xx > > or NOTIFY) just as well. > > > > /a > > > > > -----Original Message----- > > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > > Sent: Friday, December 07, 2001 5:14 AM > > > To: 'Paul Kyzivat '; 'Jonathan Rosenberg ' > > > Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple ' > > > Subject: AW: [Simple] 200 vs. 202 > > > > > > > > > Hello, > > > > > > I believe the subscriber SHOULD keep all NOTIFY messages > > > which arrive before > > > the response to the SUBSCRIBE arives. After receiving the > > response the > > > subscriber can decide which way to handle the NOTIFY's. > > > > > > 1) Only accept NOTIFY's which fit to the response > > > > > > 2) Accept all NOTIFY's (problem with DoS? - Is it one with > > firewalls?) > > > > > > 3) Accept only a subset of the NOTIFY's (based on some > local policy) > > > > > > If the subscriber doesn't want to wait for the response to > > > the SUBSCRIBE, > > > and NOTIFY's arrive before the response, it has the possibilities: > > > > > > 1) Accept the first NOTIFY and ignore the response > > > > > > 2) Accept all NOTIFY's and ignore the response > > > > > > 3) Accept only a subset of the NOTIFY's > > > > > > 4) Accept no NOTIFY. When the response to the SUBSCRIBE > > > arrives, subscribe > > > again, but then accept the NOTIFY from the sender from the > > > first SUBSCRIBE. > > > ( NOTE: I DON'T propose that) > > > > > > There was the proposal to accept the dialog which arrives > > first, be it > > > response or NOTIFY. > > > > > > > > > Did I forget another possibility? I think all of them work. > > > Basically all of > > > them depend on a kind of local policy and on the kind of > > > application, which > > > shouldn't be controlled anyway by the protocol. > > > > > > So I vote for 1) as default procedure. > > > > > > Lachlan > > > > > > > > > -----Originalnachricht----- > > > Von: Paul Kyzivat > > > An: Jonathan Rosenberg > > > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple > > > Gesendet: 06.12.01 22:58 > > > Betreff: Re: [Simple] 200 vs. 202 > > > > > > [SNIP] > > > > > > > > > > > Do we have consensus though? I'd like to declare this issue > > > resolved. > > > Adam's > > > > proposal was to accept the first NOTIFY, and ignore the > > > 2xx. I'd like > > > to > > > > suggest a mild variant to that that I think is even simpler. My > > > proposal is > > > > to accept whatever comes first. If you get a 2xx to > > SUBSCRIBE first, > > > that > > > > establishes a dialog. All other NOTIFYs are 481d. If a > > NOTIFY comes > > > first, > > > > you accept that. Any other NOTIFY are 481'd. The 2xx to > > > SUBSCRIBE may > > > or may > > > > not be for the dialog that was accepted; it doesn't > really matter. > > > > > > > > Agreement? > > > > > > I don't have a preference between those two alternatives. > > > > > > I won't stop progress by continuing to argue, but I don't > > find either > > > solution very appealing. > > > > > > Paul > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 12:41:25 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25556 for ; Fri, 7 Dec 2001 12:41:25 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7HcB4I028483; Fri, 7 Dec 2001 12:38:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20275; Fri, 7 Dec 2001 12:40:05 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20262 for ; Fri, 7 Dec 2001 12:39:11 -0500 (EST) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id fB7HXSH01276; Fri, 7 Dec 2001 11:33:28 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fB7HXS627754; Fri, 7 Dec 2001 11:33:28 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA00242; Fri, 7 Dec 2001 11:33:27 -0600 (CST) Reply-To: To: "'Jonathan Rosenberg'" , , "'Brazier Lachlan'" , "''Paul Kyzivat ' '" Cc: "'''Brian Stucker' ' '" , "''simple ' '" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66CF5@eamrcnt717.exu.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 11:33:26 -0600 Content-Transfer-Encoding: 7bit Sorry for the confusion. I was talking about an earlier suggestion -- the one Brian reiterates as "Only accept NOTIFY's which fit to the response". Your revision of my earlier proposal -- which allows SUBSCRIBE responses to create dialogs -- is the best solution I've seen proposed so far. /a > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, December 07, 2001 11:09 AM > To: 'adam.roach@ericsson.com'; 'Brazier Lachlan'; ''Paul Kyzivat ' '; > Jonathan Rosenberg > Cc: '''Brian Stucker' ' '; ''simple ' ' > Subject: RE: [Simple] 200 vs. 202 > > > What was the problem with my proposal to accept what comes > first (200 or > NOTIFY)? Seems to consistently work and be really simple... > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > Sent: Friday, December 07, 2001 11:52 AM > > To: 'Brazier Lachlan'; adam.roach@ericsson.com; ''Paul Kyzivat ' '; > > ''Jonathan Rosenberg ' ' > > Cc: '''Brian Stucker' ' '; ''simple ' ' > > Subject: RE: [Simple] 200 vs. 202 > > > > > > Ah. In that case, I'm going to have to disagree for the > > exact same reasons that I objected when Jonathan proposed > > this: it's more complicated to implement, and the NOTIFY > > that corresponds to the final response doesn't have any > > special meaning. It's no better than any other NOTIFY. > > > > Keep it simple. (No pun intended). > > > > /a > > > > > -----Original Message----- > > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > > Sent: Friday, December 07, 2001 10:44 AM > > > To: 'adam.roach@ericsson.com '; Brazier Lachlan; ''Paul > Kyzivat ' '; > > > ''Jonathan Rosenberg ' ' > > > Cc: '''Brian Stucker' ' '; ''simple ' ' > > > Subject: AW: [Simple] 200 vs. 202 > > > > > > > > > Ups, sorry, > > > > > > I meant > > > 1) Only accept NOTIFY's which fit to the response > > > > > > Lachlan > > > > > > -----Originalnachricht----- > > > Von: adam.roach@ericsson.com > > > An: 'Brazier Lachlan'; 'Paul Kyzivat '; 'Jonathan Rosenberg ' > > > Cc: adam.roach@ericsson.com; ''Brian Stucker' '; 'simple ' > > > Gesendet: 07.12.01 17:13 > > > Betreff: RE: [Simple] 200 vs. 202 > > > > > > Brian: > > > > > > I can't tell what you're proposing, since you have two points > > > labelled as "1)." I like the second "1)" just fine, and the > > > variant in which the first dialog-establishing message (2xx > > > or NOTIFY) just as well. > > > > > > /a > > > > > > > -----Original Message----- > > > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > > > Sent: Friday, December 07, 2001 5:14 AM > > > > To: 'Paul Kyzivat '; 'Jonathan Rosenberg ' > > > > Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple ' > > > > Subject: AW: [Simple] 200 vs. 202 > > > > > > > > > > > > Hello, > > > > > > > > I believe the subscriber SHOULD keep all NOTIFY messages > > > > which arrive before > > > > the response to the SUBSCRIBE arives. After receiving the > > > response the > > > > subscriber can decide which way to handle the NOTIFY's. > > > > > > > > 1) Only accept NOTIFY's which fit to the response > > > > > > > > 2) Accept all NOTIFY's (problem with DoS? - Is it one with > > > firewalls?) > > > > > > > > 3) Accept only a subset of the NOTIFY's (based on some > > local policy) > > > > > > > > If the subscriber doesn't want to wait for the response to > > > > the SUBSCRIBE, > > > > and NOTIFY's arrive before the response, it has the > possibilities: > > > > > > > > 1) Accept the first NOTIFY and ignore the response > > > > > > > > 2) Accept all NOTIFY's and ignore the response > > > > > > > > 3) Accept only a subset of the NOTIFY's > > > > > > > > 4) Accept no NOTIFY. When the response to the SUBSCRIBE > > > > arrives, subscribe > > > > again, but then accept the NOTIFY from the sender from the > > > > first SUBSCRIBE. > > > > ( NOTE: I DON'T propose that) > > > > > > > > There was the proposal to accept the dialog which arrives > > > first, be it > > > > response or NOTIFY. > > > > > > > > > > > > Did I forget another possibility? I think all of them work. > > > > Basically all of > > > > them depend on a kind of local policy and on the kind of > > > > application, which > > > > shouldn't be controlled anyway by the protocol. > > > > > > > > So I vote for 1) as default procedure. > > > > > > > > Lachlan > > > > > > > > > > > > -----Originalnachricht----- > > > > Von: Paul Kyzivat > > > > An: Jonathan Rosenberg > > > > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple > > > > Gesendet: 06.12.01 22:58 > > > > Betreff: Re: [Simple] 200 vs. 202 > > > > > > > > [SNIP] > > > > > > > > > > > > > > Do we have consensus though? I'd like to declare this issue > > > > resolved. > > > > Adam's > > > > > proposal was to accept the first NOTIFY, and ignore the > > > > 2xx. I'd like > > > > to > > > > > suggest a mild variant to that that I think is even > simpler. My > > > > proposal is > > > > > to accept whatever comes first. If you get a 2xx to > > > SUBSCRIBE first, > > > > that > > > > > establishes a dialog. All other NOTIFYs are 481d. If a > > > NOTIFY comes > > > > first, > > > > > you accept that. Any other NOTIFY are 481'd. The 2xx to > > > > SUBSCRIBE may > > > > or may > > > > > not be for the dialog that was accepted; it doesn't > > really matter. > > > > > > > > > > Agreement? > > > > > > > > I don't have a preference between those two alternatives. > > > > > > > > I won't stop progress by continuing to argue, but I don't > > > find either > > > > solution very appealing. > > > > > > > > Paul > > > > _______________________________________________ > > > > simple mailing list > > > > simple@mailman.dynamicsoft.com > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 13:28:17 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27105 for ; Fri, 7 Dec 2001 13:28:17 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7IPB4I028883; Fri, 7 Dec 2001 13:25:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20444; Fri, 7 Dec 2001 13:27:03 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20433 for ; Fri, 7 Dec 2001 13:26:08 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7IL34I028845; Fri, 7 Dec 2001 13:21:03 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 13:22:33 -0500 Message-ID: From: Jonathan Rosenberg To: "'adam.roach@ericsson.com'" , Jonathan Rosenberg , "'Brazier Lachlan'" , "''Paul Kyzivat ' '" Cc: "'''Brian Stucker' ' '" , "''simple ' '" Subject: RE: [Simple] 200 vs. 202 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 13:22:26 -0500 Adam, Assuming that the consensus is to use this approach when you want to accept only a single notification, you agree this belongs in sip-events, right? Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Friday, December 07, 2001 12:33 PM > To: 'Jonathan Rosenberg'; adam.roach@ericsson.com; 'Brazier Lachlan'; > ''Paul Kyzivat ' ' > Cc: '''Brian Stucker' ' '; ''simple ' ' > Subject: RE: [Simple] 200 vs. 202 > > > Sorry for the confusion. > > I was talking about an earlier suggestion -- the one Brian > reiterates as "Only accept NOTIFY's which fit to the response". > > Your revision of my earlier proposal -- which allows SUBSCRIBE > responses to create dialogs -- is the best solution I've seen > proposed so far. > > /a > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Friday, December 07, 2001 11:09 AM > > To: 'adam.roach@ericsson.com'; 'Brazier Lachlan'; ''Paul > Kyzivat ' '; > > Jonathan Rosenberg > > Cc: '''Brian Stucker' ' '; ''simple ' ' > > Subject: RE: [Simple] 200 vs. 202 > > > > > > What was the problem with my proposal to accept what comes > > first (200 or > > NOTIFY)? Seems to consistently work and be really simple... > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > > -----Original Message----- > > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > > Sent: Friday, December 07, 2001 11:52 AM > > > To: 'Brazier Lachlan'; adam.roach@ericsson.com; ''Paul > Kyzivat ' '; > > > ''Jonathan Rosenberg ' ' > > > Cc: '''Brian Stucker' ' '; ''simple ' ' > > > Subject: RE: [Simple] 200 vs. 202 > > > > > > > > > Ah. In that case, I'm going to have to disagree for the > > > exact same reasons that I objected when Jonathan proposed > > > this: it's more complicated to implement, and the NOTIFY > > > that corresponds to the final response doesn't have any > > > special meaning. It's no better than any other NOTIFY. > > > > > > Keep it simple. (No pun intended). > > > > > > /a > > > > > > > -----Original Message----- > > > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > > > Sent: Friday, December 07, 2001 10:44 AM > > > > To: 'adam.roach@ericsson.com '; Brazier Lachlan; ''Paul > > Kyzivat ' '; > > > > ''Jonathan Rosenberg ' ' > > > > Cc: '''Brian Stucker' ' '; ''simple ' ' > > > > Subject: AW: [Simple] 200 vs. 202 > > > > > > > > > > > > Ups, sorry, > > > > > > > > I meant > > > > 1) Only accept NOTIFY's which fit to the response > > > > > > > > Lachlan > > > > > > > > -----Originalnachricht----- > > > > Von: adam.roach@ericsson.com > > > > An: 'Brazier Lachlan'; 'Paul Kyzivat '; 'Jonathan Rosenberg ' > > > > Cc: adam.roach@ericsson.com; ''Brian Stucker' '; 'simple ' > > > > Gesendet: 07.12.01 17:13 > > > > Betreff: RE: [Simple] 200 vs. 202 > > > > > > > > Brian: > > > > > > > > I can't tell what you're proposing, since you have two points > > > > labelled as "1)." I like the second "1)" just fine, and the > > > > variant in which the first dialog-establishing message (2xx > > > > or NOTIFY) just as well. > > > > > > > > /a > > > > > > > > > -----Original Message----- > > > > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > > > > Sent: Friday, December 07, 2001 5:14 AM > > > > > To: 'Paul Kyzivat '; 'Jonathan Rosenberg ' > > > > > Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple ' > > > > > Subject: AW: [Simple] 200 vs. 202 > > > > > > > > > > > > > > > Hello, > > > > > > > > > > I believe the subscriber SHOULD keep all NOTIFY messages > > > > > which arrive before > > > > > the response to the SUBSCRIBE arives. After receiving the > > > > response the > > > > > subscriber can decide which way to handle the NOTIFY's. > > > > > > > > > > 1) Only accept NOTIFY's which fit to the response > > > > > > > > > > 2) Accept all NOTIFY's (problem with DoS? - Is it one with > > > > firewalls?) > > > > > > > > > > 3) Accept only a subset of the NOTIFY's (based on some > > > local policy) > > > > > > > > > > If the subscriber doesn't want to wait for the response to > > > > > the SUBSCRIBE, > > > > > and NOTIFY's arrive before the response, it has the > > possibilities: > > > > > > > > > > 1) Accept the first NOTIFY and ignore the response > > > > > > > > > > 2) Accept all NOTIFY's and ignore the response > > > > > > > > > > 3) Accept only a subset of the NOTIFY's > > > > > > > > > > 4) Accept no NOTIFY. When the response to the SUBSCRIBE > > > > > arrives, subscribe > > > > > again, but then accept the NOTIFY from the sender from the > > > > > first SUBSCRIBE. > > > > > ( NOTE: I DON'T propose that) > > > > > > > > > > There was the proposal to accept the dialog which arrives > > > > first, be it > > > > > response or NOTIFY. > > > > > > > > > > > > > > > Did I forget another possibility? I think all of them work. > > > > > Basically all of > > > > > them depend on a kind of local policy and on the kind of > > > > > application, which > > > > > shouldn't be controlled anyway by the protocol. > > > > > > > > > > So I vote for 1) as default procedure. > > > > > > > > > > Lachlan > > > > > > > > > > > > > > > -----Originalnachricht----- > > > > > Von: Paul Kyzivat > > > > > An: Jonathan Rosenberg > > > > > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple > > > > > Gesendet: 06.12.01 22:58 > > > > > Betreff: Re: [Simple] 200 vs. 202 > > > > > > > > > > [SNIP] > > > > > > > > > > > > > > > > > Do we have consensus though? I'd like to declare this issue > > > > > resolved. > > > > > Adam's > > > > > > proposal was to accept the first NOTIFY, and ignore the > > > > > 2xx. I'd like > > > > > to > > > > > > suggest a mild variant to that that I think is even > > simpler. My > > > > > proposal is > > > > > > to accept whatever comes first. If you get a 2xx to > > > > SUBSCRIBE first, > > > > > that > > > > > > establishes a dialog. All other NOTIFYs are 481d. If a > > > > NOTIFY comes > > > > > first, > > > > > > you accept that. Any other NOTIFY are 481'd. The 2xx to > > > > > SUBSCRIBE may > > > > > or may > > > > > > not be for the dialog that was accepted; it doesn't > > > really matter. > > > > > > > > > > > > Agreement? > > > > > > > > > > I don't have a preference between those two alternatives. > > > > > > > > > > I won't stop progress by continuing to argue, but I don't > > > > find either > > > > > solution very appealing. > > > > > > > > > > Paul > > > > > _______________________________________________ > > > > > simple mailing list > > > > > simple@mailman.dynamicsoft.com > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > > > > > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 13:34:11 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27284 for ; Fri, 7 Dec 2001 13:34:10 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7IV74I028965; Fri, 7 Dec 2001 13:31:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20489; Fri, 7 Dec 2001 13:33:02 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20476 for ; Fri, 7 Dec 2001 13:32:41 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7ISr4I028951; Fri, 7 Dec 2001 13:28:53 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 13:30:23 -0500 Message-ID: From: Jonathan Rosenberg To: "'David R. Oran'" , adam.roach@ericsson.com, "'Christian Huitema'" , "'Brazier Lachlan'" , "'Paul Kyzivat '" , Jonathan Rosenberg Cc: "''Brian Stucker' '" , "'simple '" Subject: RE: [Simple] 200 vs. 202 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 13:30:19 -0500 > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Friday, December 07, 2001 11:35 AM > To: adam.roach@ericsson.com; 'Christian Huitema'; 'Brazier Lachlan'; > 'Paul Kyzivat '; 'Jonathan Rosenberg ' > Cc: ''Brian Stucker' '; 'simple ' > Subject: RE: [Simple] 200 vs. 202 > > > There's a set of caller preferences to control forking. From > draft-ietf-caller-pref-04.txt: > > > fork-feature: This feature indicates whether a proxy > should fork > a request, or proxy to only a single address. If > the server > is requested not to fork, the server SHOULD proxy the > request to the "best" address (generally the one with the > highest q value). The feature is ignored if > "redirect" has > been requested. Its worth noting that the proposal to accept a single NOTIFY amounts to the same thing, except that we ignore any forked branches rather than having them not occur in the first place. I should also point out that caller preferences is optional to obey, so you would have to handle the forking anyway. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 14:40:25 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28690 for ; Fri, 7 Dec 2001 14:40:25 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7JbA4I029388; Fri, 7 Dec 2001 14:37:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20725; Fri, 7 Dec 2001 14:39:04 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20713 for ; Fri, 7 Dec 2001 14:38:03 -0500 (EST) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fB7JMuY25730; Fri, 7 Dec 2001 13:22:56 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fB7JMuq28358; Fri, 7 Dec 2001 13:22:56 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id NAA10788; Fri, 7 Dec 2001 13:22:55 -0600 (CST) Reply-To: To: "'Jonathan Rosenberg'" , , "'Brazier Lachlan'" , "''Paul Kyzivat ' '" Cc: "'''Brian Stucker' ' '" , "''simple ' '" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66CF6@eamrcnt717.exu.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 13:22:54 -0600 Content-Transfer-Encoding: 7bit Yes. The consensus on this topic will be described in detail in sip-events, and does not need to be reiterated in any SIMPLE documents. /a > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, December 07, 2001 12:22 PM > To: 'adam.roach@ericsson.com'; Jonathan Rosenberg; 'Brazier Lachlan'; > ''Paul Kyzivat ' ' > Cc: '''Brian Stucker' ' '; ''simple ' ' > Subject: RE: [Simple] 200 vs. 202 > > > Adam, > > Assuming that the consensus is to use this approach when you > want to accept > only a single notification, you agree this belongs in > sip-events, right? > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > Sent: Friday, December 07, 2001 12:33 PM > > To: 'Jonathan Rosenberg'; adam.roach@ericsson.com; 'Brazier > Lachlan'; > > ''Paul Kyzivat ' ' > > Cc: '''Brian Stucker' ' '; ''simple ' ' > > Subject: RE: [Simple] 200 vs. 202 > > > > > > Sorry for the confusion. > > > > I was talking about an earlier suggestion -- the one Brian > > reiterates as "Only accept NOTIFY's which fit to the response". > > > > Your revision of my earlier proposal -- which allows SUBSCRIBE > > responses to create dialogs -- is the best solution I've seen > > proposed so far. > > > > /a > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Friday, December 07, 2001 11:09 AM > > > To: 'adam.roach@ericsson.com'; 'Brazier Lachlan'; ''Paul > > Kyzivat ' '; > > > Jonathan Rosenberg > > > Cc: '''Brian Stucker' ' '; ''simple ' ' > > > Subject: RE: [Simple] 200 vs. 202 > > > > > > > > > What was the problem with my proposal to accept what comes > > > first (200 or > > > NOTIFY)? Seems to consistently work and be really simple... > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > > > > > -----Original Message----- > > > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > > > Sent: Friday, December 07, 2001 11:52 AM > > > > To: 'Brazier Lachlan'; adam.roach@ericsson.com; ''Paul > > Kyzivat ' '; > > > > ''Jonathan Rosenberg ' ' > > > > Cc: '''Brian Stucker' ' '; ''simple ' ' > > > > Subject: RE: [Simple] 200 vs. 202 > > > > > > > > > > > > Ah. In that case, I'm going to have to disagree for the > > > > exact same reasons that I objected when Jonathan proposed > > > > this: it's more complicated to implement, and the NOTIFY > > > > that corresponds to the final response doesn't have any > > > > special meaning. It's no better than any other NOTIFY. > > > > > > > > Keep it simple. (No pun intended). > > > > > > > > /a > > > > > > > > > -----Original Message----- > > > > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > > > > Sent: Friday, December 07, 2001 10:44 AM > > > > > To: 'adam.roach@ericsson.com '; Brazier Lachlan; ''Paul > > > Kyzivat ' '; > > > > > ''Jonathan Rosenberg ' ' > > > > > Cc: '''Brian Stucker' ' '; ''simple ' ' > > > > > Subject: AW: [Simple] 200 vs. 202 > > > > > > > > > > > > > > > Ups, sorry, > > > > > > > > > > I meant > > > > > 1) Only accept NOTIFY's which fit to the response > > > > > > > > > > Lachlan > > > > > > > > > > -----Originalnachricht----- > > > > > Von: adam.roach@ericsson.com > > > > > An: 'Brazier Lachlan'; 'Paul Kyzivat '; 'Jonathan Rosenberg ' > > > > > Cc: adam.roach@ericsson.com; ''Brian Stucker' '; 'simple ' > > > > > Gesendet: 07.12.01 17:13 > > > > > Betreff: RE: [Simple] 200 vs. 202 > > > > > > > > > > Brian: > > > > > > > > > > I can't tell what you're proposing, since you have two points > > > > > labelled as "1)." I like the second "1)" just fine, and the > > > > > variant in which the first dialog-establishing message (2xx > > > > > or NOTIFY) just as well. > > > > > > > > > > /a > > > > > > > > > > > -----Original Message----- > > > > > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > > > > > Sent: Friday, December 07, 2001 5:14 AM > > > > > > To: 'Paul Kyzivat '; 'Jonathan Rosenberg ' > > > > > > Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; > 'simple ' > > > > > > Subject: AW: [Simple] 200 vs. 202 > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > I believe the subscriber SHOULD keep all NOTIFY messages > > > > > > which arrive before > > > > > > the response to the SUBSCRIBE arives. After receiving the > > > > > response the > > > > > > subscriber can decide which way to handle the NOTIFY's. > > > > > > > > > > > > 1) Only accept NOTIFY's which fit to the response > > > > > > > > > > > > 2) Accept all NOTIFY's (problem with DoS? - Is it one with > > > > > firewalls?) > > > > > > > > > > > > 3) Accept only a subset of the NOTIFY's (based on some > > > > local policy) > > > > > > > > > > > > If the subscriber doesn't want to wait for the response to > > > > > > the SUBSCRIBE, > > > > > > and NOTIFY's arrive before the response, it has the > > > possibilities: > > > > > > > > > > > > 1) Accept the first NOTIFY and ignore the response > > > > > > > > > > > > 2) Accept all NOTIFY's and ignore the response > > > > > > > > > > > > 3) Accept only a subset of the NOTIFY's > > > > > > > > > > > > 4) Accept no NOTIFY. When the response to the SUBSCRIBE > > > > > > arrives, subscribe > > > > > > again, but then accept the NOTIFY from the sender from the > > > > > > first SUBSCRIBE. > > > > > > ( NOTE: I DON'T propose that) > > > > > > > > > > > > There was the proposal to accept the dialog which arrives > > > > > first, be it > > > > > > response or NOTIFY. > > > > > > > > > > > > > > > > > > Did I forget another possibility? I think all of them work. > > > > > > Basically all of > > > > > > them depend on a kind of local policy and on the kind of > > > > > > application, which > > > > > > shouldn't be controlled anyway by the protocol. > > > > > > > > > > > > So I vote for 1) as default procedure. > > > > > > > > > > > > Lachlan > > > > > > > > > > > > > > > > > > -----Originalnachricht----- > > > > > > Von: Paul Kyzivat > > > > > > An: Jonathan Rosenberg > > > > > > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple > > > > > > Gesendet: 06.12.01 22:58 > > > > > > Betreff: Re: [Simple] 200 vs. 202 > > > > > > > > > > > > [SNIP] > > > > > > > > > > > > > > > > > > > > Do we have consensus though? I'd like to declare > this issue > > > > > > resolved. > > > > > > Adam's > > > > > > > proposal was to accept the first NOTIFY, and ignore the > > > > > > 2xx. I'd like > > > > > > to > > > > > > > suggest a mild variant to that that I think is even > > > simpler. My > > > > > > proposal is > > > > > > > to accept whatever comes first. If you get a 2xx to > > > > > SUBSCRIBE first, > > > > > > that > > > > > > > establishes a dialog. All other NOTIFYs are 481d. If a > > > > > NOTIFY comes > > > > > > first, > > > > > > > you accept that. Any other NOTIFY are 481'd. The 2xx to > > > > > > SUBSCRIBE may > > > > > > or may > > > > > > > not be for the dialog that was accepted; it doesn't > > > > really matter. > > > > > > > > > > > > > > Agreement? > > > > > > > > > > > > I don't have a preference between those two alternatives. > > > > > > > > > > > > I won't stop progress by continuing to argue, but I don't > > > > > find either > > > > > > solution very appealing. > > > > > > > > > > > > Paul > > > > > > _______________________________________________ > > > > > > simple mailing list > > > > > > simple@mailman.dynamicsoft.com > > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > > > > > > > > > > > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 14:53:10 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28833 for ; Fri, 7 Dec 2001 14:53:10 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7Jo94I029599; Fri, 7 Dec 2001 14:50:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20837; Fri, 7 Dec 2001 14:52:04 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20821 for ; Fri, 7 Dec 2001 14:51:09 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7JnD4I029585; Fri, 7 Dec 2001 14:49:13 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 14:50:43 -0500 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Cc: "'sip@ietf.oeg'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Alginment of sip-events and watcherinfo Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 14:50:37 -0500 (resend; first attempt seemed to have been garbled) I'm cc'ing SIMPLE since this is a joint issue that affects both the watcherinfo work and sip-events. Also, sip-events is a sip work item, not sipping, so I am changing the list to sip. > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Wednesday, November 28, 2001 2:00 PM > To: 'Brian Stucker'; Jonathan Rosenberg; 'Bert Culpepper'; > adam.roach@ericsson.com > Cc: sipping@ietf.org > Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01 > > > This sounds like a good suggestion to me Brian. > > I would like to suggest the watherinfo reason codes are > expanded a little. > For instance, the watcherinfo assumes that the pending states > is waiting for > authorization. It could however be pending while waiting for > the subscribed > object to become active (note: I am not referring to the > subscribed Event > package here). This sort of behavior may be typical/useful > when you are > trying to subscribe to an event that has not started yet (and > yet you desire > to have the subscription in place _before_ the event begins). OK, but in this case, the subscription itself is not pending, its the state of the object that is effectively "TBD". This should be reflected in the presence document delivered in the first NOTIFY, not in the state of the subscription, IMHO. > I also think > the rejection/termination reasons could be expanded a little more. Suggestions? Brian Stucker wrote: > > I can't see much use in including the > event field since > (presumably) the watcher will know what event triggered the > NOTIFY, and if > they can't, they can use watcherinfo to get it. No, these are not events of the presentity, they are events of the subscription. These events correspond quite closely to the "reason" parameters Adam has currently specified. In fact, for the rejecttion events, here is the mapping: sip-events watcherinfo ---------- ----------- migration <-> deactivated maint <-> ? refused <-> rejected timeout <-> expired ? <-> timeout Clearly, these should be aligned, and should be present in both the SUbscription-Expires and the watcherinfo format. Its not clear to me what the semantics of maint are; should the client retry after some period? Presuming we can define it conciesely, we should add it to the watcherinfo package. So, here would be my proposal for the unified set: deactivated: subscription is terminated, but client SHOULD retry immediately with a new subscription. This handles migration plus other cases potentially. probation: subscription is terminated; but client SHOULD retry at some later time (we could include a Retry-After header in the case of presence in the Subscription-Expires header) rejected: subscription terminated due to change in authorization policy. Retrying will not help. timeout: subscription terminated because it was not refreshed. giveup: could not obtain authorization in a timely fashion, and so the pending subscription is being terminated. The client can retry and will likely get put back into pending state. THanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 15:17:00 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29270 for ; Fri, 7 Dec 2001 15:17:00 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7KE94I029800; Fri, 7 Dec 2001 15:14:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20952; Fri, 7 Dec 2001 15:16:03 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20941 for ; Fri, 7 Dec 2001 15:15:22 -0500 (EST) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fB7KESY17549; Fri, 7 Dec 2001 14:14:28 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fB7KERq14841; Fri, 7 Dec 2001 14:14:27 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id OAA16090; Fri, 7 Dec 2001 14:14:26 -0600 (CST) Reply-To: To: "'Paul Kyzivat'" , "Jonathan Rosenberg" Cc: "'warren montgomery'" , Subject: RE: [Simple] New I-D on IM transport Message-ID: <61D824C63B99D311975E00508B0CC98502C66CF9@eamrcnt717.exu.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3BFA68B2.94C6CEB2@cisco.com> Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 14:14:24 -0600 Content-Transfer-Encoding: 7bit Slightly off topic, but just offering an explanation... > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > The latest versions of SDP don't permit FQDNs in the c= line. > I never did hear why this change was made. While it often may > be wise to > avoid FQDNs in sdp, it seems pretty heavy handed to forbid them, since > as you point out here there may be cases where they are useful. The issue as I understand it is that people want to be able to design endpoints that do not necessarily have DNS capabilities. I'm not going to defend this design decision. If sending of FQDNs is a MAY, then being able to receive them is necessarily a MUST, lest we end up with a protocol that isn't compatible with itself. Conversely, if receiving of FQDNs is not a MUST (to appease the no-DNS-in-my-endpoint minority), then sending of FQDNs is a MUST NOT. Personally, I think this is a case of letting a very small portion of the tip of the tail wag the whole elephant... /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 7 18:29:51 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02454 for ; Fri, 7 Dec 2001 18:29:50 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB7NQH4I001064; Fri, 7 Dec 2001 18:26:18 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21651; Fri, 7 Dec 2001 18:28:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21640 for ; Fri, 7 Dec 2001 18:27:29 -0500 (EST) Received: from cannonat.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fB7NR7c18475; Fri, 7 Dec 2001 18:27:07 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannonat.cisco.com (Mirapoint) with ESMTP id AAF44903 (AUTH pkyzivat); Fri, 7 Dec 2001 18:28:25 -0500 (EST) Message-ID: <3C114F75.492D4C25@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: adam.roach@ericsson.com CC: Jonathan Rosenberg , "'warren montgomery'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] New I-D on IM transport References: <61D824C63B99D311975E00508B0CC98502C66CF9@eamrcnt717.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 07 Dec 2001 18:23:33 -0500 Content-Transfer-Encoding: 7bit FYI - it was draft-ietf-mmusic-sdp-new-02 and draft-ietf-mmusic-sdp-new-03 where FQDNs in the c= line were illegal. In the recently introduced draft-ietf-mmusic-sdp-new-04 they are legal again. I have no visibility into why these changes were made. Paul adam.roach@ericsson.com wrote: > > Slightly off topic, but just offering an explanation... > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > The latest versions of SDP don't permit FQDNs in the c= line. > > I never did hear why this change was made. While it often may > > be wise to > > avoid FQDNs in sdp, it seems pretty heavy handed to forbid them, since > > as you point out here there may be cases where they are useful. > > The issue as I understand it is that people want to be able to > design endpoints that do not necessarily have DNS capabilities. > I'm not going to defend this design decision. > > If sending of FQDNs is a MAY, then being able to receive them > is necessarily a MUST, lest we end up with a protocol that isn't > compatible with itself. > > Conversely, if receiving of FQDNs is not a MUST (to appease the > no-DNS-in-my-endpoint minority), then sending of FQDNs is a > MUST NOT. > > Personally, I think this is a case of letting a very small portion > of the tip of the tail wag the whole elephant... > > /a > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Dec 8 12:13:07 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01561 for ; Sat, 8 Dec 2001 12:13:07 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB8HAB4I002623; Sat, 8 Dec 2001 12:10:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24838; Sat, 8 Dec 2001 12:12:04 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19664 for ; Fri, 7 Dec 2001 11:12:06 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.195]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Dec 2001 08:11:40 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Dec 2001 08:11:40 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Dec 2001 08:11:40 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Dec 2001 08:11:39 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Fri, 7 Dec 2001 08:10:15 -0800 x-mimeole: Produced By Microsoft Exchange V6.0.6092.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] 200 vs. 202 Message-ID: Thread-Topic: [Simple] 200 vs. 202 Thread-Index: AcF/EOvnZLxycBUgRdqjRoyMRZg4TwAKKV4Q From: "Christian Huitema" To: "Brazier Lachlan" , "Paul Kyzivat " , "Jonathan Rosenberg " Cc: , "'Brian Stucker' " , "simple " X-OriginalArrivalTime: 07 Dec 2001 16:10:15.0819 (UTC) FILETIME=[A865C5B0:01C17F39] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA19664 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 7 Dec 2001 08:10:15 -0800 Content-Transfer-Encoding: 8bit So, It seems that much boils down to the expectations of the subscriber, and its ability to sort out the mess created by a forking proxy. Do we want to add a header line in SIP, such as: Fork-with-me: Don't you dare This would clearly tell proxies to not fork around... -- Christian Huitema > -----Original Message----- > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > Sent: Friday, December 07, 2001 3:14 AM > To: 'Paul Kyzivat '; 'Jonathan Rosenberg ' > Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple ' > Subject: AW: [Simple] 200 vs. 202 > > Hello, > > I believe the subscriber SHOULD keep all NOTIFY messages which arrive > before > the response to the SUBSCRIBE arives. After receiving the response the > subscriber can decide which way to handle the NOTIFY's. > > 1) Only accept NOTIFY's which fit to the response > > 2) Accept all NOTIFY's (problem with DoS? - Is it one with firewalls?) > > 3) Accept only a subset of the NOTIFY's (based on some local policy) > > If the subscriber doesn't want to wait for the response to the > SUBSCRIBE, > and NOTIFY's arrive before the response, it has the possibilities: > > 1) Accept the first NOTIFY and ignore the response > > 2) Accept all NOTIFY's and ignore the response > > 3) Accept only a subset of the NOTIFY's > > 4) Accept no NOTIFY. When the response to the SUBSCRIBE arrives, > subscribe > again, but then accept the NOTIFY from the sender from the first > SUBSCRIBE. > ( NOTE: I DON'T propose that) > > There was the proposal to accept the dialog which arrives first, be it > response or NOTIFY. > > > Did I forget another possibility? I think all of them work. Basically > all of > them depend on a kind of local policy and on the kind of application, > which > shouldn't be controlled anyway by the protocol. > > So I vote for 1) as default procedure. > > Lachlan > > > -----Originalnachricht----- > Von: Paul Kyzivat > An: Jonathan Rosenberg > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple > Gesendet: 06.12.01 22:58 > Betreff: Re: [Simple] 200 vs. 202 > > [SNIP] > > > > > Do we have consensus though? I'd like to declare this issue > resolved. > Adam's > > proposal was to accept the first NOTIFY, and ignore the 2xx. I'd > like > to > > suggest a mild variant to that that I think is even simpler. My > proposal is > > to accept whatever comes first. If you get a 2xx to SUBSCRIBE first, > that > > establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes > first, > > you accept that. Any other NOTIFY are 481'd. The 2xx to SUBSCRIBE > may > or may > > not be for the dialog that was accepted; it doesn't really matter. > > > > Agreement? > > I don't have a preference between those two alternatives. > > I won't stop progress by continuing to argue, but I don't find either > solution very appealing. > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Dec 10 22:54:27 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19636 for ; Mon, 10 Dec 2001 22:54:27 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBB3oHPr005093; Mon, 10 Dec 2001 22:50:17 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA03644; Mon, 10 Dec 2001 22:52:04 -0500 (EST) Received: from exchange1.nuera.com ([12.105.228.79]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03067 for ; Mon, 10 Dec 2001 19:46:20 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 16:48:06 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Sip] FW: [Simple] Alignment of sip-events and watcherinfo MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 10 Dec 2001 16:48:06 -0800 Hi Jonathan, > > (resend; first attempt seemed to have been garbled) > > > I'm cc'ing SIMPLE since this is a joint issue that affects both the > watcherinfo work and sip-events. Also, sip-events is a sip > work item, not > sipping, so I am changing the list to sip. > Re-adding SIMPLE after resend. > > I would like to suggest the watherinfo reason codes are > > expanded a little. > > For instance, the watcherinfo assumes that the pending states > > is waiting for > > authorization. It could however be pending while waiting for > > the subscribed > > object to become active (note: I am not referring to the > > subscribed Event > > package here). This sort of behavior may be typical/useful > > when you are > > trying to subscribe to an event that has not started yet (and > > yet you desire > > to have the subscription in place _before_ the event begins). > > OK, but in this case, the subscription itself is not pending, > its the state > of the object that is effectively "TBD". This should be > reflected in the > presence document delivered in the first NOTIFY, not in the > state of the > subscription, IMHO. I disagree. I think this is very much the concern of subscription and not the Event package. Example: If I create a subscription that is associated with a televised concert that occurs at some time in the future. When the concert finishes, obviously the subscription should also terminate, the reason for the termination is that the subscribed object has terminated. This is not an Event Package related reason. Likewise, every Event Package (e.g., my "Excessive Decibels" Monitoring Event Package) should not have to deal with understanding/reporting when the concert is valid (and why the subscription was terminated) - the package is only concerned with reporting when the audio component of the associated object exceeds a certain threshold. This argument applies equally to the pending state. I want to create a subscription to this concert before it starts so I don't miss the beginning. So the subscription is not active until the concert actually starts - once again my Decibel Monitoring Event Package has no concern for this. It is a function of the subscription itself to know when the object (and hence the subscription) is pending/active/terminated. Thus both the terminated & pending reason causes should be Subscription-Expire reasons and not solely contained in the Event package bodies themselves. > > I also think > > the rejection/termination reasons could be expanded a little more. > > Suggestions? > I made a couple in my last email (some of which you have already covered): - Terminated/rejected because authorization failed - Terminated because subscribed object terminated - Terminated because subscriber requested termination. - Expired. Subscriber did not refresh subscription. - Terminated at request of notifier. Regards, Robert. > > > > I can't see much use in including the > > event field since > > (presumably) the watcher will know what event triggered the > > NOTIFY, and if > > they can't, they can use watcherinfo to get it. > > No, these are not events of the presentity, they are events of the > subscription. These events correspond quite closely to the "reason" > parameters Adam has currently specified. In fact, for the > rejecttion events, > here is the mapping: > > sip-events watcherinfo > ---------- ----------- > migration <-> deactivated > maint <-> ? > refused <-> rejected > timeout <-> expired > ? <-> timeout > > Clearly, these should be aligned, and should be present in both the > SUbscription-Expires and the watcherinfo format. > > Its not clear to me what the semantics of maint are; should > the client retry > after some period? Presuming we can define it conciesely, we > should add it > to the watcherinfo package. > > So, here would be my proposal for the unified set: > > deactivated: subscription is terminated, but client SHOULD > retry immediately > with a new subscription. This handles migration plus other cases > potentially. > > probation: subscription is terminated; but client SHOULD > retry at some later > time (we could include a Retry-After header in the case of > presence in the > Subscription-Expires header) > > rejected: subscription terminated due to change in > authorization policy. > Retrying will not help. > > timeout: subscription terminated because it was not refreshed. > > giveup: could not obtain authorization in a timely fashion, and so the > pending subscription is being terminated. The client can > retry and will > likely get put back into pending state. > > THanks, > Jonathan R. > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 11 02:27:13 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09339 for ; Tue, 11 Dec 2001 02:27:13 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBB7NDPr005537; Tue, 11 Dec 2001 02:23:13 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04343; Tue, 11 Dec 2001 02:25:05 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04330 for ; Tue, 11 Dec 2001 02:24:42 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBB7NVB21296; Tue, 11 Dec 2001 01:23:31 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Dec 2001 01:22:19 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011D816A@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "'Fairlie-Cuninghame, Robert'" , "'Jonathan Rosenberg'" , "'sip@ietf.org'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Sip] FW: [Simple] Alignment of sip-events and watcherinfo MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18214.9AAD4CD0" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 11 Dec 2001 01:22:34 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C18214.9AAD4CD0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Monday, December 10, 2001 6:48 PM > To: 'Jonathan Rosenberg'; 'sip@ietf.org' > Cc: 'simple@mailman.dynamicsoft.com' > Subject: RE: [Sip] FW: [Simple] Alignment of sip-events and > watcherinfo > > > Hi Jonathan, > > > > > (resend; first attempt seemed to have been garbled) > > > > > > I'm cc'ing SIMPLE since this is a joint issue that affects both the > > watcherinfo work and sip-events. Also, sip-events is a sip > > work item, not > > sipping, so I am changing the list to sip. > > > > Re-adding SIMPLE after resend. > > > > I would like to suggest the watherinfo reason codes are > > > expanded a little. > > > For instance, the watcherinfo assumes that the pending states > > > is waiting for > > > authorization. It could however be pending while waiting for > > > the subscribed > > > object to become active (note: I am not referring to the > > > subscribed Event > > > package here). This sort of behavior may be typical/useful > > > when you are > > > trying to subscribe to an event that has not started yet (and > > > yet you desire > > > to have the subscription in place _before_ the event begins). > > > > OK, but in this case, the subscription itself is not pending, > > its the state > > of the object that is effectively "TBD". This should be > > reflected in the > > presence document delivered in the first NOTIFY, not in the > > state of the > > subscription, IMHO. > > I disagree. I think this is very much the concern of > subscription and not > the Event package. > > Example: If I create a subscription that is associated with a > televised > concert that occurs at some time in the future. When the > concert finishes, > obviously the subscription should also terminate, the reason for the > termination is that the subscribed object has terminated. > This is not an > Event Package related reason. Likewise, every Event Package (e.g., my > "Excessive Decibels" Monitoring Event Package) should not > have to deal with > understanding/reporting when the concert is valid (and why > the subscription > was terminated) - the package is only concerned with > reporting when the > audio component of the associated object exceeds a certain threshold. > > > This argument applies equally to the pending state. I want to create a > subscription to this concert before it starts so I don't miss > the beginning. > So the subscription is not active until the concert actually > starts - once > again my Decibel Monitoring Event Package has no concern for > this. It is a > function of the subscription itself to know when the object > (and hence the > subscription) is pending/active/terminated. > > Thus both the terminated & pending reason causes should be > Subscription-Expire reasons and not solely contained in the > Event package > bodies themselves. I would have to disagree (is there any other reason to post to this thread =). I think there's a co-mingling of terms that is going on here, either that or I've totally misunderstood what you were trying to get across. A subscription being pending or active, at least to me when I brought up my proposal to split out the subscription state from the message body about a month back, dealt completely with the actual state of the subscription, not the resource it is watching. In your scenario, even though the resource is pending (the concert hasn't started yet), the subscription to it is NOT pending. It's active. You will receive a notification when that concert begins (should that be the behavoir that the subscription was setup to handle). If the subscription were pending, meaning it had not been authorized, you would NOT get a notification that the concert started necessarily. Likewise, there's no reason that the subscription needs to be terminated explicitly either. The server processing your subscription could simply send you a final NOTIFY (the concert ended) and then dump the subscription in the bit bucket. It's not very polite, but it's allowed in the draft. Therefore, the two are distinct. This is what I was trying to avoid by suggesting that using an "Illegal" message body in the NOTIFY doesn't work well, and thus, we need a more explicit header to do the job to keep everything more understandible. A subscription can be pending to an active resource, or pending to a pending resource. The two are distinct. They are separate finite state machines, and thus should be processed separately. The state that the subscription is in has nothing at all to do with the state of the resource on a basic level. The resource may cause the subscription to be handled differently, for sure, but at a generic sip-events level, there is no coupling in my mind. Cheers, Brian > > > > I also think > > > the rejection/termination reasons could be expanded a little more. > > > > Suggestions? > > > > I made a couple in my last email (some of which you have > already covered): > > - Terminated/rejected because authorization failed > - Terminated because subscribed object terminated > - Terminated because subscriber requested termination. > - Expired. Subscriber did not refresh subscription. > - Terminated at request of notifier. > > Regards, > > Robert. > > > > > > > I can't see much use in including the > > > event field since > > > (presumably) the watcher will know what event triggered the > > > NOTIFY, and if > > > they can't, they can use watcherinfo to get it. > > > > No, these are not events of the presentity, they are events of the > > subscription. These events correspond quite closely to the "reason" > > parameters Adam has currently specified. In fact, for the > > rejecttion events, > > here is the mapping: > > > > sip-events watcherinfo > > ---------- ----------- > > migration <-> deactivated > > maint <-> ? > > refused <-> rejected > > timeout <-> expired > > ? <-> timeout > > > > Clearly, these should be aligned, and should be present in both the > > SUbscription-Expires and the watcherinfo format. > > > > Its not clear to me what the semantics of maint are; should > > the client retry > > after some period? Presuming we can define it conciesely, we > > should add it > > to the watcherinfo package. > > > > So, here would be my proposal for the unified set: > > > > deactivated: subscription is terminated, but client SHOULD > > retry immediately > > with a new subscription. This handles migration plus other cases > > potentially. > > > > probation: subscription is terminated; but client SHOULD > > retry at some later > > time (we could include a Retry-After header in the case of > > presence in the > > Subscription-Expires header) > > > > rejected: subscription terminated due to change in > > authorization policy. > > Retrying will not help. > > > > timeout: subscription terminated because it was not refreshed. > > > > giveup: could not obtain authorization in a timely fashion, > and so the > > pending subscription is being terminated. The client can > > retry and will > > likely get put back into pending state. > > > > THanks, > > Jonathan R. > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C18214.9AAD4CD0 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] FW: [Simple] Alignment of sip-events and watcherinfo

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
> Sent: Monday, December 10, 2001 6:48 PM
> To: 'Jonathan Rosenberg'; 'sip@ietf.org'
> Cc: 'simple@mailman.dynamicsoft.com'
> Subject: RE: [Sip] FW: [Simple] Alignment of sip-events and
> watcherinfo
>
>
> Hi Jonathan,
>
> >
> > (resend; first attempt seemed to have been garbled)
> >
> >
> > I'm cc'ing SIMPLE since this is a joint issue that affects both the
> > watcherinfo work and sip-events. Also, sip-events is a sip
> > work item, not
> > sipping, so I am changing the list to sip.
> > 
>
> Re-adding SIMPLE after resend.
>
> > > I would like to suggest the watherinfo reason codes are
> > > expanded a little.
> > > For instance, the watcherinfo assumes that the pending states
> > > is waiting for
> > > authorization. It could however be pending while waiting for
> > > the subscribed
> > > object to become active (note: I am not referring to the
> > > subscribed Event
> > > package here). This sort of behavior may be typical/useful
> > > when you are
> > > trying to subscribe to an event that has not started yet (and
> > > yet you desire
> > > to have the subscription in place _before_ the event begins).
> >
> > OK, but in this case, the subscription itself is not pending,
> > its the state
> > of the object that is effectively "TBD". This should be
> > reflected in the
> > presence document delivered in the first NOTIFY, not in the
> > state of the
> > subscription, IMHO.
>
> I disagree. I think this is very much the concern of
> subscription and not
> the Event package.
>
> Example: If I create a subscription that is associated with a
> televised
> concert that occurs at some time in the future. When the
> concert finishes,
> obviously the subscription should also terminate, the reason for the
> termination is that the subscribed object has terminated.
> This is not an
> Event Package related reason. Likewise, every Event Package (e.g., my
> "Excessive Decibels" Monitoring Event Package) should not
> have to deal with
> understanding/reporting when the concert is valid (and why
> the subscription
> was terminated) - the package is only concerned with
> reporting when the
> audio component of the associated object exceeds a certain threshold.
> <contrived but it will do>
>
> This argument applies equally to the pending state. I want to create a
> subscription to this concert before it starts so I don't miss
> the beginning.
> So the subscription is not active until the concert actually
> starts - once
> again my Decibel Monitoring Event Package has no concern for
> this. It is a
> function of the subscription itself to know when the object
> (and hence the
> subscription) is pending/active/terminated.
>
> Thus both the terminated & pending reason causes should be
> Subscription-Expire reasons and not solely contained in the
> Event package
> bodies themselves.

I would have to disagree (is there any other reason to post to this thread =).

I think there's a co-mingling of terms that is going on here, either that or I've totally misunderstood what you were trying to get across.

A subscription being pending or active, at least to me when I brought up my proposal to split out the subscription state from the message body about a month back, dealt completely with the actual state of the subscription, not the resource it is watching.

In your scenario, even though the resource is pending (the concert hasn't started yet), the subscription to it is NOT pending. It's active. You will receive a notification when that concert begins (should that be the behavoir that the subscription was setup to handle). If the subscription were pending, meaning it had not been authorized, you would NOT get a notification that the concert started necessarily. Likewise, there's no reason that the subscription needs to be terminated explicitly either. The server processing your subscription could simply send you a final NOTIFY (the concert ended) and then dump the subscription in the bit bucket. It's not very polite, but it's allowed in the draft.

Therefore, the two are distinct. This is what I was trying to avoid by suggesting that using an "Illegal" message body in the NOTIFY doesn't work well, and thus, we need a more explicit header to do the job to keep everything more understandible.

A subscription can be pending to an active resource, or pending to a pending resource. The two are distinct. They are separate finite state machines, and thus should be processed separately. The state that the subscription is in has nothing at all to do with the state of the resource on a basic level. The resource may cause the subscription to be handled differently, for sure, but at a generic sip-events level, there is no coupling in my mind.

Cheers,

Brian

>
> > > I also think
> > > the rejection/termination reasons could be expanded a little more.
> >
> > Suggestions?
> >
>
> I made a couple in my last email (some of which you have
> already covered):
>
>       - Terminated/rejected because authorization failed
>       - Terminated because subscribed object terminated
>       - Terminated because subscriber requested termination.
>       - Expired. Subscriber did not refresh subscription.
>       - Terminated at request of notifier.
>
> Regards,
>
> Robert.
>
> > >
> > > I can't see much use in including the
> > > event field since
> > > (presumably) the watcher will know what event triggered the
> > > NOTIFY, and if
> > > they can't, they can use watcherinfo to get it.
> >
> > No, these are not events of the presentity, they are events of the
> > subscription. These events correspond quite closely to the "reason"
> > parameters Adam has currently specified. In fact, for the
> > rejecttion events,
> > here is the mapping:
> >
> > sip-events      watcherinfo
> > ----------      -----------
> > migration  <->   deactivated
> > maint      <->    ?
> > refused    <->   rejected
> > timeout    <->   expired
> >  ?         <->   timeout
> >
> > Clearly, these should be aligned, and should be present in both the
> > SUbscription-Expires and the watcherinfo format.
> >
> > Its not clear to me what the semantics of maint are; should
> > the client retry
> > after some period? Presuming we can define it conciesely, we
> > should add it
> > to the watcherinfo package.
> >
> > So, here would be my proposal for the unified set:
> >
> > deactivated: subscription is terminated, but client SHOULD
> > retry immediately
> > with a new subscription. This handles migration plus other cases
> > potentially.
> >
> > probation: subscription is terminated; but client SHOULD
> > retry at some later
> > time (we could include a Retry-After header in the case of
> > presence in the
> > Subscription-Expires header)
> >
> > rejected: subscription terminated due to change in
> > authorization policy.
> > Retrying will not help.
> >
> > timeout: subscription terminated because it was not refreshed.
> >
> > giveup: could not obtain authorization in a timely fashion,
> and so the
> > pending subscription is being terminated. The client can
> > retry and will
> > likely get put back into pending state.
> >
> > THanks,
> > Jonathan R.
> >
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

------_=_NextPart_001_01C18214.9AAD4CD0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 12 16:31:43 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18590 for ; Wed, 12 Dec 2001 16:31:43 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBCLSAPr015207; Wed, 12 Dec 2001 16:28:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11371; Wed, 12 Dec 2001 16:30:05 -0500 (EST) Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA11358 for ; Wed, 12 Dec 2001 16:29:35 -0500 (EST) Message-ID: <20011212212908.84557.qmail@web11606.mail.yahoo.com> Received: from [12.131.201.74] by web11606.mail.yahoo.com via HTTP; Wed, 12 Dec 2001 13:29:08 PST From: Sean Olson To: simple@mailman.dynamicsoft.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Simple] Duration of URIs in application/uri-list for Presence Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 12 Dec 2001 13:29:08 -0800 (PST) Just a follow up to meeting discussion. There seemed to be consensus that there is a need to clarify the duration of validity of URIs carried in application/uri-list body of a presence NOTIFY. Since this type of payload in a NOTIFY is meant as an alert that a change has occurred without directly carrying the change in the body and since there is a desire to maintain equivalent semantics with the case where the NOTIFY *does* carry the actual presence document, I propose the following: At a default the URI list should contain a HTTP URL. This HTTP URL should be valid *at least* for one HTTP GET request. This is exactly the guarantee you have when you receive a NOTIFY with a presence payload. Any duration longer than a single HTTP fetch should be allowed but should be completely up to the implementation. /sean ===== -- Sean Olson This is from me. Assume nothing else. __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 12 18:31:49 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21171 for ; Wed, 12 Dec 2001 18:31:48 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBCNSKPr016138; Wed, 12 Dec 2001 18:28:20 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11790; Wed, 12 Dec 2001 18:30:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11777 for ; Wed, 12 Dec 2001 18:29:52 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBCNTSn06124; Wed, 12 Dec 2001 18:29:28 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG20495 (AUTH pkyzivat); Wed, 12 Dec 2001 18:30:43 -0500 (EST) Message-ID: <3C17E771.1192E5DF@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence References: <20011212212908.84557.qmail@web11606.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 12 Dec 2001 18:25:37 -0500 Content-Transfer-Encoding: 7bit Sean Olson wrote: [snip] > At a default the URI list should contain a HTTP > URL. This HTTP URL should be valid *at least* > for one HTTP GET request. This is exactly the > guarantee you have when you receive a NOTIFY > with a presence payload. Any duration longer > than a single HTTP fetch should be allowed > but should be completely up to the implementation. What if the recipient waits a few hours (or days) before issuing the GET? Must the URL still be valid? I don't think that you can reasonably mandate that it must. Can you really require much more than that the URL is valid for a GET at the time the message referencing it is sent? _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 12 18:45:03 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21503 for ; Wed, 12 Dec 2001 18:45:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBCNg5Pr016268; Wed, 12 Dec 2001 18:42:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11856; Wed, 12 Dec 2001 18:44:03 -0500 (EST) Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA11845 for ; Wed, 12 Dec 2001 18:43:46 -0500 (EST) Message-ID: <20011212234318.94855.qmail@web11608.mail.yahoo.com> Received: from [12.131.201.74] by web11608.mail.yahoo.com via HTTP; Wed, 12 Dec 2001 15:43:18 PST From: Sean Olson Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence To: Paul Kyzivat Cc: simple@mailman.dynamicsoft.com In-Reply-To: <3C17E771.1192E5DF@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 12 Dec 2001 15:43:18 -0800 (PST) Good point. The issue is how long do you keep this around after the 200 OK for the NOTIFY is received. Seconds, minutes, hours. My initial impression is to keep the state around on the web server for the duration of the subscription. In any event, couldn't this duration be communicated in the Expires: header of the NOTIFY? /sean --- Paul Kyzivat wrote: > > > Sean Olson wrote: > > [snip] > > > At a default the URI list should contain a HTTP > > URL. This HTTP URL should be valid *at least* > > for one HTTP GET request. This is exactly the > > guarantee you have when you receive a NOTIFY > > with a presence payload. Any duration longer > > than a single HTTP fetch should be allowed > > but should be completely up to the implementation. > > What if the recipient waits a few hours (or days) > before issuing the GET? Must the URL still be valid? > I don't think that you can reasonably mandate that > it > must. > > Can you really require much more than that the URL > is valid for a GET at the time the message > referencing > it is sent? ===== -- Sean Olson This is from me. Assume nothing else. __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 12 19:03:40 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21975 for ; Wed, 12 Dec 2001 19:03:40 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBD00CPr016407; Wed, 12 Dec 2001 19:00:12 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11939; Wed, 12 Dec 2001 19:02:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11928 for ; Wed, 12 Dec 2001 19:01:05 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBD00gg07294; Wed, 12 Dec 2001 19:00:42 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG20609 (AUTH pkyzivat); Wed, 12 Dec 2001 19:01:58 -0500 (EST) Message-ID: <3C17EEC4.D0A64F04@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence References: <20011212234318.94855.qmail@web11608.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 12 Dec 2001 18:56:52 -0500 Content-Transfer-Encoding: 7bit Sean, The obvious thing to do, if the web server and the presence server are sufficiently integrated, is to have the URL encode the identity of the subscription. Then when a GET is received, the then-current presence document can be returned. Nothing special need be kept that isn't already being kept by the presence server. It doesn't matter if the presence document has changed value serveral times between when the url was returned and when it is fetched. But while this is a reasonable and obvious thing to do, I don't think it ought to be mandated. Your other suggestion - to use the Expires header to convey how long the URL will remain valid is another possibility, but one that is perhaps not very useful. For instance, that duration may not be known, such as when the technique above is being used. And there is nothing to prevent returning Expires:0, which would then be accurate but not useful. Seems to me that this just has to be left to common sense and the judgment of the marketplace. Paul Sean Olson wrote: > > Good point. The issue is how long do you keep > this around after the 200 OK for the NOTIFY is > received. Seconds, minutes, hours. My initial > impression is to keep the state around on the > web server for the duration of the subscription. > In any event, couldn't this duration be communicated > in the Expires: header of the NOTIFY? _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 12 19:05:19 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22013 for ; Wed, 12 Dec 2001 19:05:18 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBD024Pr016441; Wed, 12 Dec 2001 19:02:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11965; Wed, 12 Dec 2001 19:04:03 -0500 (EST) Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id TAA11948 for ; Wed, 12 Dec 2001 19:03:12 -0500 (EST) Message-ID: <20011213000238.39018.qmail@web11603.mail.yahoo.com> Received: from [12.131.201.74] by web11603.mail.yahoo.com via HTTP; Wed, 12 Dec 2001 16:02:38 PST From: Sean Olson Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence To: Paul Kyzivat Cc: simple@mailman.dynamicsoft.com In-Reply-To: <3C17EEC4.D0A64F04@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 12 Dec 2001 16:02:38 -0800 (PST) I'm perfectly happy to leave this as an implementation detail -- that is what I argued for in the meeting. I was just trying to come up with a solution that would be reasonable to insert in the draft to satisfy those that thought it should be standardized. cheers, sean --- Paul Kyzivat wrote: > Sean, > > The obvious thing to do, if the web server and the > presence server are > sufficiently integrated, is to have the URL encode > the identity of the > subscription. Then when a GET is received, the > then-current presence > document can be returned. Nothing special need be > kept that isn't > already being kept by the presence server. It > doesn't matter if the > presence document has changed value serveral times > between when the url > was returned and when it is fetched. > > But while this is a reasonable and obvious thing to > do, I don't think it > ought to be mandated. > > Your other suggestion - to use the Expires header to > convey how long the > URL will remain valid is another possibility, but > one that is perhaps > not very useful. For instance, that duration may not > be known, such as > when the technique above is being used. And there is > nothing to prevent > returning Expires:0, which would then be accurate > but not useful. > > Seems to me that this just has to be left to common > sense and the > judgment of the marketplace. > > Paul > > Sean Olson wrote: > > > > Good point. The issue is how long do you keep > > this around after the 200 OK for the NOTIFY is > > received. Seconds, minutes, hours. My initial > > impression is to keep the state around on the > > web server for the duration of the subscription. > > In any event, couldn't this duration be > communicated > > in the Expires: header of the NOTIFY? ===== -- Sean Olson This is from me. Assume nothing else. __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Dec 13 02:38:00 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15518 for ; Thu, 13 Dec 2001 02:38:00 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBD7Y8Pr017892; Thu, 13 Dec 2001 02:34:08 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13379; Thu, 13 Dec 2001 02:36:04 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13367 for ; Thu, 13 Dec 2001 02:35:16 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBD7YVY02929; Thu, 13 Dec 2001 01:34:31 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Dec 2001 01:33:20 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011D8180@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "'Sean Olson'" , Paul Kyzivat Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C183A8.7E19A9C0" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 13 Dec 2001 01:33:43 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C183A8.7E19A9C0 Content-Type: text/plain; charset="iso-8859-1" While I can see both sides, that it's definitely an implementation detail, I also think we should go ahead (as I mentioned in the meeting) and try to come up with a reasonable expectation for the MINIMUM requirement for the URI. I could care less if someone wants to keep the document around for a day, or go off and fetch it hours later. The information is likely to be incorrect over periods of time that large. It's also true, as Paul points out very clearly, that it's pretty obvious that there need not be an actual document. The HTTP URI could point to some process that creates a new copy of the document right then and there based off of stored information. So, here's a proposal... Can we all agree that it's a reasonable expectation that a request URI be valid for AT LEAST: 1. Some trivial interval, say 90 seconds as a starting point, but that it is somehow conveyed to the user how long to expect that URL to be good for. 2. The next NOTIFY for that subscription. The reason I bring this up is so we don't have implementations running around that assume that the client is going to instantly try to fetch that URL all the time, and so client devices have enough information to know how long they can reasonably postpone fetching the document if they're up to something else when they receive the notification (like a phone call on a narrowband link). Another reason I bring this up, is so we don't have to worry about overlapping HTTP addresses where we wind up with two possible outstanding URLs sitting out there. Simply put, we're limiting and directing, in a very flexible manner what sort of behavoir to expect out of the client and the server in order to interoperate correctly. I am shocked at the amount of vehemence that this topic has created. I just fail to see why it's such a big deal to simply come to an agreement as to either how long is reasonable for a client to expect a server to keep a document around if it doesn't tell the client explicitly, or to otherwise tell the client so it doesn't make a bad assumption. I wish someone that feels strongly that this shouldn't be specified, or that a mechanism for communicating the interval of reason shouldn't be specified, would explain their discomfort beyond simply saying "that's an implementation detail". It's an interop detail, and to me that puts it into the realm of what should be specified. Cheers, Brian Stucker > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Wednesday, December 12, 2001 6:03 PM > To: Paul Kyzivat > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Duration of URIs in application/uri-list for > Presence > > > I'm perfectly happy to leave this as an implementation > detail -- that is what I argued for in the meeting. > I was just trying to come up with a solution that > would be reasonable to insert in the draft to > satisfy those that thought it should be standardized. > cheers, > sean > > --- Paul Kyzivat wrote: > > Sean, > > > > The obvious thing to do, if the web server and the > > presence server are > > sufficiently integrated, is to have the URL encode > > the identity of the > > subscription. Then when a GET is received, the > > then-current presence > > document can be returned. Nothing special need be > > kept that isn't > > already being kept by the presence server. It > > doesn't matter if the > > presence document has changed value serveral times > > between when the url > > was returned and when it is fetched. > > > > But while this is a reasonable and obvious thing to > > do, I don't think it > > ought to be mandated. > > > > Your other suggestion - to use the Expires header to > > convey how long the > > URL will remain valid is another possibility, but > > one that is perhaps > > not very useful. For instance, that duration may not > > be known, such as > > when the technique above is being used. And there is > > nothing to prevent > > returning Expires:0, which would then be accurate > > but not useful. > > > > Seems to me that this just has to be left to common > > sense and the > > judgment of the marketplace. > > > > Paul > > > > Sean Olson wrote: > > > > > > Good point. The issue is how long do you keep > > > this around after the 200 OK for the NOTIFY is > > > received. Seconds, minutes, hours. My initial > > > impression is to keep the state around on the > > > web server for the duration of the subscription. > > > In any event, couldn't this duration be > > communicated > > > in the Expires: header of the NOTIFY? > > > ===== > -- > Sean Olson > This is from me. Assume nothing else. > > __________________________________________________ > Do You Yahoo!? > Check out Yahoo! Shopping and Yahoo! Auctions for all of > your unique holiday gifts! Buy at http://shopping.yahoo.com > or bid at http://auctions.yahoo.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C183A8.7E19A9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Duration of URIs in application/uri-list for = Presence

While I can see both sides, that it's definitely an = implementation detail, I also think we should go ahead (as I mentioned = in the meeting) and try to come up with a reasonable expectation for = the MINIMUM requirement for the URI.

I could care less if someone wants to keep the = document around for a day, or go off and fetch it hours later. The = information is likely to be incorrect over periods of time that = large.

It's also true, as Paul points out very clearly, that = it's pretty obvious that there need not be an actual document. The HTTP = URI could point to some process that creates a new copy of the document = right then and there based off of stored information.

So, here's a proposal...

Can we all agree that it's a reasonable expectation = that a request URI be valid for AT LEAST:

1. Some trivial interval, say 90 seconds as a = starting point, but that it is somehow conveyed to the user how long to = expect that URL to be good for.

2. The next NOTIFY for that subscription.

The reason I bring this up is so we don't have = implementations running around that assume that the client is going to = instantly try to fetch that URL all the time, and so client devices = have enough information to know how long they can reasonably postpone = fetching the document if they're up to something else when they receive = the notification (like a phone call on a narrowband link). Another = reason I bring this up, is so we don't have to worry about overlapping = HTTP addresses where we wind up with two possible outstanding URLs = sitting out there. Simply put, we're limiting and directing, in a very = flexible manner what sort of behavoir to expect out of the client and = the server in order to interoperate correctly.

I am shocked at the amount of vehemence that this = topic has created. I just fail to see why it's such a big deal to = simply come to an agreement as to either how long is reasonable for a = client to expect a server to keep a document around if it doesn't tell = the client explicitly, or to otherwise tell the client so it doesn't = make a bad assumption.

I wish someone that feels strongly that this = shouldn't be specified, or that a mechanism for communicating the = interval of reason shouldn't be specified, would explain their = discomfort beyond simply saying "that's an implementation = detail". It's an interop detail, and to me that puts it into the = realm of what should be specified.

Cheers,

Brian Stucker

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Wednesday, December 12, 2001 6:03 = PM
> To: Paul Kyzivat
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Duration of URIs in = application/uri-list for
> Presence
>
>
> I'm perfectly happy to leave this as an = implementation
> detail -- that is what I argued for in the = meeting.
> I was just trying to come up with a solution = that
> would be reasonable to insert in the draft = to
> satisfy those that thought it should be = standardized.
> cheers,
> sean
>
> --- Paul Kyzivat <pkyzivat@cisco.com> = wrote:
> > Sean,
> >
> > The obvious thing to do, if the web server = and the
> > presence server are
> > sufficiently integrated, is to have the = URL encode
> > the identity of the
> > subscription. Then when a GET is received, = the
> > then-current presence
> > document can be returned. Nothing special = need be
> > kept that isn't
> > already being kept by the presence server. = It
> > doesn't matter if the
> > presence document has changed value = serveral times
> > between when the url
> > was returned and when it is = fetched.
> >
> > But while this is a reasonable and obvious = thing to
> > do, I don't think it
> > ought to be mandated.
> >
> > Your other suggestion - to use the Expires = header to
> > convey how long the
> > URL will remain valid is another = possibility, but
> > one that is perhaps
> > not very useful. For instance, that = duration may not
> > be known, such as
> > when the technique above is being used. = And there is
> > nothing to prevent
> > returning Expires:0, which would then be = accurate
> > but not useful.
> >
> > Seems to me that this just has to be left = to common
> > sense and the
> > judgment of the marketplace.
> >
> >     Paul
> >
> > Sean Olson wrote:
> > >
> > > Good point. The issue is how long do = you keep
> > > this around after the 200 OK for the = NOTIFY is
> > > received. Seconds, minutes, hours. My = initial
> > > impression is to keep the state = around on the
> > > web server for the duration of the = subscription.
> > > In any event, couldn't this duration = be
> > communicated
> > > in the Expires: header of the = NOTIFY?
>
>
> =3D=3D=3D=3D=3D
> --
> Sean Olson <seancolson@yahoo.com>
> This is from me. Assume nothing else.
>
> = __________________________________________________
> Do You Yahoo!?
> Check out Yahoo! Shopping and Yahoo! Auctions = for all of
> your unique holiday gifts! Buy at http://shopping.yah= oo.com
> or bid at http://auctions.yahoo.com
> = _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=
>

------_=_NextPart_001_01C183A8.7E19A9C0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Dec 13 03:28:15 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18500 for ; Thu, 13 Dec 2001 03:28:15 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBD8P5Pr018046; Thu, 13 Dec 2001 03:25:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13565; Thu, 13 Dec 2001 03:27:04 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13552 for ; Thu, 13 Dec 2001 03:26:53 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fBD8QPT13998; Thu, 13 Dec 2001 09:26:25 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id JAA20308; Thu, 13 Dec 2001 09:26:21 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xma019405; Thu, 13 Dec 01 09:24:46 +0100 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Dec 2001 09:24:41 +0100 Message-ID: From: Brazier Lachlan To: "'Brian Stucker'" , "'Sean Olson'" , Paul Kyzivat Cc: simple@mailman.dynamicsoft.com Subject: AW: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA13552 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 13 Dec 2001 09:24:40 +0100 Content-Transfer-Encoding: 8bit Hello I think it needs to be specified what it means, when the URI isn't valid anymore (Reasons like broken webserver, no document, ...). When something like this happens, does the last valid presence document count? Is the subscription expired or not? It just occurs to me, I don't know what it means, when the presence document doesn't fit the format it is supposed to be. Does this touch the subscription state? Any ideas? Lachlan -----Ursprüngliche Nachricht----- Von: Brian Stucker [mailto:bstucker@nortelnetworks.com] Gesendet am: Donnerstag, 13. Dezember 2001 08:34 An: 'Sean Olson'; Paul Kyzivat Cc: simple@mailman.dynamicsoft.com Betreff: RE: [Simple] Duration of URIs in application/uri-list for Presenc e While I can see both sides, that it's definitely an implementation detail, I also think we should go ahead (as I mentioned in the meeting) and try to come up with a reasonable expectation for the MINIMUM requirement for the URI. I could care less if someone wants to keep the document around for a day, or go off and fetch it hours later. The information is likely to be incorrect over periods of time that large. It's also true, as Paul points out very clearly, that it's pretty obvious that there need not be an actual document. The HTTP URI could point to some process that creates a new copy of the document right then and there based off of stored information. So, here's a proposal... Can we all agree that it's a reasonable expectation that a request URI be valid for AT LEAST: 1. Some trivial interval, say 90 seconds as a starting point, but that it is somehow conveyed to the user how long to expect that URL to be good for. 2. The next NOTIFY for that subscription. The reason I bring this up is so we don't have implementations running around that assume that the client is going to instantly try to fetch that URL all the time, and so client devices have enough information to know how long they can reasonably postpone fetching the document if they're up to something else when they receive the notification (like a phone call on a narrowband link). Another reason I bring this up, is so we don't have to worry about overlapping HTTP addresses where we wind up with two possible outstanding URLs sitting out there. Simply put, we're limiting and directing, in a very flexible manner what sort of behavoir to expect out of the client and the server in order to interoperate correctly. I am shocked at the amount of vehemence that this topic has created. I just fail to see why it's such a big deal to simply come to an agreement as to either how long is reasonable for a client to expect a server to keep a document around if it doesn't tell the client explicitly, or to otherwise tell the client so it doesn't make a bad assumption. I wish someone that feels strongly that this shouldn't be specified, or that a mechanism for communicating the interval of reason shouldn't be specified, would explain their discomfort beyond simply saying "that's an implementation detail". It's an interop detail, and to me that puts it into the realm of what should be specified. Cheers, Brian Stucker [DELETE] _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Dec 13 03:48:04 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18632 for ; Thu, 13 Dec 2001 03:48:04 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBD8d5Pr018148; Thu, 13 Dec 2001 03:39:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13653; Thu, 13 Dec 2001 03:41:04 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13642 for ; Thu, 13 Dec 2001 03:40:47 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBD8YpY03776; Thu, 13 Dec 2001 02:34:51 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Dec 2001 02:33:40 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011D8184@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "'Brazier Lachlan'" , "'Sean Olson'" , Paul Kyzivat Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C183B0.EB5E67C0" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 13 Dec 2001 02:34:02 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C183B0.EB5E67C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good questions. I would argue that if the presence document cannot be retrieved via the URL, that it does not affect the subscription. It = would be analogous to being sent a malformed CPIM-PIDF document in the NOTIFY = itself in my mind. As far as the SIP Events portion of things are concerned, the duty of = the sip event draft was completed when the URI was given to the client, and = what happens with that URI afterwards has no bearing on the subscription = itself. Regards, Brian > -----Original Message----- > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > Sent: Thursday, December 13, 2001 2:25 AM > To: Stucker, Brian [NGB:B635:EXCH]; 'Sean Olson'; Paul Kyzivat > Cc: simple@mailman.dynamicsoft.com > Subject: AW: [Simple] Duration of URIs in application/uri-list for > Presenc e >=20 >=20 > Hello >=20 > I think it needs to be specified what it means, when the URI=20 > isn't valid > anymore (Reasons like broken webserver, > no document, ...). >=20 > When something like this happens, does the last valid=20 > presence document > count? Is the subscription expired or not?=20 >=20 > It just occurs to me, I don't know what it means, when the=20 > presence document > doesn't fit the format it is supposed to be. > Does this touch the subscription state? >=20 > Any ideas? >=20 > Lachlan >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Brian Stucker [mailto:bstucker@nortelnetworks.com] > Gesendet am: Donnerstag, 13. Dezember 2001 08:34 > An: 'Sean Olson'; Paul Kyzivat > Cc: simple@mailman.dynamicsoft.com > Betreff: RE: [Simple] Duration of URIs in=20 > application/uri-list for Presenc e >=20 >=20 > While I can see both sides, that it's definitely an=20 > implementation detail, I > also think we should go ahead (as I mentioned in the meeting)=20 > and try to > come up with a reasonable expectation for the MINIMUM=20 > requirement for the > URI. > I could care less if someone wants to keep the document=20 > around for a day, or > go off and fetch it hours later. The information is likely to=20 > be incorrect > over periods of time that large. > It's also true, as Paul points out very clearly, that it's=20 > pretty obvious > that there need not be an actual document. The HTTP URI could=20 > point to some > process that creates a new copy of the document right then=20 > and there based > off of stored information.=20 > So, here's a proposal...=20 > Can we all agree that it's a reasonable expectation that a=20 > request URI be > valid for AT LEAST:=20 > 1. Some trivial interval, say 90 seconds as a starting point,=20 > but that it is > somehow conveyed to the user how long to expect that URL to=20 > be good for. > 2. The next NOTIFY for that subscription.=20 > The reason I bring this up is so we don't have implementations = running > around that assume that the client is going to instantly try=20 > to fetch that > URL all the time, and so client devices have enough=20 > information to know how > long they can reasonably postpone fetching the document if=20 > they're up to > something else when they receive the notification (like a=20 > phone call on a > narrowband link). Another reason I bring this up, is so we=20 > don't have to > worry about overlapping HTTP addresses where we wind up with=20 > two possible > outstanding URLs sitting out there. Simply put, we're limiting and > directing, in a very flexible manner what sort of behavoir to=20 > expect out of > the client and the server in order to interoperate correctly. > I am shocked at the amount of vehemence that this topic has=20 > created. I just > fail to see why it's such a big deal to simply come to an=20 > agreement as to > either how long is reasonable for a client to expect a server=20 > to keep a > document around if it doesn't tell the client explicitly, or=20 > to otherwise > tell the client so it doesn't make a bad assumption. > I wish someone that feels strongly that this shouldn't be=20 > specified, or that > a mechanism for communicating the interval of reason=20 > shouldn't be specified, > would explain their discomfort beyond simply saying "that's an > implementation detail". It's an interop detail, and to me=20 > that puts it into > the realm of what should be specified. > Cheers,=20 > Brian Stucker=20 >=20 > [DELETE] >=20 ------_=_NextPart_001_01C183B0.EB5E67C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Duration of URIs in application/uri-list for = Presenc e

Good questions. I would argue that if the presence = document cannot be retrieved via the URL, that it does not affect the = subscription. It would be analogous to being sent a malformed CPIM-PIDF = document in the NOTIFY itself in my mind.

As far as the SIP Events portion of things are = concerned, the duty of the sip event draft was completed when the URI = was given to the client, and what happens with that URI afterwards has = no bearing on the subscription itself.

Regards,

Brian

> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemen= s.at]
> Sent: Thursday, December 13, 2001 2:25 = AM
> To: Stucker, Brian [NGB:B635:EXCH]; 'Sean = Olson'; Paul Kyzivat
> Cc: simple@mailman.dynamicsoft.com
> Subject: AW: [Simple] Duration of URIs in = application/uri-list for
> Presenc e
>
>
> Hello
>
> I think it needs to be specified what it means, = when the URI
> isn't valid
> anymore (Reasons like broken webserver,
> no document, ...).
>
> When something like this happens, does the last = valid
> presence document
> count? Is the subscription expired or not? =
>
> It just occurs to me, I don't know what it = means, when the
> presence document
> doesn't fit the format it is supposed to = be.
> Does this touch the subscription state?
>
> Any ideas?
>
> Lachlan
>
>
> -----Urspr=FCngliche Nachricht-----
> Von: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
> Gesendet am: Donnerstag, 13. Dezember 2001 = 08:34
> An: 'Sean Olson'; Paul Kyzivat
> Cc: simple@mailman.dynamicsoft.com
> Betreff: RE: [Simple] Duration of URIs in =
> application/uri-list for Presenc e
>
>
> While I can see both sides, that it's = definitely an
> implementation detail, I
> also think we should go ahead (as I mentioned = in the meeting)
> and try to
> come up with a reasonable expectation for the = MINIMUM
> requirement for the
> URI.
> I could care less if someone wants to keep the = document
> around for a day, or
> go off and fetch it hours later. The = information is likely to
> be incorrect
> over periods of time that large.
> It's also true, as Paul points out very = clearly, that it's
> pretty obvious
> that there need not be an actual document. The = HTTP URI could
> point to some
> process that creates a new copy of the document = right then
> and there based
> off of stored information.
> So, here's a proposal...
> Can we all agree that it's a reasonable = expectation that a
> request URI be
> valid for AT LEAST:
> 1. Some trivial interval, say 90 seconds as a = starting point,
> but that it is
> somehow conveyed to the user how long to expect = that URL to
> be good for.
> 2. The next NOTIFY for that subscription. =
> The reason I bring this up is so we don't have = implementations running
> around that assume that the client is going to = instantly try
> to fetch that
> URL all the time, and so client devices have = enough
> information to know how
> long they can reasonably postpone fetching the = document if
> they're up to
> something else when they receive the = notification (like a
> phone call on a
> narrowband link). Another reason I bring this = up, is so we
> don't have to
> worry about overlapping HTTP addresses where we = wind up with
> two possible
> outstanding URLs sitting out there. Simply put, = we're limiting and
> directing, in a very flexible manner what sort = of behavoir to
> expect out of
> the client and the server in order to = interoperate correctly.
> I am shocked at the amount of vehemence that = this topic has
> created. I just
> fail to see why it's such a big deal to simply = come to an
> agreement as to
> either how long is reasonable for a client to = expect a server
> to keep a
> document around if it doesn't tell the client = explicitly, or
> to otherwise
> tell the client so it doesn't make a bad = assumption.
> I wish someone that feels strongly that this = shouldn't be
> specified, or that
> a mechanism for communicating the interval of = reason
> shouldn't be specified,
> would explain their discomfort beyond simply = saying "that's an
> implementation detail". It's an interop = detail, and to me
> that puts it into
> the realm of what should be specified.
> Cheers,
> Brian Stucker
>
> [DELETE]
>

------_=_NextPart_001_01C183B0.EB5E67C0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Dec 13 12:00:18 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23994 for ; Thu, 13 Dec 2001 12:00:18 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBDGu8Pr020060; Thu, 13 Dec 2001 11:56:08 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15195; Thu, 13 Dec 2001 11:58:04 -0500 (EST) Received: from localhost.localdomain (143-201-131-12.bellhead.com [12.131.201.143]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15183 for ; Thu, 13 Dec 2001 11:57:15 -0500 (EST) Received: from rocinante (rocinante [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fBDGoMI02390; Thu, 13 Dec 2001 10:50:22 -0600 Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence From: Ben Campbell To: Paul Kyzivat Cc: Sean Olson , simple@mailman.dynamicsoft.com In-Reply-To: <3C17EEC4.D0A64F04@cisco.com> References: <20011212234318.94855.qmail@web11608.mail.yahoo.com> <3C17EEC4.D0A64F04@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Message-Id: <1008262222.1939.8.camel@rocinante> Mime-Version: 1.0 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 13 Dec 2001 10:50:22 -0600 Content-Transfer-Encoding: 7bit On Wed, 2001-12-12 at 17:56, Paul Kyzivat wrote: > Sean, > > The obvious thing to do, if the web server and the presence server are > sufficiently integrated, is to have the URL encode the identity of the > subscription. Then when a GET is received, the then-current presence > document can be returned. Nothing special need be kept that isn't > already being kept by the presence server. It doesn't matter if the > presence document has changed value serveral times between when the url > was returned and when it is fetched. > > But while this is a reasonable and obvious thing to do, I don't think it > ought to be mandated. > > Your other suggestion - to use the Expires header to convey how long the > URL will remain valid is another possibility, but one that is perhaps > not very useful. For instance, that duration may not be known, such as > when the technique above is being used. And there is nothing to prevent > returning Expires:0, which would then be accurate but not useful. How is that different from a normal presence expiration? One assumes that if the presence state changes before I get around to getting the data, I would get a new notify if I am still subscribed. > > Seems to me that this just has to be left to common sense and the > judgment of the marketplace. > > Paul > > Sean Olson wrote: > > > > Good point. The issue is how long do you keep > > this around after the 200 OK for the NOTIFY is > > received. Seconds, minutes, hours. My initial > > impression is to keep the state around on the > > web server for the duration of the subscription. > > In any event, couldn't this duration be communicated > > in the Expires: header of the NOTIFY? > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Dec 13 12:20:23 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24496 for ; Thu, 13 Dec 2001 12:20:23 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBDHC3Pr020313; Thu, 13 Dec 2001 12:12:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15287; Thu, 13 Dec 2001 12:14:03 -0500 (EST) Received: from localhost.localdomain (143-201-131-12.bellhead.com [12.131.201.143]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15276 for ; Thu, 13 Dec 2001 12:13:34 -0500 (EST) Received: from rocinante (rocinante [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fBDGtYI02404; Thu, 13 Dec 2001 10:55:35 -0600 Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e From: Ben Campbell To: Brian Stucker Cc: "'Sean Olson'" , Paul Kyzivat , simple@mailman.dynamicsoft.com In-Reply-To: <933FADF5E673D411B8A30002A5608A0E011D8180@zrc2c012.us.nortel.com> References: <933FADF5E673D411B8A30002A5608A0E011D8180@zrc2c012.us.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Message-Id: <1008262535.1939.10.camel@rocinante> Mime-Version: 1.0 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 13 Dec 2001 10:55:34 -0600 Content-Transfer-Encoding: 7bit On Thu, 2001-12-13 at 01:33, Brian Stucker wrote: > While I can see both sides, that it's definitely an implementation > detail, I also think we should go ahead (as I mentioned in the meeting) > and try to come up with a reasonable expectation for the MINIMUM > requirement for the URI. > > I could care less if someone wants to keep the document around for a > day, or go off and fetch it hours later. The information is likely to be > incorrect over periods of time that large. > > It's also true, as Paul points out very clearly, that it's pretty > obvious that there need not be an actual document. The HTTP URI could > point to some process that creates a new copy of the document right then > and there based off of stored information. > > So, here's a proposal... > > Can we all agree that it's a reasonable expectation that a request URI > be valid for AT LEAST: > > 1. Some trivial interval, say 90 seconds as a starting point, but that > it is somehow conveyed to the user how long to expect that URL to be > good for. I am not sure that specifying X seconds is really any different than expecting an instant get, for any value of X. I do think using the Expires header makes sense, though, which is sort of a variation. > > 2. The next NOTIFY for that subscription. I have no problem with that, when combined with the Expires header. I would also propose subscription termination as another limit for URL freshness. > > The reason I bring this up is so we don't have implementations running > around that assume that the client is going to instantly try to fetch > that URL all the time, and so client devices have enough information to > know how long they can reasonably postpone fetching the document if > they're up to something else when they receive the notification (like a > phone call on a narrowband link). Another reason I bring this up, is so > we don't have to worry about overlapping HTTP addresses where we wind up > with two possible outstanding URLs sitting out there. Simply put, we're > limiting and directing, in a very flexible manner what sort of behavoir > to expect out of the client and the server in order to interoperate > correctly. > > I am shocked at the amount of vehemence that this topic has created. I > just fail to see why it's such a big deal to simply come to an agreement > as to either how long is reasonable for a client to expect a server to > keep a document around if it doesn't tell the client explicitly, or to > otherwise tell the client so it doesn't make a bad assumption. > > I wish someone that feels strongly that this shouldn't be specified, or > that a mechanism for communicating the interval of reason shouldn't be > specified, would explain their discomfort beyond simply saying "that's > an implementation detail". It's an interop detail, and to me that puts > it into the realm of what should be specified. > > Cheers, > > Brian Stucker > > > -----Original Message----- > > From: Sean Olson [ mailto:seancolson@yahoo.com > ] > > Sent: Wednesday, December 12, 2001 6:03 PM > > To: Paul Kyzivat > > Cc: simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] Duration of URIs in application/uri-list for > > Presence > > > > > > I'm perfectly happy to leave this as an implementation > > detail -- that is what I argued for in the meeting. > > I was just trying to come up with a solution that > > would be reasonable to insert in the draft to > > satisfy those that thought it should be standardized. > > cheers, > > sean > > > > --- Paul Kyzivat wrote: > > > Sean, > > > > > > The obvious thing to do, if the web server and the > > > presence server are > > > sufficiently integrated, is to have the URL encode > > > the identity of the > > > subscription. Then when a GET is received, the > > > then-current presence > > > document can be returned. Nothing special need be > > > kept that isn't > > > already being kept by the presence server. It > > > doesn't matter if the > > > presence document has changed value serveral times > > > between when the url > > > was returned and when it is fetched. > > > > > > But while this is a reasonable and obvious thing to > > > do, I don't think it > > > ought to be mandated. > > > > > > Your other suggestion - to use the Expires header to > > > convey how long the > > > URL will remain valid is another possibility, but > > > one that is perhaps > > > not very useful. For instance, that duration may not > > > be known, such as > > > when the technique above is being used. And there is > > > nothing to prevent > > > returning Expires:0, which would then be accurate > > > but not useful. > > > > > > Seems to me that this just has to be left to common > > > sense and the > > > judgment of the marketplace. > > > > > > Paul > > > > > > Sean Olson wrote: > > > > > > > > Good point. The issue is how long do you keep > > > > this around after the 200 OK for the NOTIFY is > > > > received. Seconds, minutes, hours. My initial > > > > impression is to keep the state around on the > > > > web server for the duration of the subscription. > > > > In any event, couldn't this duration be > > > communicated > > > > in the Expires: header of the NOTIFY? > > > > > > ===== > > -- > > Sean Olson > > This is from me. Assume nothing else. > > > > __________________________________________________ > > Do You Yahoo!? > > Check out Yahoo! Shopping and Yahoo! Auctions for all of > > your unique holiday gifts! Buy at http://shopping.yahoo.com > > > or bid at http://auctions.yahoo.com > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Dec 13 13:26:41 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26041 for ; Thu, 13 Dec 2001 13:26:41 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBDIN5Pr020859; Thu, 13 Dec 2001 13:23:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15528; Thu, 13 Dec 2001 13:25:05 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15514 for ; Thu, 13 Dec 2001 13:24:05 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBDINhx18757; Thu, 13 Dec 2001 13:23:43 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG25921 (AUTH pkyzivat); Thu, 13 Dec 2001 13:24:59 -0500 (EST) Message-ID: <3C18F146.AE28C2F8@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: Sean Olson , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence References: <20011212234318.94855.qmail@web11608.mail.yahoo.com> <3C17EEC4.D0A64F04@cisco.com> <1008262222.1939.8.camel@rocinante> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 13 Dec 2001 13:19:50 -0500 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > On Wed, 2001-12-12 at 17:56, Paul Kyzivat wrote: > > > > Your other suggestion - to use the Expires header to convey how long the > > URL will remain valid is another possibility, but one that is perhaps > > not very useful. For instance, that duration may not be known, such as > > when the technique above is being used. And there is nothing to prevent > > returning Expires:0, which would then be accurate but not useful. > > How is that different from a normal presence expiration? One assumes > that if the presence state changes before I get around to getting the > data, I would get a new notify if I am still subscribed. Perhaps it isn't different, but it depends on how you interpret the Expires header. In a NOTIFY there is a difference between Expires and Subscription-Expires. Expires applies to the specific notification. If you interpret Expires for something like MESSAGE, it presumably says something about how long the message content is meaningful. This is probably independent of any other messages that you might subsequently receive. So if I send you a message asking if you want to go to lunch today, I can set the expiration to the time I intend to leave for lunch. I can then send you other unrelated messages with different expirations, but they leave my lunch invitation unaffected. With the presence notification however, when sending it I in general don't know how long it will be valid. Generally it will be valid until I send another one. I could include an Expires header with the same value as Subscription-Expires, and that would be correct if there are no further changes until expiration. But it will be rendered incorrect as soon as I send out a revised notification. So at the least, expires values for notifications need to be taken with a grain of salt. Old ones need to be discarded when new ones are received, even if the old one has not yet expired. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Dec 13 13:41:07 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26504 for ; Thu, 13 Dec 2001 13:41:07 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBDIY3Pr020977; Thu, 13 Dec 2001 13:34:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15580; Thu, 13 Dec 2001 13:36:04 -0500 (EST) Received: from localhost.localdomain (143-201-131-12.bellhead.com [12.131.201.143]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15569 for ; Thu, 13 Dec 2001 13:35:36 -0500 (EST) Received: from rocinante (rocinante [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fBDITbI02866; Thu, 13 Dec 2001 12:29:37 -0600 Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence From: Ben Campbell To: Paul Kyzivat Cc: Sean Olson , simple@mailman.dynamicsoft.com In-Reply-To: <3C18F146.AE28C2F8@cisco.com> References: <20011212234318.94855.qmail@web11608.mail.yahoo.com> <3C17EEC4.D0A64F04@cisco.com> <1008262222.1939.8.camel@rocinante> <3C18F146.AE28C2F8@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Message-Id: <1008268177.1916.16.camel@rocinante> Mime-Version: 1.0 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 13 Dec 2001 12:29:37 -0600 Content-Transfer-Encoding: 7bit On Thu, 2001-12-13 at 12:19, Paul Kyzivat wrote: > > > Ben Campbell wrote: > > > > On Wed, 2001-12-12 at 17:56, Paul Kyzivat wrote: > > > > > > Your other suggestion - to use the Expires header to convey how long the > > > URL will remain valid is another possibility, but one that is perhaps > > > not very useful. For instance, that duration may not be known, such as > > > when the technique above is being used. And there is nothing to prevent > > > returning Expires:0, which would then be accurate but not useful. > > > > How is that different from a normal presence expiration? One assumes > > that if the presence state changes before I get around to getting the > > data, I would get a new notify if I am still subscribed. > > Perhaps it isn't different, but it depends on how you interpret the > Expires header. > > In a NOTIFY there is a difference between Expires and > Subscription-Expires. > Expires applies to the specific notification. > > If you interpret Expires for something like MESSAGE, it presumably says > something about how long the message content is meaningful. This is > probably independent of any other messages that you might subsequently > receive. So if I send you a message asking if you want to go to lunch > today, I can set the expiration to the time I intend to leave for lunch. > I can then send you other unrelated messages with different expirations, > but they leave my lunch invitation unaffected. > > With the presence notification however, when sending it I in general > don't know how long it will be valid. Generally it will be valid until I > send another one. I could include an Expires header with the same value > as Subscription-Expires, and that would be correct if there are no > further changes until expiration. But it will be rendered incorrect as > soon as I send out a revised notification. > > So at the least, expires values for notifications need to be taken with > a grain of salt. Old ones need to be discarded when new ones are > received, even if the old one has not yet expired. > > Paul I understand that. Expires in no way guarantees that the presence state will not change before expiration. It does, however, give you a maximum time for the presence state, that is, you should assume it is stale after expiration, unless you have received other information to the contrary. That seems to map very closely to the model for the expiration of URLs in a NOTIFY, if you say that you have a reasonable expectation of the URL being good if it has not expired and you have not received a new NOTIFY. The error scenario is when you miss a NOTIFY, but we have that exact scenario when we deliver full presence docs in the NOTIFY. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Dec 17 09:14:43 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02248 for ; Mon, 17 Dec 2001 09:14:43 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBHEBBES000990; Mon, 17 Dec 2001 09:11:12 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01140; Mon, 17 Dec 2001 09:13:08 -0500 (EST) Received: from hotsip.com ([212.28.214.249]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01127 for ; Mon, 17 Dec 2001 09:12:38 -0500 (EST) Received: from ughugh2 ([212.28.215.24]) by hotsip.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Dec 2001 15:12:04 +0100 From: "Henrik Gustafsson" To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-OriginalArrivalTime: 17 Dec 2001 14:12:04.0936 (UTC) FILETIME=[CE086480:01C18704] Subject: [Simple] Message Delivery Notification Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 17 Dec 2001 15:10:28 +0100 Content-Transfer-Encoding: 8bit The paging model for messages will probably often be used to gateway to SMS in the mobile network. Delivery notification is a very useful service in such a scenario. I would like a similar support in the SIMPLE system. This proposal is not that very thought through and I can see a number of problems already with this proposal but the initial requirement is still valid. Message Progress Notification: ------------------------------ If a MESSAGE is sent with a contact and an allow-events header: MESSAGE sip:hegu@company.com SIP/2.0 ... Allow-Events: messageprogress Contact: ;methods="NOTIFY" ... That could be an implicit subscription and later on different notifications could be sent. NOTIFY sip:hegu@host SIP/2.0 ... Event: messageprogress ... The mobile phone did not accept the message. Stored in server. Later a notification with "Message delivered.", "Message read." or "Messages transformed to SMS. The Message (400 characters) was split into 3 separate messages." could be sent. This is controversial since the message draft clearly states that contacts are not allowed in a MESSAGE. However, this contact will not be used to establish a message session. The 200-response is used to end the MESSAGE SIP transaction. If the receiving element supports the message progress event package it MAY send a notification. But you cannot depend on it. Open Issues: ------------ Is it ok to add a contact to the MESSAGE? Could an implicit subscription be used this way? How do you know that the contact is still valid when the event occurs? When does the "subscription" expire? Could different elements in the message path generate notifications? Would that be different to-tags and would that look like notifies after a forked subscribe? This message progress notifications could also be relevant in a message session ... but considering non-SIP message transport like IMTP I don’t dare to start that discussion. But today are well-known IM user agents sending events like "the other party is writing on a reply" within the message session. I have recently started writing a draft on this. I would really like some input, especially how this could be done over IMTP or should an explicit subscription be used? In the paging model I believe an implicit subscription is the way to go. /Henrik _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Dec 17 11:56:21 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10622 for ; Mon, 17 Dec 2001 11:56:20 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBHGr5ES002136; Mon, 17 Dec 2001 11:53:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01669; Mon, 17 Dec 2001 11:55:05 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01656 for ; Mon, 17 Dec 2001 11:54:08 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBHGrGF28879; Mon, 17 Dec 2001 10:53:16 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Dec 2001 10:51:50 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01334421@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Ben Campbell , Paul Kyzivat Cc: Sean Olson , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1871B.1CF612C0" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 17 Dec 2001 10:51:46 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1871B.1CF612C0 Content-Type: text/plain; charset="iso-8859-1" I agree with Ben. Although you raise good points Paul. Can we all agree to: 1. The URL is good for the interval expressed in the EXPIRES header of the notification which contained the presence document URL, or the Subscription-Expires (soon to be Subscription-State), whichever is shorter. 2. If another notification is received during the interval identified in (1), then the previous URL should be considered stale. The most recent notification always takes precedence. 3. If the subscription ends, any presence URLs associated with that subscription should be considered stale. 4. If a notify is received with an EXPIRES set to zero, the URL is considered dead-on-arrival. 5. If a notify is received without an EXPIRES header, the URL is good for the duration of the subscription. Cheers, Brian > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Thursday, December 13, 2001 12:30 PM > To: Paul Kyzivat > Cc: Sean Olson; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Duration of URIs in application/uri-list for > Presence > > > On Thu, 2001-12-13 at 12:19, Paul Kyzivat wrote: > > > > > > Ben Campbell wrote: > > > > > > On Wed, 2001-12-12 at 17:56, Paul Kyzivat wrote: > > > > > > > > Your other suggestion - to use the Expires header to > convey how long the > > > > URL will remain valid is another possibility, but one > that is perhaps > > > > not very useful. For instance, that duration may not be > known, such as > > > > when the technique above is being used. And there is > nothing to prevent > > > > returning Expires:0, which would then be accurate but > not useful. > > > > > > How is that different from a normal presence expiration? > One assumes > > > that if the presence state changes before I get around to > getting the > > > data, I would get a new notify if I am still subscribed. > > > > Perhaps it isn't different, but it depends on how you interpret the > > Expires header. > > > > In a NOTIFY there is a difference between Expires and > > Subscription-Expires. > > Expires applies to the specific notification. > > > > If you interpret Expires for something like MESSAGE, it > presumably says > > something about how long the message content is meaningful. This is > > probably independent of any other messages that you might > subsequently > > receive. So if I send you a message asking if you want to > go to lunch > > today, I can set the expiration to the time I intend to > leave for lunch. > > I can then send you other unrelated messages with different > expirations, > > but they leave my lunch invitation unaffected. > > > > With the presence notification however, when sending it I in general > > don't know how long it will be valid. Generally it will be > valid until I > > send another one. I could include an Expires header with > the same value > > as Subscription-Expires, and that would be correct if there are no > > further changes until expiration. But it will be rendered > incorrect as > > soon as I send out a revised notification. > > > > So at the least, expires values for notifications need to > be taken with > > a grain of salt. Old ones need to be discarded when new ones are > > received, even if the old one has not yet expired. > > > > Paul > > I understand that. Expires in no way guarantees that the > presence state > will not change before expiration. It does, however, give you > a maximum > time for the presence state, that is, you should assume it is stale > after expiration, unless you have received other information to the > contrary. > > That seems to map very closely to the model for the expiration of URLs > in a NOTIFY, if you say that you have a reasonable expectation of the > URL being good if it has not expired and you have not received a new > NOTIFY. The error scenario is when you miss a NOTIFY, but we have that > exact scenario when we deliver full presence docs in the NOTIFY. > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C1871B.1CF612C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Duration of URIs in application/uri-list for = Presence

I agree with Ben. Although you raise good points = Paul.

Can we all agree to:

1. The URL is good for the interval expressed in the = EXPIRES header of the notification which contained the presence = document URL, or the Subscription-Expires (soon to be = Subscription-State), whichever is shorter.

2. If another notification is received during the = interval identified in (1), then the previous URL should be considered = stale. The most recent notification always takes precedence.

3. If the subscription ends, any presence URLs = associated with that subscription should be considered stale.
4. If a notify is received with an EXPIRES set to = zero, the URL is considered dead-on-arrival.
5. If a notify is received without an EXPIRES = header, the URL is good for the duration of the subscription.

Cheers,

Brian

> -----Original Message-----
> From: Ben Campbell [mailto:bcampbell@dynamicsoft.c= om]
> Sent: Thursday, December 13, 2001 12:30 = PM
> To: Paul Kyzivat
> Cc: Sean Olson; = simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Duration of URIs in = application/uri-list for
> Presence
>
>
> On Thu, 2001-12-13 at 12:19, Paul Kyzivat = wrote:
> >
> >
> > Ben Campbell wrote:
> > >
> > > On Wed, 2001-12-12 at 17:56, Paul = Kyzivat wrote:
> > > >
> > > > Your other suggestion - to use = the Expires header to
> convey how long the
> > > > URL will remain valid is another = possibility, but one
> that is perhaps
> > > > not very useful. For instance, = that duration may not be
> known, such as
> > > > when the technique above is = being used. And there is
> nothing to prevent
> > > > returning Expires:0, which would = then be accurate but
> not useful.
> > >
> > > How is that different from a normal = presence expiration?
> One assumes
> > > that if the presence state changes = before I get around to
> getting the
> > > data, I would get a new notify if I = am still subscribed.
> >
> > Perhaps it isn't different, but it depends = on how you interpret the
> > Expires header.
> >
> > In a NOTIFY there is a difference between = Expires and
> > Subscription-Expires.
> > Expires applies to the specific = notification.
> >
> > If you interpret Expires for something = like MESSAGE, it
> presumably says
> > something about how long the message = content is meaningful. This is
> > probably independent of any other messages = that you might
> subsequently
> > receive. So if I send you a message asking = if you want to
> go to lunch
> > today, I can set the expiration to the = time I intend to
> leave for lunch.
> > I can then send you other unrelated = messages with different
> expirations,
> > but they leave my lunch invitation = unaffected.
> >
> > With the presence notification however, = when sending it I in general
> > don't know how long it will be valid. = Generally it will be
> valid until I
> > send another one. I could include an = Expires header with
> the same value
> > as Subscription-Expires, and that would be = correct if there are no
> > further changes until expiration. But it = will be rendered
> incorrect as
> > soon as I send out a revised = notification.
> >
> > So at the least, expires values for = notifications need to
> be taken with
> > a grain of salt. Old ones need to be = discarded when new ones are
> > received, even if the old one has not yet = expired.
> >
> >     Paul
>
> I understand that. Expires in no way guarantees = that the
> presence state
> will not change before expiration. It does, = however, give you
> a maximum
> time for the presence state, that is, you = should assume it is stale
> after expiration, unless you have received = other information to the
> contrary.
>
> That seems to map very closely to the model for = the expiration of URLs
> in a NOTIFY, if you say that you have a = reasonable expectation of the
> URL being good if it has not expired and you = have not received a new
> NOTIFY. The error scenario is when you miss a = NOTIFY, but we have that
> exact scenario when we deliver full presence = docs in the NOTIFY.
>
> = _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=
>

------_=_NextPart_001_01C1871B.1CF612C0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Dec 17 11:59:03 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10772 for ; Mon, 17 Dec 2001 11:58:58 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBHGu3ES002212; Mon, 17 Dec 2001 11:56:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01696; Mon, 17 Dec 2001 11:58:04 -0500 (EST) Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA01685 for ; Mon, 17 Dec 2001 11:57:35 -0500 (EST) Message-ID: <20011217165708.48004.qmail@web11606.mail.yahoo.com> Received: from [194.237.142.30] by web11606.mail.yahoo.com via HTTP; Mon, 17 Dec 2001 08:57:08 PST From: Sean Olson Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e To: Brian Stucker , Ben Campbell , Paul Kyzivat Cc: Sean Olson , simple@mailman.dynamicsoft.com In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01334421@zrc2c012.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 17 Dec 2001 08:57:08 -0800 (PST) This sounds like a very good proposal. Anything more complex would start to infringe on the implementors domain. Cheers, Sean --- Brian Stucker wrote: > I agree with Ben. Although you raise good points > Paul. > > Can we all agree to: > > 1. The URL is good for the interval expressed in the > EXPIRES header of the > notification which contained the presence document > URL, or the > Subscription-Expires (soon to be > Subscription-State), whichever is shorter. > 2. If another notification is received during the > interval identified in > (1), then the previous URL should be considered > stale. The most recent > notification always takes precedence. > 3. If the subscription ends, any presence URLs > associated with that > subscription should be considered stale. > 4. If a notify is received with an EXPIRES set to > zero, the URL is > considered dead-on-arrival. > 5. If a notify is received without an EXPIRES > header, the URL is good for > the duration of the subscription. > > Cheers, > > Brian > > > -----Original Message----- > > From: Ben Campbell > [mailto:bcampbell@dynamicsoft.com] > > Sent: Thursday, December 13, 2001 12:30 PM > > To: Paul Kyzivat > > Cc: Sean Olson; simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] Duration of URIs in > application/uri-list for > > Presence > > > > > > On Thu, 2001-12-13 at 12:19, Paul Kyzivat wrote: > > > > > > > > > Ben Campbell wrote: > > > > > > > > On Wed, 2001-12-12 at 17:56, Paul Kyzivat > wrote: > > > > > > > > > > Your other suggestion - to use the Expires > header to > > convey how long the > > > > > URL will remain valid is another > possibility, but one > > that is perhaps > > > > > not very useful. For instance, that duration > may not be > > known, such as > > > > > when the technique above is being used. And > there is > > nothing to prevent > > > > > returning Expires:0, which would then be > accurate but > > not useful. > > > > > > > > How is that different from a normal presence > expiration? > > One assumes > > > > that if the presence state changes before I > get around to > > getting the > > > > data, I would get a new notify if I am still > subscribed. > > > > > > Perhaps it isn't different, but it depends on > how you interpret the > > > Expires header. > > > > > > In a NOTIFY there is a difference between > Expires and > > > Subscription-Expires. > > > Expires applies to the specific notification. > > > > > > If you interpret Expires for something like > MESSAGE, it > > presumably says > > > something about how long the message content is > meaningful. This is > > > probably independent of any other messages that > you might > > subsequently > > > receive. So if I send you a message asking if > you want to > > go to lunch > > > today, I can set the expiration to the time I > intend to > > leave for lunch. > > > I can then send you other unrelated messages > with different > > expirations, > > > but they leave my lunch invitation unaffected. > > > > > > With the presence notification however, when > sending it I in general > > > don't know how long it will be valid. Generally > it will be > > valid until I > > > send another one. I could include an Expires > header with > > the same value > > > as Subscription-Expires, and that would be > correct if there are no > > > further changes until expiration. But it will be > rendered > > incorrect as > > > soon as I send out a revised notification. > > > > > > So at the least, expires values for > notifications need to > > be taken with > > > a grain of salt. Old ones need to be discarded > when new ones are > > > received, even if the old one has not yet > expired. > > > > > > Paul > > > > I understand that. Expires in no way guarantees > that the > > presence state > > will not change before expiration. It does, > however, give you > > a maximum > > time for the presence state, that is, you should > assume it is stale > > after expiration, unless you have received other > information to the > > contrary. > > > > That seems to map very closely to the model for > the expiration of URLs > > in a NOTIFY, if you say that you have a reasonable > expectation of the > > URL being good if it has not expired and you have > not received a new > > NOTIFY. The error scenario is when you miss a > NOTIFY, but we have that > > exact scenario when we deliver full presence docs > in the NOTIFY. > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > ===== -- Sean Olson This is from me. Assume nothing else. __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Dec 17 12:49:11 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13206 for ; Mon, 17 Dec 2001 12:49:11 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBHHk5ES002679; Mon, 17 Dec 2001 12:46:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01886; Mon, 17 Dec 2001 12:48:05 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01875 for ; Mon, 17 Dec 2001 12:47:24 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBHHl1425882; Mon, 17 Dec 2001 12:47:01 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG46482 (AUTH pkyzivat); Mon, 17 Dec 2001 12:48:16 -0500 (EST) Message-ID: <3C1E2E9C.AB1CDCCC@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Stucker CC: Ben Campbell , Sean Olson , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence References: <933FADF5E673D411B8A30002A5608A0E01334421@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 17 Dec 2001 12:42:52 -0500 Content-Transfer-Encoding: 7bit This is ok with me. Paul > Brian Stucker wrote: > > I agree with Ben. Although you raise good points Paul. > > Can we all agree to: > > 1. The URL is good for the interval expressed in the EXPIRES header of > the notification which contained the presence document URL, or the > Subscription-Expires (soon to be Subscription-State), whichever is > shorter. > > 2. If another notification is received during the interval identified > in (1), then the previous URL should be considered stale. The most > recent notification always takes precedence. > > 3. If the subscription ends, any presence URLs associated with that > subscription should be considered stale. > 4. If a notify is received with an EXPIRES set to zero, the URL is > considered dead-on-arrival. > 5. If a notify is received without an EXPIRES header, the URL is good > for the duration of the subscription. > > Cheers, > > Brian _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Dec 17 16:37:11 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19689 for ; Mon, 17 Dec 2001 16:37:11 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBHLY3ES004209; Mon, 17 Dec 2001 16:34:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02596; Mon, 17 Dec 2001 16:36:04 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02585 for ; Mon, 17 Dec 2001 16:35:26 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GOI00G01BXUFT@firewall.wcom.com> for simple@mailman.dynamicsoft.com; Mon, 17 Dec 2001 21:34:42 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GOI00G0BBXUFK@firewall.wcom.com>; Mon, 17 Dec 2001 21:34:42 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GOI00L01BXLEC@pmismtp01.wcomnet.com>; Mon, 17 Dec 2001 21:34:41 +0000 (GMT) Received: from hsinnreich2 ([166.42.41.120]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GOI00L3CBXB32@pmismtp01.wcomnet.com>; Mon, 17 Dec 2001 21:34:28 +0000 (GMT) From: Henry Sinnreich To: Jonathan Rosenberg DynamicSoft , simple@mailman.dynamicsoft.com, jon.peterson@neustar.com, rsparks@dynamicsoft.com, "'Allison Mankin'" Message-id: <000201c18742$96f16bc0$6801a8c0@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3311 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [Simple] SIPPING discussion at the 52 IETF Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 17 Dec 2001 15:34:16 -0600 Content-Transfer-Encoding: 7bit Would like to correct what I said at the discussion about the architecture presentation by Allison Mankin and Jon Peterson and also about the question on the draft "SIP Instant Message Sessions" : Both the architecture presentation and the draft of SIP session mode go very well together and make a lot of sense. The session mode for SIP IM actually meets a significant market pull. Thanks, Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Dec 17 16:49:04 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19910 for ; Mon, 17 Dec 2001 16:49:04 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBHLk3ES004365; Mon, 17 Dec 2001 16:46:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02649; Mon, 17 Dec 2001 16:48:04 -0500 (EST) Received: from hotsip.com ([212.28.214.249]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02638 for ; Mon, 17 Dec 2001 16:47:58 -0500 (EST) Received: from ughugh2 ([212.28.214.198]) by hotsip.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Dec 2001 22:47:22 +0100 From: "Henrik Gustafsson" To: "Robert Sparks" , Subject: RE: [Simple] Message Delivery Notification Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F338E8B9@DYN-TX-EXCH-001.dynamicsoft.com> Importance: Normal X-OriginalArrivalTime: 17 Dec 2001 21:47:22.0686 (UTC) FILETIME=[68AE3DE0:01C18744] Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 17 Dec 2001 22:45:45 +0100 Content-Transfer-Encoding: 7bit I believe this is part of the core. If we decide to not allow the contact header, the pager model MESSAGE cannot work as an implicit subscription. And getting notifications about what is happening on the other side of the dialog are something today's im users expects from an im service. Of course, that could be done by sending INFO messages in the message session invitation dialog. But the requirements for these notifications will be the same as for the messages. If we choose IMTP, should the notifications be sent over IMTP? Maybe the notifications are MESSAGE requests with a special content type. Anyway I believe it is a relevant requirement on IMTP. Personally I prefer the Allow-Events - Notify model, that gives more control. /Henrik > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, December 17, 2001 17:33 > To: 'Henrik Gustafsson'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Message Delivery Notification > > > We need to be careful not to break more new ground until > our core effort is complete. We should make sure > we aren't overly limiting MESSAGE's future extensibility. > We should think about the gateway to non-instant systems > problem you bring up to make sure we aren't boxing ourselves > in, but I don't think we should take on solving it as a group > until we're done with the basic presence and messaging efforts > (at least). > > RjS > > > -----Original Message----- > > From: Henrik Gustafsson [mailto:henrik.gustafsson@hotsip.com] > > Sent: Monday, December 17, 2001 8:10 AM > > To: simple@mailman.dynamicsoft.com > > Subject: [Simple] Message Delivery Notification > > > > > > The paging model for messages will probably often > > be used to gateway to SMS in the mobile network. > > Delivery notification is a very useful service > > in such a scenario. I would like a similar support > > in the SIMPLE system. This proposal is not that > > very thought through and I can see a number of > > problems already with this proposal but the > > initial requirement is still valid. > > > > Message Progress Notification: > > ------------------------------ > > If a MESSAGE is sent with a contact and an > > allow-events header: > > > > MESSAGE sip:hegu@company.com SIP/2.0 > > ... > > Allow-Events: messageprogress > > Contact: ;methods="NOTIFY" > > ... > > > > That could be an implicit subscription and later > > on different notifications could be sent. > > > > NOTIFY sip:hegu@host SIP/2.0 > > ... > > Event: messageprogress > > ... > > > > The mobile phone did not accept the message. > > Stored in server. > > > > Later a notification with "Message delivered.", > > "Message read." or "Messages transformed to SMS. > > The Message (400 characters) was split into 3 > > separate messages." could be sent. > > > > This is controversial since the message draft clearly > > states that contacts are not allowed in a MESSAGE. > > However, this contact will not be used to establish a > > message session. > > > > The 200-response is used to end the MESSAGE SIP > > transaction. If the receiving element supports > > the message progress event package it MAY send > > a notification. But you cannot depend on it. > > > > Open Issues: > > ------------ > > Is it ok to add a contact to the MESSAGE? Could an > > implicit subscription be used this way? How do you > > know that the contact is still valid when the event > > occurs? When does the "subscription" expire? Could > > different elements in the message path generate > > notifications? Would that be different to-tags and > > would that look like notifies after a forked > > subscribe? > > > > This message progress notifications could also be > > relevant in a message session ... but considering > > non-SIP message transport like IMTP I don't dare > > to start that discussion. But today are well-known > > IM user agents sending events like "the other party > > is writing on a reply" within the message session. > > > > I have recently started writing a draft on this. > > I would really like some input, especially how this > > could be done over IMTP or should an explicit > > subscription be used? In the paging model I believe > > an implicit subscription is the way to go. > > > > /Henrik > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 18 04:05:14 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16158 for ; Tue, 18 Dec 2001 04:05:13 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBI925ES006591; Tue, 18 Dec 2001 04:02:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04733; Tue, 18 Dec 2001 04:04:05 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04722 for ; Tue, 18 Dec 2001 04:03:42 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fBI93Cp21068; Tue, 18 Dec 2001 10:03:12 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id KAA29384; Tue, 18 Dec 2001 10:02:22 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xmab27077; Tue, 18 Dec 01 10:00:53 +0100 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 10:00:18 +0100 Message-ID: From: Brazier Lachlan To: "'Brian Stucker'" , Ben Campbell , Paul Kyzivat Cc: Sean Olson , simple@mailman.dynamicsoft.com Subject: AW: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA04722 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 10:00:16 +0100 Content-Transfer-Encoding: 8bit Sounds good. Lachlan -----Ursprüngliche Nachricht----- Von: Brian Stucker [mailto:bstucker@nortelnetworks.com] Gesendet am: Montag, 17. Dezember 2001 17:52 An: Ben Campbell; Paul Kyzivat Cc: Sean Olson; simple@mailman.dynamicsoft.com Betreff: RE: [Simple] Duration of URIs in application/uri-list for Presenc e I agree with Ben. Although you raise good points Paul. Can we all agree to: 1. The URL is good for the interval expressed in the EXPIRES header of the notification which contained the presence document URL, or the Subscription-Expires (soon to be Subscription-State), whichever is shorter. 2. If another notification is received during the interval identified in (1), then the previous URL should be considered stale. The most recent notification always takes precedence. 3. If the subscription ends, any presence URLs associated with that subscription should be considered stale. 4. If a notify is received with an EXPIRES set to zero, the URL is considered dead-on-arrival. 5. If a notify is received without an EXPIRES header, the URL is good for the duration of the subscription. Cheers, Brian _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 18 04:46:04 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16469 for ; Tue, 18 Dec 2001 04:46:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBI9h3ES006741; Tue, 18 Dec 2001 04:43:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04875; Tue, 18 Dec 2001 04:45:04 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04862 for ; Tue, 18 Dec 2001 04:44:53 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBI9gCc25355 for ; Tue, 18 Dec 2001 11:42:12 +0200 (EET) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Dec 2001 11:44:24 +0200 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 18 Dec 2001 11:44:24 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC7F@esebe013.NOE.Nokia.com> To: bstucker@nortelnetworks.com, bcampbell@dynamicsoft.com, pkyzivat@cisco.com Cc: seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 11:44:11 +0200 Hi All, > I agree with Ben. Although you raise good points Paul. > Can we all agree to: > 1. The URL is good for the interval expressed in the EXPIRES > header of the notification which contained the presence > document URL, or the Subscription-Expires (soon to be > Subscription-State), whichever is shorter. Overall, I like the sound of this proposal. However, a distinct linking like this between the Subscription-Expires and Expires assumes that subscriptions always establish a session. This assumption makes a fetch of event state impossible using the URL mechanism. > 2. If another notification is received during the interval > identified in (1), then the previous URL should be considered > stale. The most recent notification always takes precedence. > 3. If the subscription ends, any presence URLs associated > with that subscription should be considered stale. > 4. If a notify is received with an EXPIRES set to zero, the > URL is considered dead-on-arrival. > 5. If a notify is received without an EXPIRES header, the URL > is good for the duration of the subscription. Cheers, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 18 09:41:10 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19304 for ; Tue, 18 Dec 2001 09:41:09 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBIEcCES007690; Tue, 18 Dec 2001 09:38:12 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05749; Tue, 18 Dec 2001 09:40:08 -0500 (EST) Received: from web11602.mail.yahoo.com (web11602.mail.yahoo.com [216.136.172.54]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA05736 for ; Tue, 18 Dec 2001 09:39:52 -0500 (EST) Message-ID: <20011218143922.1269.qmail@web11602.mail.yahoo.com> Received: from [216.51.103.234] by web11602.mail.yahoo.com via HTTP; Tue, 18 Dec 2001 06:39:22 PST From: Sean Olson Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e To: aki.niemi@nokia.com, bstucker@nortelnetworks.com, bcampbell@dynamicsoft.com, pkyzivat@cisco.com Cc: seancolson@yahoo.com, simple@mailman.dynamicsoft.com In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC7F@esebe013.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 06:39:22 -0800 (PST) > Overall, I like the sound of this proposal. However, > a distinct linking like > this between the Subscription-Expires and Expires > assumes that subscriptions > always establish a session. For presence at least, they do. >This assumption makes a > fetch of event state > impossible using the URL mechanism. Why? /sean ===== -- Sean Olson This is from me. Assume nothing else. __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 18 10:38:06 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20151 for ; Tue, 18 Dec 2001 10:38:06 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBIFZ3ES008262; Tue, 18 Dec 2001 10:35:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05943; Tue, 18 Dec 2001 10:37:05 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05932 for ; Tue, 18 Dec 2001 10:36:39 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBIFVZF20721; Tue, 18 Dec 2001 09:31:36 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 09:30:10 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0139AB67@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Jonathan Rosenberg , aki.niemi@nokia.com Cc: bcampbell@dynamicsoft.com, pkyzivat@cisco.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C187D8.DD3AABA0" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 09:30:03 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C187D8.DD3AABA0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > aki.niemi@nokia.com wrote: > > > Hi All, > > > > > >>I agree with Ben. Although you raise good points Paul. > >>Can we all agree to: > >>1. The URL is good for the interval expressed in the EXPIRES > >>header of the notification which contained the presence > >>document URL, or the Subscription-Expires (soon to be > >>Subscription-State), whichever is shorter. > >> > > > > Overall, I like the sound of this proposal. However, a > distinct linking > > like > > this between the Subscription-Expires and Expires assumes that > > subscriptions > > always establish a session. This assumption makes a fetch > of event state > > impossible using the URL mechanism. > > > Good point. > > Why don't we simplify this, then, and state that the URL is valid for > duration in the Expires, if present, otherwise, the duration of the > subscription, and that the next NOTIFY overrides the previous > URL. This > way, if you want the URL validity to be less than the subscription > duration, you can do that (Expires < Subscription-Expires), > equal to it > (no Expires) or greater than it (Expires > Subscription-Expires). We > also say that in absense of reasons to do so otherwise, the > URL SHOULD > be valid for the duration of the subscription, and for > fetches, for some > reasonable interval, say 2 min. > > That is, we specify semantics that enable any policy, and state a > recommended baseline policy. > > -Jonathan R. > > Johnathan, that's precisely what was proposed. I don't understand the logic about the session making it impossible to fetch a URL. Just because you no longer have any state in SIP doesn't mean you can't have state somewhere else. I'd prefer we steer away from arbitrary timers. Brian ------_=_NextPart_001_01C187D8.DD3AABA0 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Duration of URIs in application/uri-list for Presenc e

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>
> aki.niemi@nokia.com wrote:
>
> > Hi All,
> >
> >
> >>I agree with Ben. Although you raise good points Paul.
> >>Can we all agree to:
> >>1. The URL is good for the interval expressed in the EXPIRES
> >>header of the notification which contained the presence
> >>document URL, or the Subscription-Expires (soon to be
> >>Subscription-State), whichever is shorter.
> >>
> >
> > Overall, I like the sound of this proposal. However, a
> distinct linking
> > like
> > this between the Subscription-Expires and Expires assumes that
> > subscriptions
> > always establish a session. This assumption makes a fetch
> of event state
> > impossible using the URL mechanism.
>
>
> Good point.
>
> Why don't we simplify this, then, and state that the URL is valid for
> duration in the Expires, if present, otherwise, the duration of the
> subscription, and that the next NOTIFY overrides the previous
> URL. This
> way, if you want the URL validity to be less than the subscription
> duration, you can do that (Expires < Subscription-Expires),
> equal to it
> (no Expires) or greater than it (Expires > Subscription-Expires). We
> also say that in absense of reasons to do so otherwise, the
> URL SHOULD
> be valid for the duration of the subscription, and for
> fetches, for some
> reasonable interval, say 2 min.
>
> That is, we specify semantics that enable any policy, and state a
> recommended baseline policy.
>
> -Jonathan R.
>
>

Johnathan, that's precisely what was proposed. I don't understand the logic about the
session making it impossible to fetch a URL. Just because you no longer have any state in SIP
doesn't mean you can't have state somewhere else. I'd prefer we steer away from arbitrary timers.

Brian

------_=_NextPart_001_01C187D8.DD3AABA0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 18 10:48:06 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20293 for ; Tue, 18 Dec 2001 10:48:06 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBIFe2ES008348; Tue, 18 Dec 2001 10:40:02 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05980; Tue, 18 Dec 2001 10:42:04 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05968 for ; Tue, 18 Dec 2001 10:41:16 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBIFdrF22636; Tue, 18 Dec 2001 09:39:53 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 09:38:28 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0139ABA2@zrc2c012.us.nortel.com> From: "Brian Stucker" To: aki.niemi@nokia.com, bcampbell@dynamicsoft.com, pkyzivat@cisco.com Cc: seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C187DA.053404C0" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 09:38:20 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C187DA.053404C0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > > Hi All, > > > I agree with Ben. Although you raise good points Paul. > > Can we all agree to: > > 1. The URL is good for the interval expressed in the EXPIRES > > header of the notification which contained the presence > > document URL, or the Subscription-Expires (soon to be > > Subscription-State), whichever is shorter. > > Overall, I like the sound of this proposal. However, a > distinct linking like > this between the Subscription-Expires and Expires assumes > that subscriptions > always establish a session. This assumption makes a fetch of > event state > impossible using the URL mechanism. > > > Cheers, > Aki > Why? All the expires is telling us to do with the URL is to direct us as to how long to cache the URL for (if it's to be cached at all). If you did a fetch, you could get a NOTIFY back with "subscription-state: terminated 0" and an "expires: 90" (or whatever). The contents of the NOTIFY would be good for 90 seconds, the subscription has terminated immediately, here's your URL. Am I missing something? Brian Stucker ------_=_NextPart_001_01C187DA.053404C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Duration of URIs in application/uri-list for = Presenc e

> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
>
>
> Hi All,
>
> > I agree with Ben. Although you raise good = points Paul.
> > Can we all agree to:
> > 1. The URL is good for the interval = expressed in the EXPIRES
> > header of the notification which contained = the presence
> > document URL, or the Subscription-Expires = (soon to be
> > Subscription-State), whichever is = shorter.
>
> Overall, I like the sound of this proposal. = However, a
> distinct linking like
> this between the Subscription-Expires and = Expires assumes
> that subscriptions
> always establish a session. This assumption = makes a fetch of
> event state
> impossible using the URL mechanism.
>
>
> Cheers,
> Aki
>

Why? All the expires is telling us to do with the URL = is to direct us as to how long to cache the URL for (if it's to be = cached at all). If you did a fetch, you could get a NOTIFY back with = "subscription-state: terminated 0" and an "expires: = 90" (or whatever). The contents of the NOTIFY would be good for 90 = seconds, the subscription has terminated immediately, here's your = URL.

Am I missing something?

Brian Stucker

------_=_NextPart_001_01C187DA.053404C0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 18 11:51:57 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21734 for ; Tue, 18 Dec 2001 11:51:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBIGh3ES009095; Tue, 18 Dec 2001 11:43:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06181; Tue, 18 Dec 2001 11:45:05 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06168 for ; Tue, 18 Dec 2001 11:44:30 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBIGi4823484; Tue, 18 Dec 2001 11:44:04 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAH01361 (AUTH pkyzivat); Tue, 18 Dec 2001 11:45:20 -0500 (EST) Message-ID: <3C1F7158.725CEB64@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Brian Stucker , aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Duration of URIs in application/uri-list for Presenc e References: <933FADF5E673D411B8A30002A5608A0E0139ABA2@zrc2c012.us.nortel.com> <3C1F6B8E.5010000@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 11:39:52 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > The original proposal was that the URL was valid until either the > Expires duration ends, or the subscription terminates, whichever happens > first. Since fetches are nothing more than subscriptions with zero > duration, this would mean that the URL would be invalidated immediately. How did you reach the conclusion stated in the last sentence above? I think one valid implementation might be that a fetch of the URL returns the same thing that a new subscription with a zero duration would return. But if so, I don't think that should affect the status of the original subscription that returned the URL, or the validity of the URL itself. Another valid (though perhaps suboptimal) implementation might be for the notification that returns a URL to actually format the notification, store it as a file, and return a URL for that file. The file might remain indefinitely, regardless of what subsequently happens to the subscription or the state of the presentity subscribed to. The rules ought to permit both sorts of implementations, and behave in a comparable way for both. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 18 15:02:08 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25547 for ; Tue, 18 Dec 2001 15:02:08 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBIJx2ES010982; Tue, 18 Dec 2001 14:59:02 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06820; Tue, 18 Dec 2001 15:01:04 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06808 for ; Tue, 18 Dec 2001 15:00:18 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBIJx3F22026; Tue, 18 Dec 2001 13:59:04 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 13:57:38 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0139B069@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Paul Kyzivat , Jonathan Rosenberg , adam.roach@ericsson.com Cc: aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C187FE.389E0E90" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 13:57:28 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C187FE.389E0E90 Content-Type: text/plain; charset="iso-8859-1" The problem is that, the wording that was given earlier meant that a fetch was not possible because the URL would only last until the subscription expired. Ahh.. Now I see it. Ok. Yes, there is a problem Aki. So the logic needs to be revised, which is what Jonathan was talking about. Now I understand. It seems that (nearly) everyone was intent on not specifying a standard interval for the URL to be good for. So, with that in mind, how about: 1. The URL is good for the interval expressed in the EXPIRES header of the notification which contained the presence document URL, or the Subscription-Expires (soon to be Subscription-State), whichever is shorter. 2. If another notification is received during the interval identified in (1), then the previous URL should be considered stale. The most recent notification always takes precedence. 3. If a persistient subscription (not a fetch) ends, any presence URLs associated with that subscription should be considered stale. 4. If a notify is received with an EXPIRES set to zero, the URL is considered dead-on-arrival. 5. If a notify is received without an EXPIRES header, the URL is good for the duration of the subscription. 6. If a notify is received due to a subscription fetch, the URL is good for the interval expressed in the EXPIRES header of the notification which contained the presence document URL. This would require that the sip-events draft change the normative language in Section 4.3.5 of the -01 draft. Adam? Cheers, Brian Stucker > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, December 18, 2001 10:40 AM > To: Jonathan Rosenberg > Cc: Stucker, Brian [NGB:B635:EXCH]; aki.niemi@nokia.com; > bcampbell@dynamicsoft.com; seancolson@yahoo.com; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Duration of URIs in application/uri-list for > Presenc e > > > > > Jonathan Rosenberg wrote: > > > > The original proposal was that the URL was valid until either the > > Expires duration ends, or the subscription terminates, > whichever happens > > first. Since fetches are nothing more than subscriptions with zero > > duration, this would mean that the URL would be invalidated > immediately. > > How did you reach the conclusion stated in the last sentence above? > > I think one valid implementation might be that a fetch of the URL > returns the same thing that a new subscription with a zero duration > would return. But if so, I don't think that should affect the > status of > the original subscription that returned the URL, or the > validity of the > URL itself. > > Another valid (though perhaps suboptimal) implementation might be for > the notification that returns a URL to actually format the > notification, > store it as a file, and return a URL for that file. The file might > remain indefinitely, regardless of what subsequently happens to the > subscription or the state of the presentity subscribed to. > > The rules ought to permit both sorts of implementations, and > behave in a > comparable way for both. > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C187FE.389E0E90 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Duration of URIs in application/uri-list for Presenc e

The problem is that, the wording that was given earlier meant that a fetch
was not possible because the URL would only last until the subscription expired.

Ahh.. Now I see it. Ok. Yes, there is a problem Aki.

So the logic needs to be revised, which is what Jonathan was talking about. Now
I understand. It seems that (nearly) everyone was intent on not specifying a
standard interval for the URL to be good for. So, with that in mind, how about:

1. The URL is good for the interval expressed in the EXPIRES
header of the notification which contained the presence
document URL, or the Subscription-Expires (soon to be
Subscription-State), whichever is shorter.

2. If another notification is received during the interval
identified in (1), then the previous URL should be considered
stale. The most recent notification always takes precedence.

3. If a persistient subscription (not a fetch) ends, any
presence URLs associated with that subscription should be considered stale.

4. If a notify is received with an EXPIRES set to zero, the
URL is considered dead-on-arrival.

5. If a notify is received without an EXPIRES header, the URL
is good for the duration of the subscription.

6. If a notify is received due to a subscription fetch, the URL
is good for the interval expressed in the EXPIRES header of the
notification which contained the presence document URL.

This would require that the sip-events draft change the normative language
in Section 4.3.5 of the -01 draft.

Adam?

Cheers,

Brian Stucker


> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, December 18, 2001 10:40 AM
> To: Jonathan Rosenberg
> Cc: Stucker, Brian [NGB:B635:EXCH]; aki.niemi@nokia.com;
> bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Duration of URIs in application/uri-list for
> Presenc e
>
>
>
>
> Jonathan Rosenberg wrote:
> >
> > The original proposal was that the URL was valid until either the
> > Expires duration ends, or the subscription terminates,
> whichever happens
> > first. Since fetches are nothing more than subscriptions with zero
> > duration, this would mean that the URL would be invalidated
> immediately.
>
> How did you reach the conclusion stated in the last sentence above?
>
> I think one valid implementation might be that a fetch of the URL
> returns the same thing that a new subscription with a zero duration
> would return. But if so, I don't think that should affect the
> status of
> the original subscription that returned the URL, or the
> validity of the
> URL itself.
>
> Another valid (though perhaps suboptimal) implementation might be for
> the notification that returns a URL to actually format the
> notification,
> store it as a file, and return a URL for that file. The file might
> remain indefinitely, regardless of what subsequently happens to the
> subscription or the state of the presentity subscribed to.
>
> The rules ought to permit both sorts of implementations, and
> behave in a
> comparable way for both.
>
>       Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

------_=_NextPart_001_01C187FE.389E0E90-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 18 15:31:08 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26235 for ; Tue, 18 Dec 2001 15:31:08 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBIKS4ES011352; Tue, 18 Dec 2001 15:28:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06924; Tue, 18 Dec 2001 15:30:05 -0500 (EST) Received: from web11601.mail.yahoo.com (web11601.mail.yahoo.com [216.136.172.53]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA06911 for ; Tue, 18 Dec 2001 15:29:45 -0500 (EST) Message-ID: <20011218202914.79284.qmail@web11601.mail.yahoo.com> Received: from [208.237.135.12] by web11601.mail.yahoo.com via HTTP; Tue, 18 Dec 2001 12:29:14 PST From: Sean Olson Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e To: Brian Stucker , Paul Kyzivat , Jonathan Rosenberg , adam.roach@ericsson.com Cc: aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com In-Reply-To: <933FADF5E673D411B8A30002A5608A0E0139B069@zrc2c012.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 12:29:14 -0800 (PST) > 1. The URL is good for the interval expressed in the > EXPIRES > header of the notification which contained the > presence > document URL, or the Subscription-Expires (soon to > be > Subscription-State), whichever is shorter. > > 2. If another notification is received during the > interval > identified in (1), then the previous URL should be > considered > stale. The most recent notification always takes > precedence. I would like this to be a "SHOULD" strength condition and not a "MUST". > > 3. If a persistient subscription (not a fetch) ends, > any > presence URLs associated with that subscription > should be considered stale. There is no need for a special case here. The text in bullet 1 covers both a "fetch" as well as a long running subscription. > > 4. If a notify is received with an EXPIRES set to > zero, the > URL is considered dead-on-arrival. This is an extremely odd case. Wouldn't an empty body be more appropriate. Can someone give a real world example of when this would be used? > > 5. If a notify is received without an EXPIRES > header, the URL > is good for the duration of the subscription. > > 6. If a notify is received due to a subscription > fetch, the URL > is good for the interval expressed in the EXPIRES > header of the > notification which contained the presence document > URL. > > This would require that the sip-events draft change > the normative language > in Section 4.3.5 of the -01 draft. > > Adam? > > Cheers, > Brian Stucker /sean ===== -- Sean Olson This is from me. Assume nothing else. __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 18 16:58:00 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27588 for ; Tue, 18 Dec 2001 16:57:59 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBILt2ES012192; Tue, 18 Dec 2001 16:55:02 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07194; Tue, 18 Dec 2001 16:57:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07183 for ; Tue, 18 Dec 2001 16:56:40 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBILuHj18425; Tue, 18 Dec 2001 16:56:17 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAH04289 (AUTH pkyzivat); Tue, 18 Dec 2001 16:57:33 -0500 (EST) Message-ID: <3C1FBA85.D150C472@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Stucker CC: Jonathan Rosenberg , adam.roach@ericsson.com, aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence References: <933FADF5E673D411B8A30002A5608A0E0139B069@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 16:52:05 -0500 Content-Transfer-Encoding: 7bit Comments below. > Brian Stucker wrote: > > The problem is that, the wording that was given earlier meant that a > fetch > was not possible because the URL would only last until the > subscription expired. > > Ahh.. Now I see it. Ok. Yes, there is a problem Aki. > > So the logic needs to be revised, which is what Jonathan was talking > about. Now > I understand. It seems that (nearly) everyone was intent on not > specifying a > standard interval for the URL to be good for. So, with that in mind, > how about: > > 1. The URL is good for the interval expressed in the EXPIRES > header of the notification which contained the presence > document URL, or the Subscription-Expires (soon to be > Subscription-State), whichever is shorter. I think this is wrong. How about: 1. If the notification which contained the presence document URL also contained an Expires header, the URL is good for the interval expressed in that header. This permits the document referenced by the URL to outlast the subscription, if that is what the notifier desired. The case where there is Subscription-Expires but not Expires is covered by 5. > > 2. If another notification is received during the interval > identified in (1), then the previous URL should be considered > stale. The most recent notification always takes precedence. > > 3. If a persistient subscription (not a fetch) ends, any > presence URLs associated with that subscription should be considered > stale. > > 4. If a notify is received with an EXPIRES set to zero, the > URL is considered dead-on-arrival. It would be stupid to do this. Since it is both stupid and a special case of 1, no need to mention. > > 5. If a notify is received without an EXPIRES header, the URL > is good for the duration of the subscription. > > 6. If a notify is received due to a subscription fetch, the URL > is good for the interval expressed in the EXPIRES header of the > notification which contained the presence document URL. I don't understand this. What do you mean by a "subscription fetch"? Does this say anything not covered by one of the other points? Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 18 18:30:03 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29407 for ; Tue, 18 Dec 2001 18:30:02 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBINR3ES012893; Tue, 18 Dec 2001 18:27:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07491; Tue, 18 Dec 2001 18:29:05 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07480 for ; Tue, 18 Dec 2001 18:28:07 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBINR0F06120; Tue, 18 Dec 2001 17:27:00 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 17:25:35 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0139B3C3@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Paul Kyzivat Cc: Jonathan Rosenberg , adam.roach@ericsson.com, aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1881B.4A848D60" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 17:25:33 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1881B.4A848D60 Content-Type: text/plain; charset="iso-8859-1" The reason I mention the fetch is because in the sip-events draft, you can have a NOTIFY with an expires of zero, and no subscription-expires (the subscription-expires is only a SHOULD, presumably to keep from deprecating implementations from the -00 draft). So, if your client KNOWS that it just did a fetch, then the problem as has been pointed out is that the NOTIFY could come back with no subscription-expires header, an Expires header set to zero (to denote that the subscription is over as there never was one), and with a presence URL (because it's a fetch). In this case the client shouldn't treat the URL as dead-on-arrival even though the NOTIFY looks just like a "stupid" dead-on-arrival notify. I think this is what Aki was getting at, and it's a good point. Either we agree to a set interval, as Jonathan has suggested (which I'm fine with), or we agree that when a URL is to be sent back in NOTIFY that was sent because of a fetch operation, that there MUST be a subscription-expires, and the expires header can't be zero. Otherwise, URLs returned as part of a fetch operation where the optional subscription-expires header isn't present would either be immediately stale (as Aki pointed out), or would be valid for an undetermined amount of time (which is what we're trying to avoid). Regards, Brian Stucker > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, December 18, 2001 3:52 PM > To: Stucker, Brian [NGB:B635:EXCH] > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; aki.niemi@nokia.com; > bcampbell@dynamicsoft.com; seancolson@yahoo.com; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Duration of URIs in application/uri-list for > Presence > > > Comments below. > > > Brian Stucker wrote: > > > > The problem is that, the wording that was given earlier meant that a > > fetch > > was not possible because the URL would only last until the > > subscription expired. > > > > Ahh.. Now I see it. Ok. Yes, there is a problem Aki. > > > > So the logic needs to be revised, which is what Jonathan was talking > > about. Now > > I understand. It seems that (nearly) everyone was intent on not > > specifying a > > standard interval for the URL to be good for. So, with that in mind, > > how about: > > > > 1. The URL is good for the interval expressed in the EXPIRES > > header of the notification which contained the presence > > document URL, or the Subscription-Expires (soon to be > > Subscription-State), whichever is shorter. > > I think this is wrong. How about: > > 1. If the notification which contained the presence document URL > also contained an Expires header, the URL is good for the interval > expressed in that header. > > This permits the document referenced by the URL to outlast > the subscription, if that is what the notifier desired. > The case where there is Subscription-Expires but not Expires > is covered by 5. > > > > > 2. If another notification is received during the interval > > identified in (1), then the previous URL should be considered > > stale. The most recent notification always takes precedence. > > > > 3. If a persistient subscription (not a fetch) ends, any > > presence URLs associated with that subscription should be considered > > stale. > > > > 4. If a notify is received with an EXPIRES set to zero, the > > URL is considered dead-on-arrival. > > It would be stupid to do this. Since it is both stupid and a > special case of 1, no need to mention. > > > > > 5. If a notify is received without an EXPIRES header, the URL > > is good for the duration of the subscription. > > > > 6. If a notify is received due to a subscription fetch, the URL > > is good for the interval expressed in the EXPIRES header of the > > notification which contained the presence document URL. > > I don't understand this. What do you mean by a "subscription fetch"? > Does this say anything not covered by one of the other points? > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C1881B.4A848D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Duration of URIs in application/uri-list for = Presence

The reason I mention the fetch is because in the = sip-events draft, you can have a NOTIFY with an expires of zero,
and no subscription-expires (the = subscription-expires is only a SHOULD, presumably to keep from = deprecating implementations from the -00 draft).

So, if your client KNOWS that it just did a fetch, = then the problem as has been pointed out is that the NOTIFY could come = back with no subscription-expires header, an Expires header set to zero = (to denote that the subscription is over as there never was one), and = with a presence URL (because it's a fetch). In this case the client = shouldn't treat the URL as dead-on-arrival even though the NOTIFY looks = just like a "stupid" dead-on-arrival notify. I think this is = what Aki was getting at, and it's a good point.

Either we agree to a set interval, as Jonathan has = suggested (which I'm fine with), or we agree that when a URL is to be = sent back in NOTIFY that was sent because of a fetch operation, that = there MUST be a subscription-expires, and the expires header can't be = zero. Otherwise, URLs returned as part of a fetch operation where the = optional subscription-expires header isn't present would either be = immediately stale (as Aki pointed out), or would be valid for an = undetermined amount of time (which is what we're trying to = avoid).

Regards,

Brian Stucker


> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=
> Sent: Tuesday, December 18, 2001 3:52 PM
> To: Stucker, Brian [NGB:B635:EXCH]
> Cc: Jonathan Rosenberg; = adam.roach@ericsson.com; aki.niemi@nokia.com;
> bcampbell@dynamicsoft.com; = seancolson@yahoo.com;
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Duration of URIs in = application/uri-list for
> Presence
>
>
> Comments below.
>
> > Brian Stucker wrote:
> >
> > The problem is that, the wording that was = given earlier meant that a
> > fetch
> > was not possible because the URL would = only last until the
> > subscription expired.
> >
> > Ahh.. Now I see it. Ok. Yes, there is a = problem Aki.
> >
> > So the logic needs to be revised, which is = what Jonathan was talking
> > about. Now
> > I understand. It seems that (nearly) = everyone was intent on not
> > specifying a
> > standard interval for the URL to be good = for. So, with that in mind,
> > how about:
> >
> > 1. The URL is good for the interval = expressed in the EXPIRES
> > header of the notification which contained = the presence
> > document URL, or the Subscription-Expires = (soon to be
> > Subscription-State), whichever is = shorter.
>
> I think this is wrong. How about:
>
>   1. If the notification which = contained the presence document URL
>   also contained an Expires header, = the URL is good for the interval
>   expressed in that header.
>
> This permits the document referenced by the URL = to outlast
> the subscription, if that is what the notifier = desired.
> The case where there is Subscription-Expires = but not Expires
> is covered by 5.
>
> >
> > 2. If another notification is received = during the interval
> > identified in (1), then the previous URL = should be considered
> > stale. The most recent notification always = takes precedence.
> >
> > 3. If a persistient subscription (not a = fetch) ends, any
> > presence URLs associated with that = subscription should be considered
> > stale.
> >
> > 4. If a notify is received with an EXPIRES = set to zero, the
> > URL is considered dead-on-arrival.
>
> It would be stupid to do this. Since it is both = stupid and a
> special case of 1, no need to mention.
>
> >
> > 5. If a notify is received without an = EXPIRES header, the URL
> > is good for the duration of the = subscription.
> >
> > 6. If a notify is received due to a = subscription fetch, the URL
> > is good for the interval expressed in the = EXPIRES header of the
> > notification which contained the presence = document URL.
>
> I don't understand this. What do you mean by a = "subscription fetch"?
> Does this say anything not covered by one of = the other points?
>
>       Paul
> = _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=
>

------_=_NextPart_001_01C1881B.4A848D60-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 18 19:54:29 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02407 for ; Tue, 18 Dec 2001 19:54:29 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJ0p3ES013426; Tue, 18 Dec 2001 19:51:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07763; Tue, 18 Dec 2001 19:53:05 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07751 for ; Tue, 18 Dec 2001 19:52:21 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBJ0pwQ26083; Tue, 18 Dec 2001 19:51:59 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAH05206 (AUTH pkyzivat); Tue, 18 Dec 2001 19:53:14 -0500 (EST) Message-ID: <3C1FE3B1.DF8B4D91@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Stucker CC: Jonathan Rosenberg , adam.roach@ericsson.com, aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence References: <933FADF5E673D411B8A30002A5608A0E0139B3C3@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 19:47:45 -0500 Content-Transfer-Encoding: 7bit I'm sorry, but I am still not sure I understand what you mean about a subscription fetch. Do you perhaps mean sending a SUBSCRIBE with an Expires of zero to do a one-time retrieval of the presence document? If so, I think this does present an ugly case. I think the presence server must return a non-zero Expires value, or else the client can take its chances with no guarantees. Note that this is new behavior because there aren't any presence servers returning URI-LIST yet. Of course the same problem exists to an extent even if you request the presence document. But then at least you have the document to look at even if it has expired. It doesn't have to do anything to be used. With the URL, the server hosting the URL has to honor it before it is useful. Paul > Brian Stucker wrote: > > The reason I mention the fetch is because in the sip-events draft, you > can have a NOTIFY with an expires of zero, > and no subscription-expires (the subscription-expires is only a > SHOULD, presumably to keep from deprecating implementations from the > -00 draft). > > So, if your client KNOWS that it just did a fetch, then the problem as > has been pointed out is that the NOTIFY could come back with no > subscription-expires header, an Expires header set to zero (to denote > that the subscription is over as there never was one), and with a > presence URL (because it's a fetch). In this case the client shouldn't > treat the URL as dead-on-arrival even though the NOTIFY looks just > like a "stupid" dead-on-arrival notify. I think this is what Aki was > getting at, and it's a good point. > > Either we agree to a set interval, as Jonathan has suggested (which > I'm fine with), or we agree that when a URL is to be sent back in > NOTIFY that was sent because of a fetch operation, that there MUST be > a subscription-expires, and the expires header can't be zero. > Otherwise, URLs returned as part of a fetch operation where the > optional subscription-expires header isn't present would either be > immediately stale (as Aki pointed out), or would be valid for an > undetermined amount of time (which is what we're trying to avoid). > > Regards, > > Brian Stucker > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, December 18, 2001 3:52 PM > > To: Stucker, Brian [NGB:B635:EXCH] > > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; > aki.niemi@nokia.com; > > bcampbell@dynamicsoft.com; seancolson@yahoo.com; > > simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] Duration of URIs in application/uri-list for > > Presence > > > > > > Comments below. > > > > > Brian Stucker wrote: > > > > > > The problem is that, the wording that was given earlier meant that > a > > > fetch > > > was not possible because the URL would only last until the > > > subscription expired. > > > > > > Ahh.. Now I see it. Ok. Yes, there is a problem Aki. > > > > > > So the logic needs to be revised, which is what Jonathan was > talking > > > about. Now > > > I understand. It seems that (nearly) everyone was intent on not > > > specifying a > > > standard interval for the URL to be good for. So, with that in > mind, > > > how about: > > > > > > 1. The URL is good for the interval expressed in the EXPIRES > > > header of the notification which contained the presence > > > document URL, or the Subscription-Expires (soon to be > > > Subscription-State), whichever is shorter. > > > > I think this is wrong. How about: > > > > 1. If the notification which contained the presence document URL > > also contained an Expires header, the URL is good for the interval > > > expressed in that header. > > > > This permits the document referenced by the URL to outlast > > the subscription, if that is what the notifier desired. > > The case where there is Subscription-Expires but not Expires > > is covered by 5. > > > > > > > > 2. If another notification is received during the interval > > > identified in (1), then the previous URL should be considered > > > stale. The most recent notification always takes precedence. > > > > > > 3. If a persistient subscription (not a fetch) ends, any > > > presence URLs associated with that subscription should be > considered > > > stale. > > > > > > 4. If a notify is received with an EXPIRES set to zero, the > > > URL is considered dead-on-arrival. > > > > It would be stupid to do this. Since it is both stupid and a > > special case of 1, no need to mention. > > > > > > > > 5. If a notify is received without an EXPIRES header, the URL > > > is good for the duration of the subscription. > > > > > > 6. If a notify is received due to a subscription fetch, the URL > > > is good for the interval expressed in the EXPIRES header of the > > > notification which contained the presence document URL. > > > > I don't understand this. What do you mean by a "subscription fetch"? > > > Does this say anything not covered by one of the other points? > > > > Paul > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Dec 18 20:03:04 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02563 for ; Tue, 18 Dec 2001 20:03:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJ103ES013558; Tue, 18 Dec 2001 20:00:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07835; Tue, 18 Dec 2001 20:02:05 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07824 for ; Tue, 18 Dec 2001 20:01:25 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBJ10WF14622; Tue, 18 Dec 2001 19:00:32 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 18:59:07 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0139B450@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Paul Kyzivat Cc: Jonathan Rosenberg , adam.roach@ericsson.com, aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18828.5788FF70" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 18:58:59 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C18828.5788FF70 Content-Type: text/plain; charset="iso-8859-1" I didn't understand it at first either, but yes, I am talking about the expires of zero to do a one-time retrieval of the presence document. You have a good point about the non-URL case. Jonathan, what's the current behavior set for that case? Wouldn't it follow the same pattern? Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, December 18, 2001 6:48 PM > To: Stucker, Brian [NGB:B635:EXCH] > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; aki.niemi@nokia.com; > bcampbell@dynamicsoft.com; seancolson@yahoo.com; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Duration of URIs in application/uri-list for > Presence > > > I'm sorry, but I am still not sure I understand what you mean about a > subscription fetch. Do you perhaps mean sending a SUBSCRIBE with an > Expires of zero to do a one-time retrieval of the presence document? > > If so, I think this does present an ugly case. I think the presence > server must return a non-zero Expires value, or else the > client can take > its chances with no guarantees. Note that this is new behavior because > there aren't any presence servers returning URI-LIST yet. > > Of course the same problem exists to an extent even if you request the > presence document. But then at least you have the document to look at > even if it has expired. It doesn't have to do anything to be > used. With > the URL, the server hosting the URL has to honor it before it > is useful. > > Paul > > > > Brian Stucker wrote: > > > > The reason I mention the fetch is because in the sip-events > draft, you > > can have a NOTIFY with an expires of zero, > > and no subscription-expires (the subscription-expires is only a > > SHOULD, presumably to keep from deprecating implementations from the > > -00 draft). > > > > So, if your client KNOWS that it just did a fetch, then the > problem as > > has been pointed out is that the NOTIFY could come back with no > > subscription-expires header, an Expires header set to zero > (to denote > > that the subscription is over as there never was one), and with a > > presence URL (because it's a fetch). In this case the > client shouldn't > > treat the URL as dead-on-arrival even though the NOTIFY looks just > > like a "stupid" dead-on-arrival notify. I think this is what Aki was > > getting at, and it's a good point. > > > > Either we agree to a set interval, as Jonathan has suggested (which > > I'm fine with), or we agree that when a URL is to be sent back in > > NOTIFY that was sent because of a fetch operation, that > there MUST be > > a subscription-expires, and the expires header can't be zero. > > Otherwise, URLs returned as part of a fetch operation where the > > optional subscription-expires header isn't present would either be > > immediately stale (as Aki pointed out), or would be valid for an > > undetermined amount of time (which is what we're trying to avoid). > > > > Regards, > > > > Brian Stucker ------_=_NextPart_001_01C18828.5788FF70 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Duration of URIs in application/uri-list for Presence

I didn't understand it at first either, but yes, I am talking about the
expires of zero to do a one-time retrieval of the presence document.

You have a good point about the non-URL case. Jonathan, what's the current behavior set
for that case? Wouldn't it follow the same pattern?

Brian


> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, December 18, 2001 6:48 PM
> To: Stucker, Brian [NGB:B635:EXCH]
> Cc: Jonathan Rosenberg; adam.roach@ericsson.com; aki.niemi@nokia.com;
> bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Duration of URIs in application/uri-list for
> Presence
>
>
> I'm sorry, but I am still not sure I understand what you mean about a
> subscription fetch. Do you perhaps mean sending a SUBSCRIBE with an
> Expires of zero to do a one-time retrieval of the presence document?
>
> If so, I think this does present an ugly case. I think the presence
> server must return a non-zero Expires value, or else the
> client can take
> its chances with no guarantees. Note that this is new behavior because
> there aren't any presence servers returning URI-LIST yet.
>
> Of course the same problem exists to an extent even if you request the
> presence document. But then at least you have the document to look at
> even if it has expired. It doesn't have to do anything to be
> used. With
> the URL, the server hosting the URL has to honor it before it
> is useful.
>
>       Paul
>
>
> > Brian Stucker wrote:
> >
> > The reason I mention the fetch is because in the sip-events
> draft, you
> > can have a NOTIFY with an expires of zero,
> > and no subscription-expires (the subscription-expires is only a
> > SHOULD, presumably to keep from deprecating implementations from the
> > -00 draft).
> >
> > So, if your client KNOWS that it just did a fetch, then the
> problem as
> > has been pointed out is that the NOTIFY could come back with no
> > subscription-expires header, an Expires header set to zero
> (to denote
> > that the subscription is over as there never was one), and with a
> > presence URL (because it's a fetch). In this case the
> client shouldn't
> > treat the URL as dead-on-arrival even though the NOTIFY looks just
> > like a "stupid" dead-on-arrival notify. I think this is what Aki was
> > getting at, and it's a good point.
> >
> > Either we agree to a set interval, as Jonathan has suggested (which
> > I'm fine with), or we agree that when a URL is to be sent back in
> > NOTIFY that was sent because of a fetch operation, that
> there MUST be
> > a subscription-expires, and the expires header can't be zero.
> > Otherwise, URLs returned as part of a fetch operation where the
> > optional subscription-expires header isn't present would either be
> > immediately stale (as Aki pointed out), or would be valid for an
> > undetermined amount of time (which is what we're trying to avoid).
> >
> > Regards,
> >
> > Brian Stucker

------_=_NextPart_001_01C18828.5788FF70-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 19 09:55:13 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28776 for ; Wed, 19 Dec 2001 09:55:12 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJEl9ES016117; Wed, 19 Dec 2001 09:47:10 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10301; Wed, 19 Dec 2001 09:49:05 -0500 (EST) Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA10290 for ; Wed, 19 Dec 2001 09:48:10 -0500 (EST) Message-ID: <20011219144740.3875.qmail@web11604.mail.yahoo.com> Received: from [208.237.135.21] by web11604.mail.yahoo.com via HTTP; Wed, 19 Dec 2001 06:47:40 PST From: Sean Olson Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e To: Brian Stucker , Paul Kyzivat Cc: Jonathan Rosenberg , adam.roach@ericsson.com, aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com In-Reply-To: <933FADF5E673D411B8A30002A5608A0E0139B3C3@zrc2c012.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 19 Dec 2001 06:47:40 -0800 (PST) I would argue that if the server wants to return a list of URLs and if those URLs should be valid for a duration longer than zero seconds, then the Expire: header should be non-zero. A zero value for the expires parameter of the Subscription-State: header could be used to indicate that this is a "fetch" with no actual subscription session. With this in mind, there is no reason to define any arbitrary interval. /sean --- Brian Stucker wrote: > The reason I mention the fetch is because in the > sip-events draft, you can > have a NOTIFY with an expires of zero, > and no subscription-expires (the > subscription-expires is only a SHOULD, > presumably to keep from deprecating implementations > from the -00 draft). > > So, if your client KNOWS that it just did a fetch, > then the problem as has > been pointed out is that the NOTIFY could come back > with no > subscription-expires header, an Expires header set > to zero (to denote that > the subscription is over as there never was one), > and with a presence URL > (because it's a fetch). In this case the client > shouldn't treat the URL as > dead-on-arrival even though the NOTIFY looks just > like a "stupid" > dead-on-arrival notify. I think this is what Aki was > getting at, and it's a > good point. > > Either we agree to a set interval, as Jonathan has > suggested (which I'm fine > with), or we agree that when a URL is to be sent > back in NOTIFY that was > sent because of a fetch operation, that there MUST > be a > subscription-expires, and the expires header can't > be zero. Otherwise, URLs > returned as part of a fetch operation where the > optional > subscription-expires header isn't present would > either be immediately stale > (as Aki pointed out), or would be valid for an > undetermined amount of time > (which is what we're trying to avoid). > > Regards, > > Brian Stucker > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, December 18, 2001 3:52 PM > > To: Stucker, Brian [NGB:B635:EXCH] > > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; > aki.niemi@nokia.com; > > bcampbell@dynamicsoft.com; seancolson@yahoo.com; > > simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] Duration of URIs in > application/uri-list for > > Presence > > > > > > Comments below. > > > > > Brian Stucker wrote: > > > > > > The problem is that, the wording that was given > earlier meant that a > > > fetch > > > was not possible because the URL would only last > until the > > > subscription expired. > > > > > > Ahh.. Now I see it. Ok. Yes, there is a problem > Aki. > > > > > > So the logic needs to be revised, which is what > Jonathan was talking > > > about. Now > > > I understand. It seems that (nearly) everyone > was intent on not > > > specifying a > > > standard interval for the URL to be good for. > So, with that in mind, > > > how about: > > > > > > 1. The URL is good for the interval expressed in > the EXPIRES > > > header of the notification which contained the > presence > > > document URL, or the Subscription-Expires (soon > to be > > > Subscription-State), whichever is shorter. > > > > I think this is wrong. How about: > > > > 1. If the notification which contained the > presence document URL > > also contained an Expires header, the URL is > good for the interval > > expressed in that header. > > > > This permits the document referenced by the URL to > outlast > > the subscription, if that is what the notifier > desired. > > The case where there is Subscription-Expires but > not Expires > > is covered by 5. > > > > > > > > 2. If another notification is received during > the interval > > > identified in (1), then the previous URL should > be considered > > > stale. The most recent notification always takes > precedence. > > > > > > 3. If a persistient subscription (not a fetch) > ends, any > > > presence URLs associated with that subscription > should be considered > > > stale. > > > > > > 4. If a notify is received with an EXPIRES set > to zero, the > > > URL is considered dead-on-arrival. > > > > It would be stupid to do this. Since it is both > stupid and a > > special case of 1, no need to mention. > > > > > > > > 5. If a notify is received without an EXPIRES > header, the URL > > > is good for the duration of the subscription. > > > > > > 6. If a notify is received due to a subscription > fetch, the URL > > > is good for the interval expressed in the > EXPIRES header of the > > > notification which contained the presence > document URL. > > > > I don't understand this. What do you mean by a > "subscription fetch"? > > Does this say anything not covered by one of the > other points? > > > > Paul > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > ===== -- Sean Olson This is from me. Assume nothing else. __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 19 11:48:11 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01449 for ; Wed, 19 Dec 2001 11:48:11 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJGe3ES017224; Wed, 19 Dec 2001 11:40:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10673; Wed, 19 Dec 2001 11:42:05 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10662 for ; Wed, 19 Dec 2001 11:41:56 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJGdqES017218 for ; Wed, 19 Dec 2001 11:39:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 11:41:28 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E8C2@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'simple@mailman.dynamicsoft.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] administrative test Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 19 Dec 2001 11:41:23 -0500 please ignore _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 19 14:39:23 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05248 for ; Wed, 19 Dec 2001 14:39:23 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJJV1ES018920; Wed, 19 Dec 2001 14:31:01 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11274; Wed, 19 Dec 2001 14:33:05 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11263 for ; Wed, 19 Dec 2001 14:32:59 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBJJSAP15472; Wed, 19 Dec 2001 13:28:10 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 13:26:43 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E013F14DB@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "Brian Stucker" , Sean Olson , Paul Kyzivat Cc: Jonathan Rosenberg , adam.roach@ericsson.com, aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C188C3.165FEC70" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 19 Dec 2001 13:26:41 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C188C3.165FEC70 Content-Type: text/plain; charset="iso-8859-1" Sorry, meant to say don't put a ZERO expires in there. =) > -----Original Message----- > From: Stucker, Brian [NGB:B635:EXCH] > Sent: Wednesday, December 19, 2001 1:31 PM > To: 'Sean Olson'; Paul Kyzivat > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; aki.niemi@nokia.com; > bcampbell@dynamicsoft.com; seancolson@yahoo.com; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Duration of URIs in application/uri-list for > Presenc e > > > Except that Adam's draft doesn't mandate the > Subscription-State in the -01 revision (at least to my > reading). So you may not have a Subscription-State header, > and therefore would need the Expires to be zero if it's a fetch. > > Yes, otherwise the whole issue is moot. Don't put a non-zero > expires in there, that makes no sense. > > Brian > > > -----Original Message----- > > From: Sean Olson [mailto:seancolson@yahoo.com] > > Sent: Wednesday, December 19, 2001 8:48 AM > > To: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat > > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; > aki.niemi@nokia.com; > > bcampbell@dynamicsoft.com; seancolson@yahoo.com; > > simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Duration of URIs in application/uri-list for > > Presenc e > > > > > > I would argue that if the server wants to return > > a list of URLs and if those URLs should be > > valid for a duration longer than zero seconds, > > then the Expire: header should be non-zero. > > A zero value for the expires parameter of the > > Subscription-State: header could be used to > > indicate that this is a "fetch" with no > > actual subscription session. With this in mind, > > there is no reason to define any arbitrary interval. > > > > /sean > > > > --- Brian Stucker wrote: > > > The reason I mention the fetch is because in the > > > sip-events draft, you can > > > have a NOTIFY with an expires of zero, > > > and no subscription-expires (the > > > subscription-expires is only a SHOULD, > > > presumably to keep from deprecating implementations > > > from the -00 draft). > > > > > > So, if your client KNOWS that it just did a fetch, > > > then the problem as has > > > been pointed out is that the NOTIFY could come back > > > with no > > > subscription-expires header, an Expires header set > > > to zero (to denote that > > > the subscription is over as there never was one), > > > and with a presence URL > > > (because it's a fetch). In this case the client > > > shouldn't treat the URL as > > > dead-on-arrival even though the NOTIFY looks just > > > like a "stupid" > > > dead-on-arrival notify. I think this is what Aki was > > > getting at, and it's a > > > good point. > > > > > > Either we agree to a set interval, as Jonathan has > > > suggested (which I'm fine > > > with), or we agree that when a URL is to be sent > > > back in NOTIFY that was > > > sent because of a fetch operation, that there MUST > > > be a > > > subscription-expires, and the expires header can't > > > be zero. Otherwise, URLs > > > returned as part of a fetch operation where the > > > optional > > > subscription-expires header isn't present would > > > either be immediately stale > > > (as Aki pointed out), or would be valid for an > > > undetermined amount of time > > > (which is what we're trying to avoid). > > > > > > Regards, > > > > > > Brian Stucker > > > > > > ------_=_NextPart_001_01C188C3.165FEC70 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Duration of URIs in application/uri-list for Presenc e

Sorry, meant to say don't put a ZERO expires in there. =)

> -----Original Message-----
> From: Stucker, Brian [NGB:B635:EXCH]
> Sent: Wednesday, December 19, 2001 1:31 PM
> To: 'Sean Olson'; Paul Kyzivat
> Cc: Jonathan Rosenberg; adam.roach@ericsson.com; aki.niemi@nokia.com;
> bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Duration of URIs in application/uri-list for
> Presenc e
>
>
> Except that Adam's draft doesn't mandate the
> Subscription-State in the -01 revision (at least to my
> reading). So you may not have a Subscription-State header,
> and therefore would need the Expires to be zero if it's a fetch.
>
> Yes, otherwise the whole issue is moot. Don't put a non-zero
> expires in there, that makes no sense.
>
> Brian
>
> > -----Original Message-----
> > From: Sean Olson [mailto:seancolson@yahoo.com]
> > Sent: Wednesday, December 19, 2001 8:48 AM
> > To: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat
> > Cc: Jonathan Rosenberg; adam.roach@ericsson.com;
> aki.niemi@nokia.com;
> > bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> > simple@mailman.dynamicsoft.com
> > Subject: RE: [Simple] Duration of URIs in application/uri-list for
> > Presenc e
> >
> >
> > I would argue that if the server wants to return
> > a list of URLs and if those URLs should be
> > valid for a duration longer than zero seconds,
> > then the Expire: header should be non-zero.
> > A zero value for the expires parameter of the
> > Subscription-State: header could be used to
> > indicate that this is a "fetch" with no
> > actual subscription session. With this in mind,
> > there is no reason to define any arbitrary interval.
> >
> > /sean
> >
> > --- Brian Stucker <bstucker@nortelnetworks.com> wrote:
> > > The reason I mention the fetch is because in the
> > > sip-events draft, you can
> > > have a NOTIFY with an expires of zero,
> > > and no subscription-expires (the
> > > subscription-expires is only a SHOULD,
> > > presumably to keep from deprecating implementations
> > > from the -00 draft).
> > >
> > > So, if your client KNOWS that it just did a fetch,
> > > then the problem as has
> > > been pointed out is that the NOTIFY could come back
> > > with no
> > > subscription-expires header, an Expires header set
> > > to zero (to denote that
> > > the subscription is over as there never was one),
> > > and with a presence URL
> > > (because it's a fetch). In this case the client
> > > shouldn't treat the URL as
> > > dead-on-arrival even though the NOTIFY looks just
> > > like a "stupid"
> > > dead-on-arrival notify. I think this is what Aki was
> > > getting at, and it's a
> > > good point.
> > >
> > > Either we agree to a set interval, as Jonathan has
> > > suggested (which I'm fine
> > > with), or we agree that when a URL is to be sent
> > > back in NOTIFY that was
> > > sent because of a fetch operation, that there MUST
> > > be a
> > > subscription-expires, and the expires header can't
> > > be zero. Otherwise, URLs
> > > returned as part of a fetch operation where the
> > > optional
> > > subscription-expires header isn't present would
> > > either be immediately stale
> > > (as Aki pointed out), or would be valid for an
> > > undetermined amount of time
> > > (which is what we're trying to avoid).
> > >
> > > Regards,
> > >
> > > Brian Stucker
> > >
> > >

------_=_NextPart_001_01C188C3.165FEC70-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 19 14:40:18 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05287 for ; Wed, 19 Dec 2001 14:40:17 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJJR5ES018841; Wed, 19 Dec 2001 14:27:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11241; Wed, 19 Dec 2001 14:29:05 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11230 for ; Wed, 19 Dec 2001 14:28:12 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBJJROP15310; Wed, 19 Dec 2001 13:27:24 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 13:25:57 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E013F14D5@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Sean Olson , Paul Kyzivat Cc: Jonathan Rosenberg , adam.roach@ericsson.com, aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C188C2.FA20A180" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 19 Dec 2001 13:25:54 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C188C2.FA20A180 Content-Type: text/plain; charset="iso-8859-1" Except that Adam's draft doesn't mandate the Subscription-State in the -01 revision (at least to my reading). So you may not have a Subscription-State header, and therefore would need the Expires to be zero if it's a fetch. Yes, otherwise the whole issue is moot. Don't put a non-zero expires in there, that makes no sense. Brian > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Wednesday, December 19, 2001 8:48 AM > To: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; aki.niemi@nokia.com; > bcampbell@dynamicsoft.com; seancolson@yahoo.com; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Duration of URIs in application/uri-list for > Presenc e > > > I would argue that if the server wants to return > a list of URLs and if those URLs should be > valid for a duration longer than zero seconds, > then the Expire: header should be non-zero. > A zero value for the expires parameter of the > Subscription-State: header could be used to > indicate that this is a "fetch" with no > actual subscription session. With this in mind, > there is no reason to define any arbitrary interval. > > /sean > > --- Brian Stucker wrote: > > The reason I mention the fetch is because in the > > sip-events draft, you can > > have a NOTIFY with an expires of zero, > > and no subscription-expires (the > > subscription-expires is only a SHOULD, > > presumably to keep from deprecating implementations > > from the -00 draft). > > > > So, if your client KNOWS that it just did a fetch, > > then the problem as has > > been pointed out is that the NOTIFY could come back > > with no > > subscription-expires header, an Expires header set > > to zero (to denote that > > the subscription is over as there never was one), > > and with a presence URL > > (because it's a fetch). In this case the client > > shouldn't treat the URL as > > dead-on-arrival even though the NOTIFY looks just > > like a "stupid" > > dead-on-arrival notify. I think this is what Aki was > > getting at, and it's a > > good point. > > > > Either we agree to a set interval, as Jonathan has > > suggested (which I'm fine > > with), or we agree that when a URL is to be sent > > back in NOTIFY that was > > sent because of a fetch operation, that there MUST > > be a > > subscription-expires, and the expires header can't > > be zero. Otherwise, URLs > > returned as part of a fetch operation where the > > optional > > subscription-expires header isn't present would > > either be immediately stale > > (as Aki pointed out), or would be valid for an > > undetermined amount of time > > (which is what we're trying to avoid). > > > > Regards, > > > > Brian Stucker > > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Tuesday, December 18, 2001 3:52 PM > > > To: Stucker, Brian [NGB:B635:EXCH] > > > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; > > aki.niemi@nokia.com; > > > bcampbell@dynamicsoft.com; seancolson@yahoo.com; > > > simple@mailman.dynamicsoft.com > > > Subject: Re: [Simple] Duration of URIs in > > application/uri-list for > > > Presence > > > > > > > > > Comments below. > > > > > > > Brian Stucker wrote: > > > > > > > > The problem is that, the wording that was given > > earlier meant that a > > > > fetch > > > > was not possible because the URL would only last > > until the > > > > subscription expired. > > > > > > > > Ahh.. Now I see it. Ok. Yes, there is a problem > > Aki. > > > > > > > > So the logic needs to be revised, which is what > > Jonathan was talking > > > > about. Now > > > > I understand. It seems that (nearly) everyone > > was intent on not > > > > specifying a > > > > standard interval for the URL to be good for. > > So, with that in mind, > > > > how about: > > > > > > > > 1. The URL is good for the interval expressed in > > the EXPIRES > > > > header of the notification which contained the > > presence > > > > document URL, or the Subscription-Expires (soon > > to be > > > > Subscription-State), whichever is shorter. > > > > > > I think this is wrong. How about: > > > > > > 1. If the notification which contained the > > presence document URL > > > also contained an Expires header, the URL is > > good for the interval > > > expressed in that header. > > > > > > This permits the document referenced by the URL to > > outlast > > > the subscription, if that is what the notifier > > desired. > > > The case where there is Subscription-Expires but > > not Expires > > > is covered by 5. > > > > > > > > > > > 2. If another notification is received during > > the interval > > > > identified in (1), then the previous URL should > > be considered > > > > stale. The most recent notification always takes > > precedence. > > > > > > > > 3. If a persistient subscription (not a fetch) > > ends, any > > > > presence URLs associated with that subscription > > should be considered > > > > stale. > > > > > > > > 4. If a notify is received with an EXPIRES set > > to zero, the > > > > URL is considered dead-on-arrival. > > > > > > It would be stupid to do this. Since it is both > > stupid and a > > > special case of 1, no need to mention. > > > > > > > > > > > 5. If a notify is received without an EXPIRES > > header, the URL > > > > is good for the duration of the subscription. > > > > > > > > 6. If a notify is received due to a subscription > > fetch, the URL > > > > is good for the interval expressed in the > > EXPIRES header of the > > > > notification which contained the presence > > document URL. > > > > > > I don't understand this. What do you mean by a > > "subscription fetch"? > > > Does this say anything not covered by one of the > > other points? > > > > > > Paul > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.com > > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > ===== > -- > Sean Olson > This is from me. Assume nothing else. > > __________________________________________________ > Do You Yahoo!? > Check out Yahoo! Shopping and Yahoo! Auctions for all of > your unique holiday gifts! Buy at http://shopping.yahoo.com > or bid at http://auctions.yahoo.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C188C2.FA20A180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Duration of URIs in application/uri-list for = Presenc e

Except that Adam's draft doesn't mandate the = Subscription-State in the -01 revision (at least to my reading). So you = may not have a Subscription-State header, and therefore would need the = Expires to be zero if it's a fetch.

Yes, otherwise the whole issue is moot. Don't put a = non-zero expires in there, that makes no sense.

Brian

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Wednesday, December 19, 2001 8:48 = AM
> To: Stucker, Brian [NGB:B635:EXCH]; Paul = Kyzivat
> Cc: Jonathan Rosenberg; = adam.roach@ericsson.com; aki.niemi@nokia.com;
> bcampbell@dynamicsoft.com; = seancolson@yahoo.com;
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Duration of URIs in = application/uri-list for
> Presenc e
>
>
> I would argue that if the server wants to = return
> a list of URLs and if those URLs should = be
> valid for a duration longer than zero = seconds,
> then the Expire: header should be = non-zero.
> A zero value for the expires parameter of = the
> Subscription-State: header could be used = to
> indicate that this is a "fetch" with = no
> actual subscription session. With this in = mind,
> there is no reason to define any arbitrary = interval.
>
> /sean
>
> --- Brian Stucker = <bstucker@nortelnetworks.com> wrote:
> > The reason I mention the fetch is because = in the
> > sip-events draft, you can
> > have a NOTIFY with an expires of = zero,
> > and no subscription-expires (the
> > subscription-expires is only a = SHOULD,
> > presumably to keep from deprecating = implementations
> > from the -00 draft).
> >
> > So, if your client KNOWS that it just did = a fetch,
> > then the problem as has
> > been pointed out is that the NOTIFY could = come back
> > with no
> > subscription-expires header, an Expires = header set
> > to zero (to denote that
> > the subscription is over as there never = was one),
> > and with a presence URL
> > (because it's a fetch). In this case the = client
> > shouldn't treat the URL as
> > dead-on-arrival even though the NOTIFY = looks just
> > like a "stupid"
> > dead-on-arrival notify. I think this is = what Aki was
> > getting at, and it's a
> > good point.
> >
> > Either we agree to a set interval, as = Jonathan has
> > suggested (which I'm fine
> > with), or we agree that when a URL is to = be sent
> > back in NOTIFY that was
> > sent because of a fetch operation, that = there MUST
> > be a
> > subscription-expires, and the expires = header can't
> > be zero. Otherwise, URLs
> > returned as part of a fetch operation = where the
> > optional
> > subscription-expires header isn't present = would
> > either be immediately stale
> > (as Aki pointed out), or would be valid = for an
> > undetermined amount of time
> > (which is what we're trying to = avoid).
> >
> > Regards,
> >
> > Brian Stucker
> >
> >
> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=
> > > Sent: Tuesday, December 18, 2001 3:52 = PM
> > > To: Stucker, Brian = [NGB:B635:EXCH]
> > > Cc: Jonathan Rosenberg; = adam.roach@ericsson.com;
> > aki.niemi@nokia.com;
> > > bcampbell@dynamicsoft.com; = seancolson@yahoo.com;
> > > simple@mailman.dynamicsoft.com
> > > Subject: Re: [Simple] Duration of = URIs in
> > application/uri-list for
> > > Presence
> > >
> > >
> > > Comments below.
> > >
> > > > Brian Stucker wrote:
> > > >
> > > > The problem is that, the wording = that was given
> > earlier meant that a
> > > > fetch
> > > > was not possible because the URL = would only last
> > until the
> > > > subscription expired.
> > > >
> > > > Ahh.. Now I see it. Ok. Yes, = there is a problem
> > Aki.
> > > >
> > > > So the logic needs to be = revised, which is what
> > Jonathan was talking
> > > > about. Now
> > > > I understand. It seems that = (nearly) everyone
> > was intent on not
> > > > specifying a
> > > > standard interval for the URL to = be good for.
> > So, with that in mind,
> > > > how about:
> > > >
> > > > 1. The URL is good for the = interval expressed in
> > the EXPIRES
> > > > header of the notification which = contained the
> > presence
> > > > document URL, or the = Subscription-Expires (soon
> > to be
> > > > Subscription-State), whichever = is shorter.
> > >
> > > I think this is wrong. How = about:
> > >
> > >   1. If the notification = which contained the
> > presence document URL
> > >   also contained an Expires = header, the URL is
> > good for the interval
> > >   expressed in that = header.
> > >
> > > This permits the document referenced = by the URL to
> > outlast
> > > the subscription, if that is what the = notifier
> > desired.
> > > The case where there is = Subscription-Expires but
> > not Expires
> > > is covered by 5.
> > >
> > > >
> > > > 2. If another notification is = received during
> > the interval
> > > > identified in (1), then the = previous URL should
> > be considered
> > > > stale. The most recent = notification always takes
> > precedence.
> > > >
> > > > 3. If a persistient subscription = (not a fetch)
> > ends, any
> > > > presence URLs associated with = that subscription
> > should be considered
> > > > stale.
> > > >
> > > > 4. If a notify is received with = an EXPIRES set
> > to zero, the
> > > > URL is considered = dead-on-arrival.
> > >
> > > It would be stupid to do this. Since = it is both
> > stupid and a
> > > special case of 1, no need to = mention.
> > >
> > > >
> > > > 5. If a notify is received = without an EXPIRES
> > header, the URL
> > > > is good for the duration of the = subscription.
> > > >
> > > > 6. If a notify is received due = to a subscription
> > fetch, the URL
> > > > is good for the interval = expressed in the
> > EXPIRES header of the
> > > > notification which contained the = presence
> > document URL.
> > >
> > > I don't understand this. What do you = mean by a
> > "subscription fetch"?
> > > Does this say anything not covered by = one of the
> > other points?
> > >
> > >   Paul
> > > ______________________________________= _________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > >
> >
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=
> > >
> >
>
>
> =3D=3D=3D=3D=3D
> --
> Sean Olson <seancolson@yahoo.com>
> This is from me. Assume nothing else.
>
> = __________________________________________________
> Do You Yahoo!?
> Check out Yahoo! Shopping and Yahoo! Auctions = for all of
> your unique holiday gifts! Buy at http://shopping.yahoo.com
> or bid at http://auctions.yahoo.com
> = _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=
>

------_=_NextPart_001_01C188C2.FA20A180-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Dec 19 15:16:15 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06111 for ; Wed, 19 Dec 2001 15:16:15 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJK83ES019368; Wed, 19 Dec 2001 15:08:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11423; Wed, 19 Dec 2001 15:10:07 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10894 for ; Wed, 19 Dec 2001 12:44:53 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJHgnES017951 for <"simple@mailman.dynamicsoft.com">; Wed, 19 Dec 2001 12:42:49 -0500 (EST) Received: from dynamicsoft.com (POPE1 [63.113.46.82]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZDFR1M3N; Wed, 19 Dec 2001 12:44:25 -0500 Message-ID: <3C20D1F8.60308@dynamicsoft.com> From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "simple@mailman.dynamicsoft.com"@mail1.dynamicsoft.com Subject: [Fwd: Re: [Simple] Duration of URIs in application/uri-list for Presenc e] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 19 Dec 2001 12:44:24 -0500 Content-Transfer-Encoding: 7bit Resend due to some unusual mailing problems.... aki.niemi@nokia.com wrote: > Hi All, > > >>I agree with Ben. Although you raise good points Paul. >>Can we all agree to: >>1. The URL is good for the interval expressed in the EXPIRES >>header of the notification which contained the presence >>document URL, or the Subscription-Expires (soon to be >>Subscription-State), whichever is shorter. >> > > Overall, I like the sound of this proposal. However, a distinct linking > like > this between the Subscription-Expires and Expires assumes that > subscriptions > always establish a session. This assumption makes a fetch of event state > impossible using the URL mechanism. Good point. Why don't we simplify this, then, and state that the URL is valid for duration in the Expires, if present, otherwise, the duration of the subscription, and that the next NOTIFY overrides the previous URL. This way, if you want the URL validity to be less than the subscription duration, you can do that (Expires < Subscription-Expires), equal to it (no Expires) or greater than it (Expires > Subscription-Expires). We also say that in absense of reasons to do so otherwise, the URL SHOULD be valid for the duration of the subscription, and for fetches, for some reasonable interval, say 2 min. That is, we specify semantics that enable any policy, and state a recommended baseline policy. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Dec 20 07:07:20 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06130 for ; Thu, 20 Dec 2001 07:07:20 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBKBx3ES022800; Thu, 20 Dec 2001 06:59:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14270; Thu, 20 Dec 2001 07:01:05 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14259 for ; Thu, 20 Dec 2001 07:00:09 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBKBxc913004 for ; Thu, 20 Dec 2001 13:59:38 +0200 (EET) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Dec 2001 13:59:38 +0200 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Thu, 20 Dec 2001 13:59:38 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC84@esebe013.NOE.Nokia.com> To: bstucker@nortelnetworks.com, seancolson@yahoo.com, pkyzivat@cisco.com Cc: jdrosen@dynamicsoft.com, adam.roach@ericsson.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 20 Dec 2001 13:59:28 +0200 Hi, > Except that Adam's draft doesn't mandate the > Subscription-State in the -01 revision (at least to my > reading). So you may not have a Subscription-State header, > and therefore would need the Expires to be zero if it's a fetch. The client knows it's a fetch because: - It sets the Expires to zero in its SUBSCRIBE - the 2xx for the SUBSCRIBE carries an Expires: 0 The Expires in NOTIFY should be scoped to only set the expiry for that particular message content. Subscription-* is there to communicate the expiry for the whole session. I don't see why there needs to be anything else specified for the URI-list case, other than "If you give a link instead of the document, you SHOULD use Expires to say how long the link is valid for." An arriving NOTIFY might override some or all of the information given in a previous URL, and the content of the URL might be invalid, it doesn't really matter. If notifications carry documents instead, this is anyway self-evident; older documents are not necessarily valid, especially after the subscription has been terminated. I may be missing a point here, but I don't feel there is need to say anything more about using Expires in a NOTIFY, than what is already said for the default usage of Expires. Regards, Aki > Yes, otherwise the whole issue is moot. Don't put a non-zero > expires in there, that makes no sense. > > Brian > > > -----Original Message----- > > From: Sean Olson [mailto:seancolson@yahoo.com] > > Sent: Wednesday, December 19, 2001 8:48 AM > > To: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat > > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; > aki.niemi@nokia.com; > > bcampbell@dynamicsoft.com; seancolson@yahoo.com; > > simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Duration of URIs in application/uri-list for > > Presenc e > > > > > > I would argue that if the server wants to return > > a list of URLs and if those URLs should be > > valid for a duration longer than zero seconds, > > then the Expire: header should be non-zero. > > A zero value for the expires parameter of the > > Subscription-State: header could be used to > > indicate that this is a "fetch" with no > > actual subscription session. With this in mind, > > there is no reason to define any arbitrary interval. > > > > /sean > > > > --- Brian Stucker wrote: > > > The reason I mention the fetch is because in the > > > sip-events draft, you can > > > have a NOTIFY with an expires of zero, > > > and no subscription-expires (the > > > subscription-expires is only a SHOULD, > > > presumably to keep from deprecating implementations > > > from the -00 draft). > > > > > > So, if your client KNOWS that it just did a fetch, > > > then the problem as has > > > been pointed out is that the NOTIFY could come back > > > with no > > > subscription-expires header, an Expires header set > > > to zero (to denote that > > > the subscription is over as there never was one), > > > and with a presence URL > > > (because it's a fetch). In this case the client > > > shouldn't treat the URL as > > > dead-on-arrival even though the NOTIFY looks just > > > like a "stupid" > > > dead-on-arrival notify. I think this is what Aki was > > > getting at, and it's a > > > good point. > > > > > > Either we agree to a set interval, as Jonathan has > > > suggested (which I'm fine > > > with), or we agree that when a URL is to be sent > > > back in NOTIFY that was > > > sent because of a fetch operation, that there MUST > > > be a > > > subscription-expires, and the expires header can't > > > be zero. Otherwise, URLs > > > returned as part of a fetch operation where the > > > optional > > > subscription-expires header isn't present would > > > either be immediately stale > > > (as Aki pointed out), or would be valid for an > > > undetermined amount of time > > > (which is what we're trying to avoid). > > > > > > Regards, > > > > > > Brian Stucker > > > > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Dec 20 10:28:09 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08972 for ; Thu, 20 Dec 2001 10:28:09 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBKFP7ES023872; Thu, 20 Dec 2001 10:25:08 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14891; Thu, 20 Dec 2001 10:27:06 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14880 for ; Thu, 20 Dec 2001 10:26:01 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBKFLZ011859; Thu, 20 Dec 2001 09:21:35 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 09:20:08 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E013F1AAD@zrc2c012.us.nortel.com> From: "Brian Stucker" To: aki.niemi@nokia.com, seancolson@yahoo.com, pkyzivat@cisco.com Cc: jdrosen@dynamicsoft.com, adam.roach@ericsson.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18969.CF7901F0" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 20 Dec 2001 09:20:08 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C18969.CF7901F0 Content-Type: text/plain; charset="iso-8859-1" In the draft (as I read it) if you do not include a subscription-expires (soon to be subscription-state) in the NOTIFY of a fetch, it should include instead an EXPIRES of zero. That would mean the URL should be immediately treated as stale. That's the problem. If there's always a subscription-expires header there, then you can put whatever you want in the EXPIRES header. It's the normative language on the subscription-expires that makes the problem possible. Brian > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Thursday, December 20, 2001 5:59 AM > To: Stucker, Brian [NGB:B635:EXCH]; seancolson@yahoo.com; > pkyzivat@cisco.com > Cc: jdrosen@dynamicsoft.com; adam.roach@ericsson.com; > bcampbell@dynamicsoft.com; seancolson@yahoo.com; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Duration of URIs in application/uri-list for > Presenc e > > > Hi, > > > Except that Adam's draft doesn't mandate the > > Subscription-State in the -01 revision (at least to my > > reading). So you may not have a Subscription-State header, > > and therefore would need the Expires to be zero if it's a fetch. > > The client knows it's a fetch because: > > - It sets the Expires to zero in its SUBSCRIBE > - the 2xx for the SUBSCRIBE carries an Expires: 0 > > The Expires in NOTIFY should be scoped to only set the expiry for that > particular message content. Subscription-* is there to communicate the > expiry for the whole session. > > I don't see why there needs to be anything else specified for > the URI-list > case, other than "If you give a link instead of the document, > you SHOULD use > Expires to say how long the link is valid for." > > An arriving NOTIFY might override some or all of the > information given in a > previous URL, and the content of the URL might be invalid, it > doesn't really > matter. If notifications carry documents instead, this is anyway > self-evident; older documents are not necessarily valid, > especially after > the subscription has been terminated. > > I may be missing a point here, but I don't feel there is need to say > anything more about using Expires in a NOTIFY, than what is > already said for > the default usage of Expires. > > Regards, > Aki > > > > Yes, otherwise the whole issue is moot. Don't put a non-zero > > expires in there, that makes no sense. > > > > Brian > > > > > -----Original Message----- > > > From: Sean Olson [mailto:seancolson@yahoo.com] > > > Sent: Wednesday, December 19, 2001 8:48 AM > > > To: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat > > > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; > > aki.niemi@nokia.com; > > > bcampbell@dynamicsoft.com; seancolson@yahoo.com; > > > simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Duration of URIs in > application/uri-list for > > > Presenc e > > > > > > > > > I would argue that if the server wants to return > > > a list of URLs and if those URLs should be > > > valid for a duration longer than zero seconds, > > > then the Expire: header should be non-zero. > > > A zero value for the expires parameter of the > > > Subscription-State: header could be used to > > > indicate that this is a "fetch" with no > > > actual subscription session. With this in mind, > > > there is no reason to define any arbitrary interval. > > > > > > /sean > > > > > > --- Brian Stucker wrote: > > > > The reason I mention the fetch is because in the > > > > sip-events draft, you can > > > > have a NOTIFY with an expires of zero, > > > > and no subscription-expires (the > > > > subscription-expires is only a SHOULD, > > > > presumably to keep from deprecating implementations > > > > from the -00 draft). > > > > > > > > So, if your client KNOWS that it just did a fetch, > > > > then the problem as has > > > > been pointed out is that the NOTIFY could come back > > > > with no > > > > subscription-expires header, an Expires header set > > > > to zero (to denote that > > > > the subscription is over as there never was one), > > > > and with a presence URL > > > > (because it's a fetch). In this case the client > > > > shouldn't treat the URL as > > > > dead-on-arrival even though the NOTIFY looks just > > > > like a "stupid" > > > > dead-on-arrival notify. I think this is what Aki was > > > > getting at, and it's a > > > > good point. > > > > > > > > Either we agree to a set interval, as Jonathan has > > > > suggested (which I'm fine > > > > with), or we agree that when a URL is to be sent > > > > back in NOTIFY that was > > > > sent because of a fetch operation, that there MUST > > > > be a > > > > subscription-expires, and the expires header can't > > > > be zero. Otherwise, URLs > > > > returned as part of a fetch operation where the > > > > optional > > > > subscription-expires header isn't present would > > > > either be immediately stale > > > > (as Aki pointed out), or would be valid for an > > > > undetermined amount of time > > > > (which is what we're trying to avoid). > > > > > > > > Regards, > > > > > > > > Brian Stucker > > > > > > > > > ------_=_NextPart_001_01C18969.CF7901F0 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Duration of URIs in application/uri-list for Presenc e

In the draft (as I read it) if you do not include a subscription-expires (soon to be
subscription-state) in the NOTIFY of a fetch, it should include instead an EXPIRES of zero.

That would mean the URL should be immediately treated as stale.

That's the problem. If there's always a subscription-expires header there, then you can put
whatever you want in the EXPIRES header.

It's the normative language on the subscription-expires that makes the problem possible.

Brian

> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Thursday, December 20, 2001 5:59 AM
> To: Stucker, Brian [NGB:B635:EXCH]; seancolson@yahoo.com;
> pkyzivat@cisco.com
> Cc: jdrosen@dynamicsoft.com; adam.roach@ericsson.com;
> bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Duration of URIs in application/uri-list for
> Presenc e
>
>
> Hi,
>
> > Except that Adam's draft doesn't mandate the
> > Subscription-State in the -01 revision (at least to my
> > reading). So you may not have a Subscription-State header,
> > and therefore would need the Expires to be zero if it's a fetch.
>
> The client knows it's a fetch because:
>      
>       - It sets the Expires to zero in its SUBSCRIBE
>       - the 2xx for the SUBSCRIBE carries an Expires: 0
>
> The Expires in NOTIFY should be scoped to only set the expiry for that
> particular message content. Subscription-* is there to communicate the
> expiry for the whole session.
>
> I don't see why there needs to be anything else specified for
> the URI-list
> case, other than "If you give a link instead of the document,
> you SHOULD use
> Expires to say how long the link is valid for."
>
> An arriving NOTIFY might override some or all of the
> information given in a
> previous URL, and the content of the URL might be invalid, it
> doesn't really
> matter. If notifications carry documents instead, this is anyway
> self-evident; older documents are not necessarily valid,
> especially after
> the subscription has been terminated.
>
> I may be missing a point here, but I don't feel there is need to say
> anything more about using Expires in a NOTIFY, than what is
> already said for
> the default usage of Expires.
>
> Regards,
> Aki 
>
> 
> > Yes, otherwise the whole issue is moot. Don't put a non-zero
> > expires in there, that makes no sense.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Sean Olson [mailto:seancolson@yahoo.com]
> > > Sent: Wednesday, December 19, 2001 8:48 AM
> > > To: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat
> > > Cc: Jonathan Rosenberg; adam.roach@ericsson.com;
> > aki.niemi@nokia.com;
> > > bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> > > simple@mailman.dynamicsoft.com
> > > Subject: RE: [Simple] Duration of URIs in
> application/uri-list for
> > > Presenc e
> > >
> > >
> > > I would argue that if the server wants to return
> > > a list of URLs and if those URLs should be
> > > valid for a duration longer than zero seconds,
> > > then the Expire: header should be non-zero.
> > > A zero value for the expires parameter of the
> > > Subscription-State: header could be used to
> > > indicate that this is a "fetch" with no
> > > actual subscription session. With this in mind,
> > > there is no reason to define any arbitrary interval.
> > >
> > > /sean
> > >
> > > --- Brian Stucker <bstucker@nortelnetworks.com> wrote:
> > > > The reason I mention the fetch is because in the
> > > > sip-events draft, you can
> > > > have a NOTIFY with an expires of zero,
> > > > and no subscription-expires (the
> > > > subscription-expires is only a SHOULD,
> > > > presumably to keep from deprecating implementations
> > > > from the -00 draft).
> > > >
> > > > So, if your client KNOWS that it just did a fetch,
> > > > then the problem as has
> > > > been pointed out is that the NOTIFY could come back
> > > > with no
> > > > subscription-expires header, an Expires header set
> > > > to zero (to denote that
> > > > the subscription is over as there never was one),
> > > > and with a presence URL
> > > > (because it's a fetch). In this case the client
> > > > shouldn't treat the URL as
> > > > dead-on-arrival even though the NOTIFY looks just
> > > > like a "stupid"
> > > > dead-on-arrival notify. I think this is what Aki was
> > > > getting at, and it's a
> > > > good point.
> > > >
> > > > Either we agree to a set interval, as Jonathan has
> > > > suggested (which I'm fine
> > > > with), or we agree that when a URL is to be sent
> > > > back in NOTIFY that was
> > > > sent because of a fetch operation, that there MUST
> > > > be a
> > > > subscription-expires, and the expires header can't
> > > > be zero. Otherwise, URLs
> > > > returned as part of a fetch operation where the
> > > > optional
> > > > subscription-expires header isn't present would
> > > > either be immediately stale
> > > > (as Aki pointed out), or would be valid for an
> > > > undetermined amount of time
> > > > (which is what we're trying to avoid).
> > > >
> > > > Regards,
> > > >
> > > > Brian Stucker
> > > >
> > > >
>

------_=_NextPart_001_01C18969.CF7901F0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Dec 21 16:05:01 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02096 for ; Fri, 21 Dec 2001 16:05:01 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBLKxBES002985; Fri, 21 Dec 2001 15:59:12 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20196; Fri, 21 Dec 2001 16:00:07 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20183 for ; Fri, 21 Dec 2001 15:59:22 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id fBLKxEVZ000779 for ; Fri, 21 Dec 2001 15:59:15 -0500 (EST) Message-ID: <3C23A28C.30606@dynamicsoft.com> From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] testing - please ignore Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 21 Dec 2001 15:58:52 -0500 Content-Transfer-Encoding: 7bit sorry... -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple