From mailnull@www1.ietf.org Sat Feb 1 04:27:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02759 for ; Sat, 1 Feb 2003 04:27:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h119VRJ30787 for simple-archive@odin.ietf.org; Sat, 1 Feb 2003 04:31:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h119VRJ30784 for ; Sat, 1 Feb 2003 04:31:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02734 for ; Sat, 1 Feb 2003 04:27:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h119VJJ30743; Sat, 1 Feb 2003 04:31:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h119UBJ30686 for ; Sat, 1 Feb 2003 04:30:11 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02671 for ; Sat, 1 Feb 2003 04:25:44 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h119SEk09007 for ; Sat, 1 Feb 2003 11:28:14 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 1 Feb 2003 11:29:17 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 1 Feb 2003 11:29:16 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Simple] New I-Ds on partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1D7FD@esebe004.ntc.nokia.com> Thread-Topic: [Simple] New I-Ds on partial notification Thread-Index: AcLJP+0MaxqRYNnfQaaXsgPogDyUrAAB/+vg To: Cc: X-OriginalArrivalTime: 01 Feb 2003 09:29:16.0784 (UTC) FILETIME=[64011F00:01C2C9D4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h119UBJ30687 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 1 Feb 2003 11:29:15 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, inline > inline. > > mikko.lonnfors@nokia.com wrote: > > Hi Jonathan, > > > > As you say CI works pretty well but there are some complications. > > Charging issue is at least partly 3GPP specific. Charging would be > > especially difficult in 3GPP type solution where all SIP > carried stuff > > goes via one PDP context (e.g. signaling PDP context). All > other traffic > > is going through other PDP contexts. From these the SIP > carried stuff > > can be free on the bearer level and service based charging > is applied in > > the application server. Other PDP contexts typically cause > bill based on > > the data amount transferred. Now if the operator wants to > allow large > > content as part of the presence and apply a service based > changing the > > system becomes unnecessarily complex due to CI. > > Such a differentiated charging model for content opens the door for > fraud. If sending content through presence is free, but costs money > other ways, won't users just always send content through presence? I didn't want to imply that it would be free. Points was that operators would like to implement service based charging for some services. For example without signaling context being free users would have to pay for unanswered calls. > > > CI requires some storage where content should be places until its > > fetched or it expires. This box then needs to maintained > and connected > > to existing network elements like PS. This may be > unnecessary overhead > > for some systems. > > No doubt this is extra infrastructure to maintain. However, > such things > will frequently exist anyway (i.e., MMSC provides a similar function). MMSC (Multimedia Messaging Service Centre) is network element used in messaging service. In some systems such elements exist but to require such element being present to implement presence or to couple messaging service to presence may not make that much sense. > > > > Security is other issue. System should be able to associate HTTP > > requests to specific subscription or to specific user. Also > if CI is > > done in some other domain than subscriber's own this issue > gets more > > complicated. > > I would propose that security for indirection needs to be > equivalently > good (or bad) to without indirection. With indirection, if I can > eavesdrop, I can get the content, unless its e2e encrypted or > goes over > encrypted links. > > Now, if the CI URI is cryptographically random, it turns out the same > holds true. You won't be able to guess the URI. To find it out, you'd > have to be able to eavesdrop. Of course, if you could eavesdrop, you > could obtain the content even if there were no indirection. > If the URI > is protected e2e with encryption, or goes over secure links, you will > get good security. > > So, AFAICT, security of indirection can be the same for > inline content > so long as the URI are intelligently chosen. > > > > > One issue relates to usability. If you really want to > utilize CI user > > should always be prompted to make decision whether content > should be > > downloaded or not. If these changes happen often user may > be prompted > > quite frequently (for example every 5 minutes) to make > decision about > > content downloading. This is not very usable ad for example > for flat > > rate charging it does not make much sense. > > One feature of indirection is that it indicates when its changed. So, > you would know only to download the content in those cases. Exactly and if it changes frequently then you are prompted as frequently. Also using CI user really have no means to make decision whether to fetch the content or not. What I mean is that user sees the URL but cannot really know if he/she would be interested in this content until it is fetched. > > I have problem with partial notifications. I dont mind > developing a spec > for them either. However, I think their need is greatly > overestimated, > and it will buy you far less than you think for the complexity it > introduces. This is fair. However, reading your mail I couldn't find any of these complexities. Could you be more specific what you think causes this complexity. As the partial notification mechanism is largely based on same mechanism as winfo is PS and UAs should already (if they support winfo) have means to handle partial notifications. Regards - Mikko > -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Feb 1 05:01:19 2003 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03333 for ; Sat, 1 Feb 2003 05:01: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 h11A2jsa021789 for ; Sat, 1 Feb 2003 05:02:45 -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 FAA22279 for ; Sat, 1 Feb 2003 05:04:22 -0500 (EST) Date: Sat, 1 Feb 2003 05:04:22 -0500 (EST) Message-Id: <200302011004.FAA22279@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 mailnull@www1.ietf.org Mon Feb 3 06:48:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03809 for ; Mon, 3 Feb 2003 06:48:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13Brbg14518 for simple-archive@odin.ietf.org; Mon, 3 Feb 2003 06:53:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13BrbJ14512 for ; Mon, 3 Feb 2003 06:53:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03770 for ; Mon, 3 Feb 2003 06:48:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13BrWJ14466; Mon, 3 Feb 2003 06:53:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13Bo9J14237 for ; Mon, 3 Feb 2003 06:50:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03505; Mon, 3 Feb 2003 06:44:42 -0500 (EST) Message-Id: <200302031144.GAA03505@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-10.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Feb 2003 06:44:42 -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 : A Presence Event Package for the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-10.txt Pages : 27 Date : 2003-1-31 This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. 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 presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-10.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-10.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-10.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: <2003-1-31143022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-31143022.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 3 06:48:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03822 for ; Mon, 3 Feb 2003 06:48:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13Breg14537 for simple-archive@odin.ietf.org; Mon, 3 Feb 2003 06:53:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13BreJ14534 for ; Mon, 3 Feb 2003 06:53:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03774 for ; Mon, 3 Feb 2003 06:48:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13BraJ14484; Mon, 3 Feb 2003 06:53:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13BoFJ14246 for ; Mon, 3 Feb 2003 06:50:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03524; Mon, 3 Feb 2003 06:44:48 -0500 (EST) Message-Id: <200302031144.GAA03524@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-package-05.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Feb 2003 06:44:47 -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 : A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-simple-winfo-package-05.txt Pages : 20 Date : 2003-1-31 This document defines the watcher information template-package for the SIP event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-package-05.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-winfo-package-05.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-winfo-package-05.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: <2003-1-31143031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-winfo-package-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-winfo-package-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-31143031.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 3 06:48:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03824 for ; Mon, 3 Feb 2003 06:48:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13Breo14553 for simple-archive@odin.ietf.org; Mon, 3 Feb 2003 06:53:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13BreJ14550 for ; Mon, 3 Feb 2003 06:53:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03776 for ; Mon, 3 Feb 2003 06:48:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13BrbJ14500; Mon, 3 Feb 2003 06:53:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13BoJJ14251 for ; Mon, 3 Feb 2003 06:50:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03555; Mon, 3 Feb 2003 06:44:52 -0500 (EST) Message-Id: <200302031144.GAA03555@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-format-04.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Feb 2003 06:44:52 -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 : An Extensible Markup Language (XML) Based Format for Watcher Information Author(s) : J. Rosenberg Filename : draft-ietf-simple-winfo-format-04.txt Pages : 14 Date : 2003-1-31 Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes an XML document format for such state. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-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-winfo-format-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-winfo-format-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: <2003-1-31143042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-winfo-format-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-winfo-format-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-31143042.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 3 10:29:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10377 for ; Mon, 3 Feb 2003 10:29:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13FYDE29749 for simple-archive@odin.ietf.org; Mon, 3 Feb 2003 10:34:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13FYDJ29746 for ; Mon, 3 Feb 2003 10:34:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10372 for ; Mon, 3 Feb 2003 10:28:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13FY7J29736; Mon, 3 Feb 2003 10:34:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13FY0J29722 for ; Mon, 3 Feb 2003 10:34:00 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10364 for ; Mon, 3 Feb 2003 10:28:26 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h13FW6YH014504; Mon, 3 Feb 2003 10:32:06 -0500 (EST) Message-ID: <3E3E8B72.4030808@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] New I-Ds on partial notification References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1D7FD@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Feb 2003 10:32:02 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. mikko.lonnfors@nokia.com wrote: >>Such a differentiated charging model for content opens the door for >>fraud. If sending content through presence is free, but costs money >>other ways, won't users just always send content through presence? > > > I didn't want to imply that it would be free. Points was that operators > would like to implement service based charging for some services. For > example without signaling context being free users would have to pay for > unanswered calls. That doesnt change the point here. If transfer of content within presence is covered as part of my fee for the service, but fetching of content outside of it costs money, then users will end up generally sending content through the presence service because its cheaper. Anyway, if you do wish to do such a thing, and you are using the PDP conext to flag what is byte-metered vs. what is not, the real problem is that you can only bind a PDP context to a single protocol. Many protocols and operations may be involved in providing a service. That is the root cause problem. Designing application protocols to fit the packet metering methodology is not. > > >>>CI requires some storage where content should be places until its >>>fetched or it expires. This box then needs to maintained >> >>and connected >> >>>to existing network elements like PS. This may be >> >>unnecessary overhead >> >>>for some systems. >> >>No doubt this is extra infrastructure to maintain. However, >>such things >>will frequently exist anyway (i.e., MMSC provides a similar function). > > > MMSC (Multimedia Messaging Service Centre) is network element used in > messaging service. In some systems such elements exist but to require > such element being present to implement presence or to couple messaging > service to presence may not make that much sense. If you are not using messaging, you can get something else that provides the function that is not an mmsc. Repositories for content are not hard to come by. >>One feature of indirection is that it indicates when its changed. So, >>you would know only to download the content in those cases. > > > Exactly and if it changes frequently then you are prompted as > frequently. Also using CI user really have no means to make decision > whether to fetch the content or not. What I mean is that user sees the > URL but cannot really know if he/she would be interested in this content > until it is fetched. I doubt that is true. The indirections contain meta-data, such as size and type. Many of the PC-based IM programs prompt the user with this meta-data before files are accepted. Indeed, content indirection is the core of MMS. Content is NEVER sent directly to the recipient! Are you really trying to say that you dont think recipients should be given a choice about downloading large content?? > > >>I have problem with partial notifications. I dont mind >>developing a spec >>for them either. However, I think their need is greatly >>overestimated, >>and it will buy you far less than you think for the complexity it >>introduces. > > > This is fair. However, reading your mail I couldn't find any of these > complexities. Could you be more specific what you think causes this > complexity. As the partial notification mechanism is largely based on > same mechanism as winfo is PS and UAs should already (if they support > winfo) have means to handle partial notifications. Yes, it is the same as winfo, more or less. The complexity there is the need for the UA to handle partial information, ask for full-state updates, and for the server to deal with this as well. Its not hard, but it requires code and specifications to do. The point I have been trying to make is that I believe you need content indirection in either case, and so the benefits of the partial notifications are quite small, IMHO, not big enough to outweigh the work they introduce. -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 3 12:52:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14944 for ; Mon, 3 Feb 2003 12:52:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13HvOp09379 for simple-archive@odin.ietf.org; Mon, 3 Feb 2003 12:57:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13HvNJ09376 for ; Mon, 3 Feb 2003 12:57:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14937 for ; Mon, 3 Feb 2003 12:51:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13Hv9J09361; Mon, 3 Feb 2003 12:57:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13HuOJ09324 for ; Mon, 3 Feb 2003 12:56:24 -0500 Received: from nycsmtp1out.rdc-nyc.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14926 for ; Mon, 3 Feb 2003 12:50:47 -0500 (EST) Received: from BOBDEV (66-108-193-77.nyc.rr.com [66.108.193.77]) by nycsmtp1out.rdc-nyc.rr.com (8.12.1/Road Runner SMTP Server 1.0) with ESMTP id h13HsLwr023898 for ; Mon, 3 Feb 2003 12:54:21 -0500 (EST) Reply-To: From: "Bob Wyman" To: Message-ID: <006601c2cbad$4ab43520$6401a8c0@BOBDEV> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C2CB83.61DE2D20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: [Simple] USPTO Instant Messaging patent applications published 30-Jan-2003 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 Feb 2003 12:54:26 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C2CB83.61DE2D20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below, you'll find a summary of some of the new patent applications concerning Instant Messaging and related areas that were published on 30-Jan-2003 (i.e.last Thursday). It is likely that if one or more of these applications are granted, that they may have impact on the utility of the features, etc. that are being incorporated into SIMPLE. It is interesting to note in this week's collection the emergence of Microsoft's attempts to pin down its .NET services as well as the continuing strong interest on IBM's part in locking up IM related patents (There were at least 8 IBM applications published just last week!). =20 More information on these applications and others like them will be made available on http://www.pubsub.org/ . Your comments are welcomed. bob wyman 20030023623 Schema-based service for identity-based access to presence data US Patent Application 20030023623 Published: = 30-Jan-2003 One of a number of applications, apparently by Microsoft, claiming key elements of .NET services such as .NET My Services, .NET Presence, .NET Identity, etc. The basic claim here is on providing access to information in a form which is application independent. (i.e. generic data encoding using XML with a schema)=20 20030023850 Verifying messaging sessions by digital signatures of participants IM US Patent Application 20030023850 Published: = 30-Jan-2003 IBM claims the use of digital signatures to identify participants in an IM session. Claim 1 relates to digital signatures that are stored in a recorded IM session, while other independent claims, including claims 27 and 31 expand the scope to include the use and verification of digital signatures in "real-time". Applying digital signatures in IM systems is certainly "useful," however, it is undoubtedly "obvious" that this technology would be used by IM systems. Digital signature technology was developed to provide a means to identify any bit of digital data. The use of signatures here is simply one use of the many uses that were anticipated by the original idea of having signatures. 20030020750 Specifying messaging session subject preferences US Patent Application 20030020750 Published: = 30-Jan-2003 IBM claims a system of "filtering" or monitoring a number of IM channels or topics and "when a conversation thread about a subject preferences in a messaging session is initiated or in progress, a user is notified of that channel, topic and message entry." The claims expand the base idea of monitoring based on subject to also include notifications based on "activity level", notifying users of new channels or threads that match subject preferences, and providing a graphical interface for defining a user's subject preferences.=20 20030023689 Editing messaging sessions for a record US Patent Application 20030023689 Published: = 30-Jan-2003 In one of a number of applications dealing with recorded IM sessions, IBM claims a process which allows "users participating in a messaging session to edit their own entries and allow other users to acknowledge the edited entries for the record and replicate the record for each participant."=20 This ability to "revise and extend" comments would be familiar to anyone who has ever read the "Congressional Record"...=20 20030023684 Individually specifying message output attributes in a messaging system US Patent Application 20030023684 Published: = 30-Jan-2003 IBM claims a system of associating rules with instant messages to modify their handling. These rules would do things like change the text color of a message based on the sender identity or topic, filter messages, or to create "virtual subtopics" by splitting up messages sent to one topic into a number of subtopics. The type of "output attributes" covered will be familiar to users of email systems like Outlook Express that allow you to change the text font, color, etc. of entries in your folders based on sender name or that allow you to filter messages into different folders. Claim 33 and others expands the scope of the application to handle methods of processing requests for new discussion topics. Claim 51 and others expand the scope to cover graphical means for selecting the topic to which a message should be sent.=20 20030023683 Notifying users when messaging sessions are recorded US Patent Application 20030023683 Published: = 30-Jan-2003 IBM claims a method, system and program for notifying users participating in a messaging session when that messaging session, or part of it, is being recorded and allowing users to authorize the recording or adjust the "output attributes" of recorded sessions or messages.=20 20030023682 Watermarking messaging sessions US Patent Application 20030023682 Published: = 30-Jan-2003 IBM claims the process of watermarking messaging sessions such that the origin of recorded messaging sessions is traceable. The claims broaden to include the watermarking of individual messages in "real-time" so that their origins can be detected whether or not stored in a session recording. 20030023681 Sharing messaging device information among network users US Patent Application 20030023681 Published: = 30-Jan-2003 IBM claims a system by which participants in a messaging session can become aware of the devices used by others and of the limitations or capabilities of those devices. The idea is that if you know that someone is using a PDA in a session, you might tend not to send large messages...=20 20030021416 Encrypting a messaging session with a symmetric key US Patent Application 20030021416 Published: = 30-Jan-2003 IBM claims the most basic use of PKI in an IM session. It is difficult to say much about this application other than to question if there is any other rational way of encrypting an IM session. What they have applied for is so obvious that it is almost painful to read the application. 20030023690 Method and apparatus for providing selective delivery of notifications to users of multiple devices over a network US Patent Application 20030023690 Published: = 30-Jan-2003 Claims the use of presence information to determine to which of a plurarity of user's devices notifications and messages should be sent. (i.e. claims one of the basic and most commonly discussed reason for having presence data). Later claims expand the basic idea to include working through a list of devices on which presence information indicates the user is available until an acknowledgement is received. 20030021403 Passive call blocking method and apparatus US Patent Application 20030021403 Published: = 30-Jan-2003 Claims a system that allows you to do "call blocking" by generating a false "ringing" signal rather than explicitly stating that the call has been blocked. This is the "gentle" way to reject a call. Makes specific reference to SIP and thus constrains SIMPLE. A broadly based claim could cause problems for Jabber and other IM systems as well...=20 20030021264 Call transfer using session initiation protocol (SIP) US Patent Application 20030021264 Published: = 30-Jan-2003 Claims SIP based call transfer based on Presence information.=20 20030023754 Method and system for adding real-time, interactive functionality to a web-page US Patent Application 20030023754 Published: = 30-Jan-2003 Seems to claim the idea of IM on a web page. The process claimed "enables interaction between and among a plurality of users viewing the same web-page." I find it difficult to distinguish what is claimed here from the many existing examples of systems that allow people to have discussions on web pages or talk about web pages. 20030023736 Method and system for filtering messages=20 US Patent Application 20030023736 Published: = 30-Jan-2003 Claims a general method of filtering messages based on an authorization scheme. The "authorization" here seems to include "white lists" and "black lists" based on senders' identity or on content in messages. The only twist here is that it provides a way to tell someone how to generate a message that will be accepted. For instance, it would allow you to insist that a user must "pay" in order to have their messages received. In this way, it is very much like the " interrupt token" idea that was proposed by Scott Fahlman of IBM and others. 20030023679 System and process for network collaboration through embedded annotation and rendering instructions US Patent Application 20030023679 Published: = 30-Jan-2003 Claims a system of network collaboration through embedded annotation, etc.. Basically, like WEBDAV. Specifically claims "the present invention is usable with other forms of message or content transmission, e.g., file transfer protocol, telnet, chat, or instant messaging"=20 20030023489 Method and system for providing network based target advertising US Patent Application 20030023489 Published: = 30-Jan-2003 Claims targeted ad delivery based on geographic location in web, SMS, instant messaging systems, etc. Expands on standard geo-based systems by claiming the process of determining whether or not the remote user is in the territory covered by a particular newspaper,=20 20030023427 Devices, methods and a system for implementing a media content delivery and playback scheme US Patent Application 20030023427 Published: = 30-Jan-2003 Claims a system in which media to be displayed is downloaded to the client asynchronously for later play-back. This is a patent on "pre-fetching" of content. The most common prior art is the "Updates" alert on many Microsoft desktops today. Also, this technique was used by many "media" advertising companies in the past.=20 20030021397 Policy based PC-to-phone text messaging for enterprise networks US Patent Application 20030021397 Published: = 30-Jan-2003 Claims a gateway between computer based messaging systems and PBX systems. It would cover systems that convert IM messages to messages sent via PBX systems and provide a method for establishing "policies" or rules defining which messages should be gatewayed and to which PBX connected phones.=20 20030021244 Methods and systems of blocking and/or disregarding data and related wireless terminals and wireless service providers US Patent Application 20030021244 Published: = 30-Jan-2003 Claims the use of "white lists" for authorizing or filtering messages sent to wireless devices. An attempt to claim a well known, obvious method simply by applying it to a new medium. 20030023854 System and method for screening incoming video communications within an interactive television system US Patent Application 20030023854 Published: = 30-Jan-2003 Claims the use of "white-lists" for authorizing and filtering video communications sent via interactive television systems. An attempt to claim a well known, obvious method simply by applying it to a new medium.=20 ------=_NextPart_000_0067_01C2CB83.61DE2D20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

      =  Below,=20 you'll find a summary of some of the new patent applications concerning = Instant=20 Messaging and related areas that were published  on 30-Jan-2003 = (i.e.last=20 Thursday). It is likely that if one or more of these applications are=20 granted, that they may have impact on the utility of the features, = etc.=20 that are being incorporated into SIMPLE.   It is interesting to note = in this=20 week's collection the emergence of Microsoft's attempts to pin down its = .NET=20 services as well as the continuing strong interest on IBM's part = in locking=20 up IM related patents (There were at least 8 IBM applications = published=20 just last week!).  
    More=20 information on these applications and others like them will be made = available on=20 http://www.pubsub.org/ = . Your=20 comments are welcomed.

        bob = wyman

20030023623 Schema-based = service for=20 identity-based access to presence data
US Patent Application=20 20030023623 Published: 30-Jan-2003
One of a number of applications, = apparently by=20 Microsoft, claiming key elements of .NET services such as .NET My = Services, .NET=20 Presence, .NET Identity, etc. The basic claim here is on providing = access to=20 information in a form which is application independent.  (i.e. = generic data=20 encoding using XML with a schema)

 20030023850 = Verifying messaging=20 sessions by digital signatures of participants IM
US Patent=20 Application 20030023850 Published: 30-Jan-2003
IBM claims the use of digital = signatures to=20 identify participants in an IM session. Claim 1 relates to digital = signatures=20 that are stored in a recorded IM session, while other independent = claims,=20 including claims 27 and 31 expand the scope to include the use and = verification=20 of digital signatures in "real-time". Applying digital signatures in IM = systems=20 is certainly "useful," however, it is undoubtedly "obvious" that this = technology=20 would be used by IM systems. Digital signature technology was developed = to=20 provide a means to identify any bit of digital data. The use of = signatures here=20 is simply one use of the many uses that were anticipated by the original = idea of=20 having signatures.

20030020750 Specifying = messaging=20 session subject preferences
US Patent Application = 20030020750 Published: 30-Jan-2003
IBM claims a system of "filtering" = or=20 monitoring a number of IM channels or topics and "when a conversation = thread=20 about a subject preferences in a messaging session is initiated or in = progress,=20 a user is notified of that channel, topic and message entry." The claims = expand=20 the base idea of monitoring based on subject to also include = notifications based=20 on "activity level", notifying users of new channels or threads that = match=20 subject preferences, and providing a graphical interface for defining a = user's=20 subject preferences.

20030023689 Editing = messaging=20 sessions for a record
US Patent Application 20030023689 Published: 30-Jan-2003
In one of a number of applications = dealing=20 with recorded IM sessions, IBM claims a process which allows "users=20 participating in a messaging session to edit their own entries and allow = other=20 users to acknowledge the edited entries for the record and replicate the = record=20 for each participant."
This ability to "revise and extend" comments = would be=20 familiar to anyone who has ever read the "Congressional Record"... =

20030023684 Individually = specifying=20 message output attributes in a messaging system
US Patent=20 Application 20030023684 Published: 30-Jan-2003
IBM claims a system of associating = rules with=20 instant messages to modify their handling. These rules would do things = like=20 change the text color of a message based on the sender identity or = topic, filter=20 messages, or to create "virtual subtopics" by splitting up messages sent = to one=20 topic into a number of subtopics. The type of "output attributes" = covered will=20 be familiar to users of email systems like Outlook Express that allow = you to=20 change the text font, color, etc. of entries in your folders based on = sender=20 name or that allow you to filter messages into different folders. Claim = 33 and=20 others expands the scope of the application to handle methods of = processing=20 requests for new discussion topics. Claim 51 and others expand the scope = to=20 cover graphical means for selecting the topic to which a message should = be sent.=20

20030023683 Notifying = users when=20 messaging sessions are recorded
US Patent Application=20 20030023683 Published: 30-Jan-2003
 IBM claims a method, system = and program=20 for notifying users participating in a messaging session when that = messaging=20 session, or part of it, is being recorded and allowing users to = authorize the=20 recording or adjust the "output attributes" of recorded sessions or = messages.=20

20030023682 Watermarking = messaging=20 sessions
US Patent Application 20030023682 Published: 30-Jan-2003
 IBM claims the process of = watermarking=20 messaging sessions such that the origin of recorded messaging sessions = is=20 traceable. The claims broaden to include the watermarking of individual = messages=20 in "real-time" so that their origins can be detected whether or not = stored in a=20 session recording.

20030023681 Sharing = messaging device=20 information among network users
US Patent Application=20 20030023681 Published: 30-Jan-2003
IBM claims a system by which = participants in a=20 messaging session can become aware of the devices used by others and of = the=20 limitations or capabilities of those devices. The idea is that if you = know that=20 someone is using a PDA in a session, you might tend not to send large=20 messages...

20030021416 Encrypting a = messaging=20 session with a symmetric key
US Patent Application = 20030021416 Published: 30-Jan-2003
IBM claims the most basic use of PKI = in an IM=20 session. It is difficult to say much about this application other than = to=20 question if there is any other rational way of encrypting an IM session. = What=20 they have applied for is so obvious that it is almost painful to read = the=20 application.

20030023690 Method and = apparatus for=20 providing selective delivery of notifications to users of multiple = devices over=20 a network
US Patent Application 20030023690 Published: 30-Jan-2003
Claims the use of presence = information to=20 determine to which of a plurarity of user's devices notifications and = messages=20 should be sent. (i.e. claims one of the basic and most commonly = discussed reason=20 for having presence data). Later claims expand the basic idea to include = working=20 through a list of devices on which presence information indicates the = user is=20 available until an acknowledgement is received.

20030021403 Passive call = blocking=20 method and apparatus
US Patent Application 20030021403 Published: 30-Jan-2003
Claims a system that allows you to = do "call=20 blocking" by generating a false "ringing" signal rather than explicitly = stating=20 that the call has been blocked. This is the "gentle" way to reject a = call. Makes=20 specific reference to SIP and thus constrains SIMPLE. A broadly based = claim=20 could cause problems for Jabber and other IM systems as well... =

20030021264 Call transfer = using=20 session initiation protocol (SIP)
US Patent Application=20 20030021264 Published: 30-Jan-2003
Claims SIP based call transfer based = on=20 Presence information.

20030023754 Method and = system for=20 adding real-time, interactive functionality to a web-page
US = Patent=20 Application 20030023754 Published: 30-Jan-2003
Seems to claim the idea of IM on a = web page.=20 The process claimed "enables interaction between and among a plurality = of users=20 viewing the same web-page." I find it difficult to distinguish what is = claimed=20 here from the many existing examples of systems that allow people to = have=20 discussions on web pages or talk about web pages.

20030023736 Method and = system for=20 filtering messages
US Patent Application 20030023736 Published: 30-Jan-2003
Claims a general method of filtering = messages=20 based on an authorization scheme. The "authorization" here seems to = include=20 "white lists" and "black lists" based on senders' identity or on content = in=20 messages. The only twist here is that it provides a way to tell someone = how to=20 generate a message that will be accepted. For instance, it would allow = you to=20 insist that a user must "pay" in order to have their messages received. = In this=20 way, it is very much like the "interrupt token" idea=20 that was proposed by Scott Fahlman of IBM and others.

20030023679 System and = process for=20 network collaboration through embedded annotation and rendering=20 instructions
US Patent Application 20030023679 Published: 30-Jan-2003
Claims a system of  network = collaboration=20 through embedded annotation, etc.. Basically, like WEBDAV. Specifically = claims=20 "the present invention is usable with other forms of message or content=20 transmission, e.g., file transfer protocol, telnet, chat, or instant = messaging"=20

20030023489 Method and = system for=20 providing network based target advertising
US Patent = Application=20 20030023489 Published: 30-Jan-2003
Claims targeted ad delivery based on = geographic location in web, SMS, instant messaging systems, etc. Expands = on=20 standard geo-based systems by claiming the process of determining = whether or not=20 the remote user is in the territory covered by a particular newspaper,=20

20030023427 Devices, = methods and a=20 system for implementing a media content delivery and playback=20 scheme
US Patent Application 20030023427 Published: 30-Jan-2003
Claims a system in which media to be = displayed=20 is downloaded to the client asynchronously for later play-back. This is = a patent=20 on "pre-fetching" of content. The most common prior art is the "Updates" = alert=20 on many Microsoft desktops today. Also, this technique was used by many = "media"=20 advertising companies in the past.

20030021397 Policy based = PC-to-phone=20 text messaging for enterprise networks
US Patent Application = 20030021397 Published: 30-Jan-2003
Claims a gateway between computer = based=20 messaging systems and PBX systems. It would cover systems that convert = IM=20 messages to messages sent via PBX systems and provide a method for = establishing=20 "policies" or rules defining which messages should be gatewayed and to = which PBX=20 connected phones.

20030021244 Methods and = systems of=20 blocking and/or disregarding data and related wireless terminals and = wireless=20 service providers
US Patent Application 20030021244 Published: 30-Jan-2003
Claims the use of  "white = lists" for=20 authorizing or filtering  messages sent to wireless devices. An = attempt to=20 claim a well known, obvious method simply by applying it to a new=20 medium.

20030023854 System and = method for=20 screening incoming video communications within an interactive television = system
US Patent Application 20030023854 Published: 30-Jan-2003
Claims the use of "white-lists" for=20 authorizing and filtering video communications sent via interactive = television=20 systems. An attempt to claim a well known, obvious method simply by = applying it=20 to a new medium.

------=_NextPart_000_0067_01C2CB83.61DE2D20-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 3 13:54:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17219 for ; Mon, 3 Feb 2003 13:54:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13IxPG15324 for simple-archive@odin.ietf.org; Mon, 3 Feb 2003 13:59:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13IxPJ15311 for ; Mon, 3 Feb 2003 13:59:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17195 for ; Mon, 3 Feb 2003 13:53:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13Ix9J15295; Mon, 3 Feb 2003 13:59:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13IwqJ15274 for ; Mon, 3 Feb 2003 13:58:52 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17162 for ; Mon, 3 Feb 2003 13:51:51 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h13Iu92q014255; Mon, 3 Feb 2003 13:56:09 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-85.cisco.com [161.44.87.85]) by cia.cisco.com (Mirapoint) with ESMTP id ABO27646; Mon, 3 Feb 2003 13:45:15 -0500 (EST) Message-Id: <4.3.2.7.2.20030203134721.00b3cfb8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Michael Hammer Subject: Re: [Simple] USPTO Instant Messaging patent applications published 30-Jan-2003 Cc: In-Reply-To: <006601c2cbad$4ab43520$6401a8c0@BOBDEV> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Feb 2003 13:55:14 -0500 Bob, With respect to having digital signatures of session participants and encrypting sessions of messages with symmetric keys, it would be interesting to compare the requirements and design of the Defense Message System developed in the early 1990's by the U.S. Government (Department of Defense) to these patents to determine if this was considered state of art or in public domain already. While DMS was focusing on securing e-mail, messages are messages. Mike At 12:54 PM 2/3/2003 -0500, Bob Wyman wrote: > Below, you'll find a summary of some of the new patent > applications concerning Instant Messaging and related areas that were > published on 30-Jan-2003 (i.e.last Thursday). It is likely that if one > or more of these applications are granted, that they may have impact on > the utility of the features, etc. that are being incorporated into > SIMPLE. It is interesting to note in this week's collection the > emergence of Microsoft's attempts to pin down its .NET services as well > as the continuing strong interest on IBM's part in locking up IM related > patents (There were at least 8 IBM applications published just last week!). > More information on these applications and others like them will be > made available on http://www.pubsub.org/ . Your > comments are welcomed. > > bob wyman > >20030023623 Schema-based service for identity-based access to presence data >US Patent Application >20030023623 >Published: 30-Jan-2003 >One of a number of applications, apparently by Microsoft, claiming key >elements of .NET services such as .NET My Services, .NET Presence, .NET >Identity, etc. The basic claim here is on providing access to information >in a form which is application independent. (i.e. generic data encoding >using XML with a schema) > > 20030023850 Verifying messaging sessions by digital signatures of > participants IM >US Patent Application >20030023850 >Published: 30-Jan-2003 >IBM claims the use of digital signatures to identify participants in an IM >session. Claim 1 relates to digital signatures that are stored in a >recorded IM session, while other independent claims, including claims 27 >and 31 expand the scope to include the use and verification of digital >signatures in "real-time". Applying digital signatures in IM systems is >certainly "useful," however, it is undoubtedly "obvious" that this >technology would be used by IM systems. Digital signature technology was >developed to provide a means to identify any bit of digital data. The use >of signatures here is simply one use of the many uses that were >anticipated by the original idea of having signatures. > >20030020750 Specifying messaging session subject preferences >US Patent Application >20030020750 >Published: 30-Jan-2003 >IBM claims a system of "filtering" or monitoring a number of IM channels >or topics and "when a conversation thread about a subject preferences in a >messaging session is initiated or in progress, a user is notified of that >channel, topic and message entry." The claims expand the base idea of >monitoring based on subject to also include notifications based on >"activity level", notifying users of new channels or threads that match >subject preferences, and providing a graphical interface for defining a >user's subject preferences. > >20030023689 Editing messaging sessions for a record >US Patent Application >20030023689 >Published: 30-Jan-2003 >In one of a number of applications dealing with recorded IM sessions, IBM >claims a process which allows "users participating in a messaging session >to edit their own entries and allow other users to acknowledge the edited >entries for the record and replicate the record for each participant." >This ability to "revise and extend" comments would be familiar to anyone >who has ever read the "Congressional Record"... > >20030023684 Individually specifying message output attributes in a >messaging system >US Patent Application >20030023684 >Published: 30-Jan-2003 >IBM claims a system of associating rules with instant messages to modify >their handling. These rules would do things like change the text color of >a message based on the sender identity or topic, filter messages, or to >create "virtual subtopics" by splitting up messages sent to one topic into >a number of subtopics. The type of "output attributes" covered will be >familiar to users of email systems like Outlook Express that allow you to >change the text font, color, etc. of entries in your folders based on >sender name or that allow you to filter messages into different folders. >Claim 33 and others expands the scope of the application to handle methods >of processing requests for new discussion topics. Claim 51 and others >expand the scope to cover graphical means for selecting the topic to which >a message should be sent. > >20030023683 Notifying users when messaging sessions are recorded >US Patent Application >20030023683 >Published: 30-Jan-2003 > IBM claims a method, system and program for notifying users > participating in a messaging session when that messaging session, or part > of it, is being recorded and allowing users to authorize the recording or > adjust the "output attributes" of recorded sessions or messages. > >20030023682 Watermarking messaging sessions >US Patent Application >20030023682 >Published: 30-Jan-2003 > IBM claims the process of watermarking messaging sessions such that the > origin of recorded messaging sessions is traceable. The claims broaden to > include the watermarking of individual messages in "real-time" so that > their origins can be detected whether or not stored in a session recording. > >20030023681 Sharing messaging device information among network users >US Patent Application >20030023681 >Published: 30-Jan-2003 >IBM claims a system by which participants in a messaging session can >become aware of the devices used by others and of the limitations or >capabilities of those devices. The idea is that if you know that someone >is using a PDA in a session, you might tend not to send large messages... > >20030021416 Encrypting a messaging session with a symmetric key >US Patent Application >20030021416 >Published: 30-Jan-2003 >IBM claims the most basic use of PKI in an IM session. It is difficult to >say much about this application other than to question if there is any >other rational way of encrypting an IM session. What they have applied for >is so obvious that it is almost painful to read the application. > >20030023690 Method and apparatus for providing selective delivery of >notifications to users of multiple devices over a network >US Patent Application >20030023690 >Published: 30-Jan-2003 >Claims the use of presence information to determine to which of a >plurarity of user's devices notifications and messages should be sent. >(i.e. claims one of the basic and most commonly discussed reason for >having presence data). Later claims expand the basic idea to include >working through a list of devices on which presence information indicates >the user is available until an acknowledgement is received. > >20030021403 Passive call blocking method and apparatus >US Patent Application >20030021403 >Published: 30-Jan-2003 >Claims a system that allows you to do "call blocking" by generating a >false "ringing" signal rather than explicitly stating that the call has >been blocked. This is the "gentle" way to reject a call. Makes specific >reference to SIP and thus constrains SIMPLE. A broadly based claim could >cause problems for Jabber and other IM systems as well... > >20030021264 Call transfer using session initiation protocol (SIP) >US Patent Application >20030021264 >Published: 30-Jan-2003 >Claims SIP based call transfer based on Presence information. > >20030023754 Method and system for adding real-time, interactive >functionality to a web-page >US Patent Application >20030023754 >Published: 30-Jan-2003 >Seems to claim the idea of IM on a web page. The process claimed "enables >interaction between and among a plurality of users viewing the same >web-page." I find it difficult to distinguish what is claimed here from >the many existing examples of systems that allow people to have >discussions on web pages or talk about web pages. > >20030023736 Method and system for filtering messages >US Patent Application >20030023736 >Published: 30-Jan-2003 >Claims a general method of filtering messages based on an authorization >scheme. The "authorization" here seems to include "white lists" and "black >lists" based on senders' identity or on content in messages. The only >twist here is that it provides a way to tell someone how to generate a >message that will be accepted. For instance, it would allow you to insist >that a user must "pay" in order to have their messages received. In this >way, it is very much like the >"interrupt token" >idea that was proposed by Scott Fahlman of IBM and others. > >20030023679 System and process for network collaboration through embedded >annotation and rendering instructions >US Patent Application >20030023679 >Published: 30-Jan-2003 >Claims a system of network collaboration through embedded annotation, >etc.. Basically, like WEBDAV. Specifically claims "the present invention >is usable with other forms of message or content transmission, e.g., file >transfer protocol, telnet, chat, or instant messaging" > >20030023489 Method and system for providing network based target advertising >US Patent Application >20030023489 >Published: 30-Jan-2003 >Claims targeted ad delivery based on geographic location in web, SMS, >instant messaging systems, etc. Expands on standard geo-based systems by >claiming the process of determining whether or not the remote user is in >the territory covered by a particular newspaper, > >20030023427 Devices, methods and a system for implementing a media content >delivery and playback scheme >US Patent Application >20030023427 >Published: 30-Jan-2003 >Claims a system in which media to be displayed is downloaded to the client >asynchronously for later play-back. This is a patent on "pre-fetching" of >content. The most common prior art is the "Updates" alert on many >Microsoft desktops today. Also, this technique was used by many "media" >advertising companies in the past. > >20030021397 Policy based PC-to-phone text messaging for enterprise networks >US Patent Application >20030021397 >Published: 30-Jan-2003 >Claims a gateway between computer based messaging systems and PBX systems. >It would cover systems that convert IM messages to messages sent via PBX >systems and provide a method for establishing "policies" or rules defining >which messages should be gatewayed and to which PBX connected phones. > >20030021244 Methods and systems of blocking and/or disregarding data and >related wireless terminals and wireless service providers >US Patent Application >20030021244 >Published: 30-Jan-2003 >Claims the use of "white lists" for authorizing or filtering messages >sent to wireless devices. An attempt to claim a well known, obvious method >simply by applying it to a new medium. > >20030023854 System and method for screening incoming video communications >within an interactive television system >US Patent Application >20030023854 >Published: 30-Jan-2003 >Claims the use of "white-lists" for authorizing and filtering video >communications sent via interactive television systems. An attempt to >claim a well known, obvious method simply by applying it to a new medium. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 3 19:04:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25771 for ; Mon, 3 Feb 2003 19:04:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1409HQ04498 for simple-archive@odin.ietf.org; Mon, 3 Feb 2003 19:09:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1409HJ04495 for ; Mon, 3 Feb 2003 19:09:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25756 for ; Mon, 3 Feb 2003 19:03:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1409CJ04487; Mon, 3 Feb 2003 19:09:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1408WJ04462 for ; Mon, 3 Feb 2003 19:08:32 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25738 for ; Mon, 3 Feb 2003 19:02:49 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h14090m15479 for ; Tue, 4 Feb 2003 02:09:00 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Feb 2003 02:06:23 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 02:06:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] New I-Ds on partial notification Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD21C@esebe013.ntc.nokia.com> Thread-Topic: [Simple] New I-Ds on partial notification Thread-Index: AcLLmZD0wtc2nfcsQDyOgUU6S1GWowAJaDyA To: , Cc: X-OriginalArrivalTime: 04 Feb 2003 00:06:23.0300 (UTC) FILETIME=[40ADB040:01C2CBE1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1408WJ04463 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Feb 2003 02:06:22 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Comments inline. > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >>Such a differentiated charging model for content opens the door for > >>fraud. If sending content through presence is free, but costs money > >>other ways, won't users just always send content through presence? > > > > > > I didn't want to imply that it would be free. Points was > that operators > > would like to implement service based charging for some > services. For > > example without signaling context being free users would > have to pay for > > unanswered calls. > > That doesnt change the point here. If transfer of content within > presence is covered as part of my fee for the service, but > fetching of > content outside of it costs money, then users will end up generally > sending content through the presence service because its cheaper. But the scope of this problem extends way past any protocol issues. It is down to the service offering to balance the charging model appropriately, so that the above scenario doesn't occur. The opposite could also easily happen; if CI'd content was too expensive to fetch, people wouldn't go and fetch it at all. > Anyway, if you do wish to do such a thing, and you are using the PDP > conext to flag what is byte-metered vs. what is not, the real > problem is > that you can only bind a PDP context to a single protocol. Many > protocols and operations may be involved in providing a > service. That is > the root cause problem. Designing application protocols to fit the > packet metering methodology is not. But I don't know if Mikko meant exactly that. I guess the problem wrt presence is that you can't easily e.g., differentiate the presence-originated HTTP traffic for CI from other similar traffic and this reduces the number of available options in creating the charging models. However, I'm more concerned about the security implications. Firstly, "transferring" the watcher-PS security association to CI doesn't seem trivial. This of course depends on the security model, but for example, any model where presence authorization is based on asserted identities has some difficulty in authorizing CI. Secondly, I'm worried about performance in cases where the watcher needs to do CI fetching securely. For example, if a client sits behind a persistent TCP/TLS connection to a proxy and receives all notifications via that connection, doing a lot of HTTPS-sessions for CI on the side seems like a pretty big penalty. > >>>CI requires some storage where content should be places until its > >>>fetched or it expires. This box then needs to maintained > >> > >>and connected > >> > >>>to existing network elements like PS. This may be > >> > >>unnecessary overhead > >> > >>>for some systems. > >> > >>No doubt this is extra infrastructure to maintain. However, > >>such things > >>will frequently exist anyway (i.e., MMSC provides a similar > function). > > > > > > MMSC (Multimedia Messaging Service Centre) is network > element used in > > messaging service. In some systems such elements exist but > to require > > such element being present to implement presence or to > couple messaging > > service to presence may not make that much sense. > > If you are not using messaging, you can get something else > that provides > the function that is not an mmsc. Repositories for content > are not hard > to come by. Rather than the availability of appropriate repositories, isn't the problem really that publishing that content is not standardized. It seems odd that publishing CI is not on our agenda, but publishing presence is. They seem to be parts of the same problem here, since we can't have one without the other. [snip] > >>I have problem with partial notifications. I dont mind > >>developing a spec > >>for them either. However, I think their need is greatly > >>overestimated, > >>and it will buy you far less than you think for the complexity it > >>introduces. > > > > > > This is fair. However, reading your mail I couldn't find > any of these > > complexities. Could you be more specific what you think causes this > > complexity. As the partial notification mechanism is > largely based on > > same mechanism as winfo is PS and UAs should already (if > they support > > winfo) have means to handle partial notifications. > > Yes, it is the same as winfo, more or less. The complexity > there is the > need for the UA to handle partial information, ask for full-state > updates, and for the server to deal with this as well. Its > not hard, but > it requires code and specifications to do. The point I have > been trying > to make is that I believe you need content indirection in > either case, > and so the benefits of the partial notifications are quite > small, IMHO, > not big enough to outweigh the work they introduce. I agree that the issues seen with CI need to be solved anyway, because the mechanism will anyway be needed e.g. in messaging. It's then a different question that if the implied problems in security, charging and storage were solved, would we even have partial notification on the table? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Feb 4 02:56:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13309 for ; Tue, 4 Feb 2003 02:56:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1482C806066 for simple-archive@odin.ietf.org; Tue, 4 Feb 2003 03:02:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1482CJ06063 for ; Tue, 4 Feb 2003 03:02:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13293 for ; Tue, 4 Feb 2003 02:56:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14829J06055; Tue, 4 Feb 2003 03:02:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1481tJ06023 for ; Tue, 4 Feb 2003 03:01:55 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13283 for ; Tue, 4 Feb 2003 02:56:02 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h147xbKV017993; Tue, 4 Feb 2003 08:59:37 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 4 Feb 2003 08:59:37 +0100 Message-ID: From: "Peter Hedman (EMP)" To: "'aki.niemi@nokia.com'" , jdrosen@dynamicsoft.com, mikko.lonnfors@nokia.com Cc: simple@ietf.org Subject: RE: [Simple] New I-Ds on partial notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Feb 2003 08:59:54 +0100 Hi, Agree that the issues with CI needs to be solved, but IMHO partial notifications will anyway be useful as the Presence info includes location info that may change often and the mechanism might even be one step towards accepting usage of S/MIME to protect Presence info considering the usage of SigComp in 3GPP. Also, the mechanism seem to be backward compatible i.e. the UA don't need to support it. Also, I assume the first NOTIFY per SUBSCRIBE will contain full state i.e. normally no need to explicitly request for full state update. It is true that the mechanism need to be specified, but the new draft seems to be a reasonable approach. BR, Peter > > > > > > This is fair. However, reading your mail I couldn't find > > any of these > > > complexities. Could you be more specific what you think > causes this > > > complexity. As the partial notification mechanism is > > largely based on > > > same mechanism as winfo is PS and UAs should already (if > > they support > > > winfo) have means to handle partial notifications. > > > > Yes, it is the same as winfo, more or less. The complexity > > there is the > > need for the UA to handle partial information, ask for full-state > > updates, and for the server to deal with this as well. Its > > not hard, but > > it requires code and specifications to do. The point I have > > been trying > > to make is that I believe you need content indirection in > > either case, > > and so the benefits of the partial notifications are quite > > small, IMHO, > > not big enough to outweigh the work they introduce. > > I agree that the issues seen with CI need to be solved > anyway, because the mechanism will anyway be needed e.g. in > messaging. It's then a different question that if the implied > problems in security, charging and storage were solved, would > we even have partial notification on the table? > > Cheers, > Aki > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Feb 4 03:15:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13708 for ; Tue, 4 Feb 2003 03:15:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h148L9b07506 for simple-archive@odin.ietf.org; Tue, 4 Feb 2003 03:21:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h148L8J07503 for ; Tue, 4 Feb 2003 03:21:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13677 for ; Tue, 4 Feb 2003 03:15:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h148L5J07493; Tue, 4 Feb 2003 03:21:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h148KqJ07470 for ; Tue, 4 Feb 2003 03:20:52 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13670 for ; Tue, 4 Feb 2003 03:14:58 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h148HT202551 for ; Tue, 4 Feb 2003 10:17:29 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Feb 2003 10:18:33 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 10:17:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] New I-Ds on partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF1041D5@esebe004.ntc.nokia.com> Thread-Topic: [Simple] New I-Ds on partial notification Thread-Index: AcLMI2HayBzHm3zjRKG42JtafoySfgAAa/wA To: , , Cc: X-OriginalArrivalTime: 04 Feb 2003 08:17:58.0925 (UTC) FILETIME=[ED70E3D0:01C2CC25] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h148KqJ07471 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Feb 2003 10:17:58 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, inline > > Hi, > > Agree that the issues with CI needs to be solved, but IMHO > partial notifications will anyway be useful as the Presence > info includes location info that may change often and the > mechanism might even be one step towards accepting usage of > S/MIME to protect Presence info considering the usage of > SigComp in 3GPP. > > Also, the mechanism seem to be backward compatible i.e. the > UA don't need to support it. Yes, this is true. > Also, I assume the first NOTIFY > per SUBSCRIBE will contain full state i.e. normally no need > to explicitly request for full state update. First NOTIFY will contain full state. I guess what Jonathan referred to with full state update was that if UA for some reason misses one notification (carrying partial info) UA must then fetch full presence state to construct coherent presence state. This should not normally happen but this needs to be specified in any case. Same applies also to winfo. BR - Mikko > It is true that the mechanism need to be specified, but the > new draft seems to be a reasonable approach. > > BR, > Peter > > > > > > > > > This is fair. However, reading your mail I couldn't find > > > any of these > > > > complexities. Could you be more specific what you think > > causes this > > > > complexity. As the partial notification mechanism is > > > largely based on > > > > same mechanism as winfo is PS and UAs should already (if > > > they support > > > > winfo) have means to handle partial notifications. > > > > > > Yes, it is the same as winfo, more or less. The complexity > > > there is the > > > need for the UA to handle partial information, ask for full-state > > > updates, and for the server to deal with this as well. Its > > > not hard, but > > > it requires code and specifications to do. The point I have > > > been trying > > > to make is that I believe you need content indirection in > > > either case, > > > and so the benefits of the partial notifications are quite > > > small, IMHO, > > > not big enough to outweigh the work they introduce. > > > > I agree that the issues seen with CI need to be solved > > anyway, because the mechanism will anyway be needed e.g. in > > messaging. It's then a different question that if the implied > > problems in security, charging and storage were solved, would > > we even have partial notification on the table? > > > > Cheers, > > Aki > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Feb 4 16:47:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05353 for ; Tue, 4 Feb 2003 16:47:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14LqkE26355 for simple-archive@odin.ietf.org; Tue, 4 Feb 2003 16:52:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LqjJ26352 for ; Tue, 4 Feb 2003 16:52:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05328 for ; Tue, 4 Feb 2003 16:46:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LqYJ26341; Tue, 4 Feb 2003 16:52:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LpVJ26263 for ; Tue, 4 Feb 2003 16:51:31 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05292 for ; Tue, 4 Feb 2003 16:45:21 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h14Lmwkx011517 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 4 Feb 2003 16:48:59 -0500 (EST) Message-ID: <3E40355F.1060503@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] RPIDS: extensions to PIDF Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 Feb 2003 16:49:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Based on the discussion on this list, we prepared an initial draft to provide a possible approach. Until it appears in the official archives, the draft can be found at http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-simple-rpids-00.pdf http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-simple-rpids-00.txt Comments are appreciated. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 5 06:06:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17326 for ; Wed, 5 Feb 2003 06:06:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15BCeL14989 for simple-archive@odin.ietf.org; Wed, 5 Feb 2003 06:12:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BCeJ14986 for ; Wed, 5 Feb 2003 06:12:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17315 for ; Wed, 5 Feb 2003 06:06:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BCbJ14977; Wed, 5 Feb 2003 06:12:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BBOJ14930 for ; Wed, 5 Feb 2003 06:11:24 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17281 for ; Wed, 5 Feb 2003 06:04:58 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h15B8bJ10692 for ; Wed, 5 Feb 2003 11:08:37 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Feb 2003 06:08:50 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214D95@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "Simpletons (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] PUBLISH: a dialog? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Feb 2003 06:08:49 -0500 The SIMPLE minutes reflect a consensus in the room at IETF 55 that the PUBLISH method should initiate a dialog. In preparation for a revision of the PUBLISH document, this matter merits some further discussion. Some identifiers associated with publication persist beyond the scope of a particular SIP transaction. For example, it is useful for a compositor to know that a set of PUBLISH requests all came from the same device, and to know the order in which they were sent. It may also be desirable to let one device overwrite presence information that was published by a different device, which entails some shared identifiers outside the context of a dialog. draft-olson-simple-publish-01 contains a Stream header that provides a longer-term identifier than the ordinary instance identification methods of a dialog (the tags in the To and From headers and the Call-ID). It has also been argued that the sequencing of publications need not rely on something like a CSeq header, since the Date header or something internal to the presence information body (for example, the element in PIDF bodies) could provide temporal ordering information. For these reasons, draft-olson-simple-publish-01 states that PUBLISH does not establish a dialog. However, it isn't clear today if it is necessary to have a longer-term identifier in the headers of the PUBLISH method, considering that the presence information itself may contain its own identifiers (like the tuple ID in PIDF) that could be reused as needed (such as the case in which one device overwrites presence published by another). When we were first working on PUBLISH, we were influenced by a use case in which a presence compositor combined presence documents without actually reading their contents (perhaps because the presence information is encrypted, or the documents used a format that the compositor didn't understand), which would argue that the longer-term identifier used by the compositor should not be placed in the presence information itself. Ultimately, this use case might not be that significant, though; a compositor that cannot understand presence information might not be able to do its job for unrelated reasons. If at all possible, we should avoid authoring a new header that establishes a pseudo-dialog - REGISTER has taught us that creating a one-off from the dialog model is ill advised. So, we'd like some opinions on this. Should PUBLISH initiate a dialog, and use traditional dialog identifiers instead of the existing Stream header? Jon Peterson NeuStar, Inc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 5 09:10:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25756 for ; Wed, 5 Feb 2003 09:10:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15EGUI27538 for simple-archive@odin.ietf.org; Wed, 5 Feb 2003 09:16:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EGUJ27534 for ; Wed, 5 Feb 2003 09:16:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25738 for ; Wed, 5 Feb 2003 09:10:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EGQJ27523; Wed, 5 Feb 2003 09:16:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EFTJ27489 for ; Wed, 5 Feb 2003 09:15:29 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25716 for ; Wed, 5 Feb 2003 09:09:00 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15EDTDB025784; Wed, 5 Feb 2003 09:13:30 -0500 (EST) Received: from cisco.com (dhcp-64-102-99-135.cisco.com [64.102.99.135]) by cannon.cisco.com (Mirapoint) with ESMTP id AAZ15446; Wed, 5 Feb 2003 09:17:40 -0500 (EST) Message-ID: <3E411BD4.8060401@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "Simpletons (E-mail)" Subject: Re: [Simple] PUBLISH: a dialog? References: <15A2739B7DAA624D8091C65981D7DA8101214D95@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Feb 2003 09:12:36 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon, You seem to have made a case that neither an actual dialog nor a pseudo-dialog is needed - that presence publications can be taken at face value as the arrive, regardless of source. If so, then the only reason for a dialog might be an efficiency issue - to establish the path between the publisher and the compositor once. Is that a good enough reason? If so, could it be optional? (E.g. the PUBLISH might simply be permitted to piggyback on some existing dialog, without being dialog establishing.) Paul Peterson, Jon wrote: > The SIMPLE minutes reflect a consensus in the room at IETF 55 that the > PUBLISH method should initiate a dialog. In preparation for a revision of > the PUBLISH document, this matter merits some further discussion. > > Some identifiers associated with publication persist beyond the scope of a > particular SIP transaction. For example, it is useful for a compositor to > know that a set of PUBLISH requests all came from the same device, and to > know the order in which they were sent. It may also be desirable to let one > device overwrite presence information that was published by a different > device, which entails some shared identifiers outside the context of a > dialog. > > draft-olson-simple-publish-01 contains a Stream header that provides a > longer-term identifier than the ordinary instance identification methods of > a dialog (the tags in the To and From headers and the Call-ID). It has also > been argued that the sequencing of publications need not rely on something > like a CSeq header, since the Date header or something internal to the > presence information body (for example, the element in PIDF > bodies) could provide temporal ordering information. For these reasons, > draft-olson-simple-publish-01 states that PUBLISH does not establish a > dialog. > > However, it isn't clear today if it is necessary to have a longer-term > identifier in the headers of the PUBLISH method, considering that the > presence information itself may contain its own identifiers (like the tuple > ID in PIDF) that could be reused as needed (such as the case in which one > device overwrites presence published by another). When we were first working > on PUBLISH, we were influenced by a use case in which a presence compositor > combined presence documents without actually reading their contents (perhaps > because the presence information is encrypted, or the documents used a > format that the compositor didn't understand), which would argue that the > longer-term identifier used by the compositor should not be placed in the > presence information itself. Ultimately, this use case might not be that > significant, though; a compositor that cannot understand presence > information might not be able to do its job for unrelated reasons. If at all > possible, we should avoid authoring a new header that establishes a > pseudo-dialog - REGISTER has taught us that creating a one-off from the > dialog model is ill advised. > > So, we'd like some opinions on this. Should PUBLISH initiate a dialog, and > use traditional dialog identifiers instead of the existing Stream header? > > Jon Peterson > NeuStar, Inc. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 5 10:46:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28974 for ; Wed, 5 Feb 2003 10:46:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15FqYB01415 for simple-archive@odin.ietf.org; Wed, 5 Feb 2003 10:52:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15FqXJ01412 for ; Wed, 5 Feb 2003 10:52:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28958 for ; Wed, 5 Feb 2003 10:46:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15FqSJ01402; Wed, 5 Feb 2003 10:52:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15FpNJ01340 for ; Wed, 5 Feb 2003 10:51:23 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28931 for ; Wed, 5 Feb 2003 10:44:51 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h15FmQP01875; Wed, 5 Feb 2003 15:48:26 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DCH7VVW; Wed, 5 Feb 2003 15:48:26 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1DBH5FM1>; Wed, 5 Feb 2003 15:48:10 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'mikko.lonnfors@nokia.com'" , simple@ietf.org Subject: RE: [Simple] New I-Ds on partial notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CD2D.FB607420" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Feb 2003 15:48:09 -0000 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_01C2CD2D.FB607420 Content-Type: text/plain; charset="iso-8859-1" I am really skeptical about the suggestion that large binary data content will be included in-line in the presence document itself. How will this be done ? Unless I mis-understand, the presence document is an XML document encoding in UTF-8 - i.e. it's a text document. Can you really include raw binary data in-line ?? What content-transfer-encoding will you use ? How will a standard XML parser react to this ? Does XML have a mechanisms for indicating that arbitrary binary data follows and indicating the length of that data ? If the binary data is e.g. base64 encoded, then you've immediately broken your efficiency requirement. Even if the raw binary data can be included in-line, the chances are that any SIP compression on the access link will end up expanding this portion of the message. (That is unless the compressor in use is specifically designed with the requirement to handle arbitrary binary data efficiently. But since the compressor is chosen by the edge proxy, how can you know this ?) I would expect SIP compressors to be optimised to handle text-based messages and, if only for this reason, I think we should generally try and stick with text based signalling within the SIP message (and yes, we do have to do something about S/MIME encryption here!). As I mentioned at the 3GPP/IETF workshop that we have to pay continuing attention to the compressibility of SIP messages. There have been many threads on the general undesirability of using SIP to transport large content files around. Further, on a 3GPP-specific note, this approach would make it much more difficult to get any kind of reliable idea of the bandwidth/QoS requirements for the signalling-specific radio resource. Whilst you may wish to allow this resource to be used for content as well, I do not think people should be mandated to do this. Finally, one of your requirements is to cope with devices of various form-factors/capabilities and the ability to render multi-media content is one capability which varies greatly from device to device - I really do not want to send a video clip even once to a device which can't render it. I do not see what the big deal is with including a URI for any such content in the Presence Document. This has so many advantages: a) The content is only sent when it changes (even with your proposal, it is sent at least every time a watcher subscribes) b) The content is only sent to devices which can render it c) The content need only be sent when the device actually needs to render it Jonathan explained how security could easily be made no worse than for in-line content. On charging you solution is to require that this data is charged in the same way as the rest of SIP signalling - but this solution does not imply that the data is carried *in* SIP signalling. If this is what you want to do, then just allow HTTP requests to a local HTTP-proxy (designated for this purpose) to use the signalling resource. Until we've bottomed out this in-line content question, I don't see how we can conclude on whether partial notifications are valuable or not. Regards, Mark -----Original Message----- From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com] Sent: 28 January 2003 07:35 To: simple@ietf.org Subject: [Simple] New I-Ds on partial notification Hi, Here are links to two new drafts which deal with partial presence notifications. Requirements are discussed here: http://www.ietf.org/internet-drafts/draft-lonnfors-simple-presinfo-deliv-req s-00.txt A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents requirements for a solution that aids in reducing the impacts of those constrains and increasing efficiency. And the actual solution is described here: http://www.ietf.org/internet-drafts/draft-lonnofors-simple-partial-notify-00 .txt A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and increasing efficiency, by introducing a new MIME-type partial notifications and a Require header extension partial-notification. All comments are most welcome. Regards - Mikko ------_=_NextPart_001_01C2CD2D.FB607420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] New I-Ds on partial notification

I am really skeptical about the suggestion that large = binary data content will be included in-line in the presence document = itself. How will this be done ?

Unless I mis-understand, the presence document is an = XML document encoding in UTF-8 - i.e. it's a text document. Can you = really include raw binary data in-line ?? What = content-transfer-encoding will you use ? How will a standard XML parser = react to this ? Does XML have a mechanisms for indicating that = arbitrary binary data follows and indicating the length of that data = ?

If the binary data is e.g. base64 encoded, then = you've immediately broken your efficiency requirement. Even if the raw = binary data can be included in-line, the chances are that any SIP = compression on the access link will end up expanding this portion of = the message. (That is unless the compressor in use is specifically = designed with the requirement to handle arbitrary binary data = efficiently. But since the compressor is chosen by the edge proxy, how = can you know this ?)

I would expect SIP compressors to be optimised to = handle text-based messages and, if only for this reason, I think we = should generally try and stick with text based signalling within the = SIP message (and yes, we do have to do something about S/MIME = encryption here!). As I mentioned at the 3GPP/IETF workshop that we = have to pay continuing attention to the compressibility of SIP = messages.

There have been many threads on the general = undesirability of using SIP to transport large content files around. = Further, on a 3GPP-specific note, this approach would make it much more = difficult to get any kind of reliable idea of the bandwidth/QoS = requirements for the signalling-specific radio resource. Whilst you may = wish to allow this resource to be used for content as well, I do not = think people should be mandated to do this.

Finally, one of your requirements is to cope with = devices of various form-factors/capabilities and the ability to render = multi-media content is one capability which varies greatly from device = to device - I really do not want to send a video clip even once to a = device which can't render it.

I do not see what the big deal is with including a = URI for any such content in the Presence Document. This has so many = advantages:

a) The content is only sent when it changes (even = with your proposal, it is sent at least every time a watcher = subscribes)

b) The content is only sent to devices which can = render it
c) The content need only be sent when the device = actually needs to render it

Jonathan explained how security could easily be made = no worse than for in-line content.

On charging you solution is to require that this data = is charged in the same way as the rest of SIP signalling - but this = solution does not imply that the data is carried *in* SIP signalling. = If this is what you want to do, then just allow HTTP requests to a = local HTTP-proxy (designated for this purpose) to use the signalling = resource.

Until we've bottomed out this in-line content = question, I don't see how we can conclude on whether partial = notifications are valuable or not.

Regards,

Mark

-----Original Message-----
From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com= ]
Sent: 28 January 2003 07:35
To: simple@ietf.org
Subject: [Simple] New I-Ds on partial = notification


Hi,
Here are links to two new drafts which deal with = partial presence notifications.
Requirements are discussed here:
http://www.ietf.org/internet-drafts/draft-lonnfors-sim= ple-presinfo-deliv-reqs-00.txt
A Presence service implemented using SIMPLE has some = constraints for
delivering presence information to devices with low = data processing
capabilities, small display, and limited battery = power. Other
limitations can be caused by the interface between = the terminal and
the network, i.e. over radio links with high latency = and low
bandwidth. This memo presents requirements for a = solution that aids
in reducing the impacts of those constrains and = increasing
efficiency.
And the actual solution is described here:
http://www.ietf.org/internet-drafts/draft-lonnofors-si= mple-partial-notify-00.txt
A Presence service implemented using SIMPLE has some = constraints for
delivering presence information to devices with low = data processing
capabilities, small display, and limited battery = power. Other
limitations can be caused by the interface between = the terminal and
the network, i.e. over radio links with high latency = and low
bandwidth. This memo presents a solution that aids = in reducing the
impact of those constrains and increasing = efficiency, by introducing
a new MIME-type partial notifications and a Require = header
extension partial-notification.
All comments are most welcome.
Regards
- Mikko

------_=_NextPart_001_01C2CD2D.FB607420-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 5 12:08:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02047 for ; Wed, 5 Feb 2003 12:08:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15HE4607603 for simple-archive@odin.ietf.org; Wed, 5 Feb 2003 12:14:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HE4J07600 for ; Wed, 5 Feb 2003 12:14:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02024 for ; Wed, 5 Feb 2003 12:07:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HE1J07577; Wed, 5 Feb 2003 12:14:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HAvJ07198 for ; Wed, 5 Feb 2003 12:10:57 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01905 for ; Wed, 5 Feb 2003 12:04:23 -0500 (EST) From: krisztian.kiss@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h15H6t202358 for ; Wed, 5 Feb 2003 19:06:55 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Feb 2003 19:08:00 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 19:08:00 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 19:07:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] PUBLISH: a dialog? Message-ID: Thread-Topic: [Simple] PUBLISH: a dialog? Thread-Index: AcLNIRZOUdw6WSCBRYGKQ9hcTR8C5AABQRaA To: , Cc: X-OriginalArrivalTime: 05 Feb 2003 17:07:59.0700 (UTC) FILETIME=[2297D140:01C2CD39] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h15HAvJ07199 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Feb 2003 19:07:59 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi All, I am supporting the dialog initiating PUBLISH method, since that seems to be a step forward to meet some of the requirements posted to SIMPLE list recently: http://mailman.dynamicsoft.com/pipermail/simple/2002-December/002103.html First, I believe the dialog concept would be preferable to provide "feedback" to the PUA about the actual result of the publishing transaction, whether the published XML was successfully composed to the presence document or not. Secondly, in a multi-PUA scenario, a dialog would also be useful to provide feedback about other PUAs' activities, e.g. the publishing PUA could learn the presence information (including the tuple ids) published by other PUAs. By discovering the existing content of the presence document, the PUA could decide whether the data it wants to publish is considered as new or existing, so in the latter case the PUA would overwrite existing information (publish by using existing tuple id). Thus, I imagine the PUBLISH dialog to be rather similar to SUBSCRIBE-NOTIFY, rather than INVITE. Probably, as soon as a PUA is alive and publishing, the PUBLISH dialog must also be kept alive. Comments? Regards, Krisztian > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, February 05, 2003 4:13 PM > To: Peterson, Jon > Cc: Simpletons (E-mail) > Subject: Re: [Simple] PUBLISH: a dialog? > > > Jon, > > You seem to have made a case that neither an actual dialog nor a > pseudo-dialog is needed - that presence publications can be taken at > face value as the arrive, regardless of source. > > If so, then the only reason for a dialog might be an > efficiency issue - > to establish the path between the publisher and the > compositor once. Is > that a good enough reason? If so, could it be optional? (E.g. the > PUBLISH might simply be permitted to piggyback on some > existing dialog, > without being dialog establishing.) > > Paul > > Peterson, Jon wrote: > > The SIMPLE minutes reflect a consensus in the room at IETF > 55 that the > > PUBLISH method should initiate a dialog. In preparation for > a revision of > > the PUBLISH document, this matter merits some further discussion. > > > > Some identifiers associated with publication persist beyond > the scope of a > > particular SIP transaction. For example, it is useful for a > compositor to > > know that a set of PUBLISH requests all came from the same > device, and to > > know the order in which they were sent. It may also be > desirable to let one > > device overwrite presence information that was published by > a different > > device, which entails some shared identifiers outside the > context of a > > dialog. > > > > draft-olson-simple-publish-01 contains a Stream header that > provides a > > longer-term identifier than the ordinary instance > identification methods of > > a dialog (the tags in the To and From headers and the > Call-ID). It has also > > been argued that the sequencing of publications need not > rely on something > > like a CSeq header, since the Date header or something > internal to the > > presence information body (for example, the > element in PIDF > > bodies) could provide temporal ordering information. For > these reasons, > > draft-olson-simple-publish-01 states that PUBLISH does not > establish a > > dialog. > > > > However, it isn't clear today if it is necessary to have a > longer-term > > identifier in the headers of the PUBLISH method, > considering that the > > presence information itself may contain its own identifiers > (like the tuple > > ID in PIDF) that could be reused as needed (such as the > case in which one > > device overwrites presence published by another). When we > were first working > > on PUBLISH, we were influenced by a use case in which a > presence compositor > > combined presence documents without actually reading their > contents (perhaps > > because the presence information is encrypted, or the > documents used a > > format that the compositor didn't understand), which would > argue that the > > longer-term identifier used by the compositor should not be > placed in the > > presence information itself. Ultimately, this use case > might not be that > > significant, though; a compositor that cannot understand presence > > information might not be able to do its job for unrelated > reasons. If at all > > possible, we should avoid authoring a new header that establishes a > > pseudo-dialog - REGISTER has taught us that creating a > one-off from the > > dialog model is ill advised. > > > > So, we'd like some opinions on this. Should PUBLISH > initiate a dialog, and > > use traditional dialog identifiers instead of the existing > Stream header? > > > > Jon Peterson > > NeuStar, Inc. > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 5 12:22:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02520 for ; Wed, 5 Feb 2003 12:22:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15HSlt08372 for simple-archive@odin.ietf.org; Wed, 5 Feb 2003 12:28:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HSlJ08369 for ; Wed, 5 Feb 2003 12:28:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02497 for ; Wed, 5 Feb 2003 12:22:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HSgJ08322; Wed, 5 Feb 2003 12:28:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HOjJ08146 for ; Wed, 5 Feb 2003 12:24:45 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02380 for ; Wed, 5 Feb 2003 12:18:01 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h15HLcP25715 for ; Wed, 5 Feb 2003 17:21:38 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DCH8CZ2; Wed, 5 Feb 2003 17:21:37 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1DBH52W6>; Wed, 5 Feb 2003 17:21:23 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: simple@ietf.org Subject: RE: [Simple] New I-Ds on partial notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CD3A.BB9B44AC" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Feb 2003 17:21:16 -0000 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_01C2CD3A.BB9B44AC Content-Type: text/plain; charset="iso-8859-1" One more reason why in-line content breaks SIP Compression: Most compression schemes have a limit on how far they can 'reach back' into the message stream to reference repeated strings. This distance may be further limited by the UDVM memory. Depending on the compression scheme, large in-line content may cause all useful state to be lost, so that the compression ratio drops right down. ...Mark -----Original Message----- From: Watson, Mark [MOP:EP10:EXCH] Sent: 05 February 2003 15:48 To: 'mikko.lonnfors@nokia.com'; simple@ietf.org Subject: RE: [Simple] New I-Ds on partial notification I am really skeptical about the suggestion that large binary data content will be included in-line in the presence document itself. How will this be done ? Unless I mis-understand, the presence document is an XML document encoding in UTF-8 - i.e. it's a text document. Can you really include raw binary data in-line ?? What content-transfer-encoding will you use ? How will a standard XML parser react to this ? Does XML have a mechanisms for indicating that arbitrary binary data follows and indicating the length of that data ? If the binary data is e.g. base64 encoded, then you've immediately broken your efficiency requirement. Even if the raw binary data can be included in-line, the chances are that any SIP compression on the access link will end up expanding this portion of the message. (That is unless the compressor in use is specifically designed with the requirement to handle arbitrary binary data efficiently. But since the compressor is chosen by the edge proxy, how can you know this ?) I would expect SIP compressors to be optimised to handle text-based messages and, if only for this reason, I think we should generally try and stick with text based signalling within the SIP message (and yes, we do have to do something about S/MIME encryption here!). As I mentioned at the 3GPP/IETF workshop that we have to pay continuing attention to the compressibility of SIP messages. There have been many threads on the general undesirability of using SIP to transport large content files around. Further, on a 3GPP-specific note, this approach would make it much more difficult to get any kind of reliable idea of the bandwidth/QoS requirements for the signalling-specific radio resource. Whilst you may wish to allow this resource to be used for content as well, I do not think people should be mandated to do this. Finally, one of your requirements is to cope with devices of various form-factors/capabilities and the ability to render multi-media content is one capability which varies greatly from device to device - I really do not want to send a video clip even once to a device which can't render it. I do not see what the big deal is with including a URI for any such content in the Presence Document. This has so many advantages: a) The content is only sent when it changes (even with your proposal, it is sent at least every time a watcher subscribes) b) The content is only sent to devices which can render it c) The content need only be sent when the device actually needs to render it Jonathan explained how security could easily be made no worse than for in-line content. On charging you solution is to require that this data is charged in the same way as the rest of SIP signalling - but this solution does not imply that the data is carried *in* SIP signalling. If this is what you want to do, then just allow HTTP requests to a local HTTP-proxy (designated for this purpose) to use the signalling resource. Until we've bottomed out this in-line content question, I don't see how we can conclude on whether partial notifications are valuable or not. Regards, Mark -----Original Message----- From: mikko.lonnfors@nokia.com [ mailto:mikko.lonnfors@nokia.com ] Sent: 28 January 2003 07:35 To: simple@ietf.org Subject: [Simple] New I-Ds on partial notification Hi, Here are links to two new drafts which deal with partial presence notifications. Requirements are discussed here: http://www.ietf.org/internet-drafts/draft-lonnfors-simple-presinfo-deliv-req s-00.txt A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents requirements for a solution that aids in reducing the impacts of those constrains and increasing efficiency. And the actual solution is described here: http://www.ietf.org/internet-drafts/draft-lonnofors-simple-partial-notify-00 .txt A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and increasing efficiency, by introducing a new MIME-type partial notifications and a Require header extension partial-notification. All comments are most welcome. Regards - Mikko ------_=_NextPart_001_01C2CD3A.BB9B44AC Content-Type: text/html; charset="iso-8859-1" RE: [Simple] New I-Ds on partial notification
One more reason why in-line content breaks SIP Compression: Most compression schemes have a limit on how far they can 'reach back' into the message stream to reference repeated strings. This distance may be further limited by the UDVM memory. Depending on the compression scheme, large in-line content may cause all useful state to be lost, so that the compression ratio drops right down.
 
...Mark
-----Original Message-----
From: Watson, Mark [MOP:EP10:EXCH]
Sent: 05 February 2003 15:48
To: 'mikko.lonnfors@nokia.com'; simple@ietf.org
Subject: RE: [Simple] New I-Ds on partial notification

I am really skeptical about the suggestion that large binary data content will be included in-line in the presence document itself. How will this be done ?

Unless I mis-understand, the presence document is an XML document encoding in UTF-8 - i.e. it's a text document. Can you really include raw binary data in-line ?? What content-transfer-encoding will you use ? How will a standard XML parser react to this ? Does XML have a mechanisms for indicating that arbitrary binary data follows and indicating the length of that data ?

If the binary data is e.g. base64 encoded, then you've immediately broken your efficiency requirement. Even if the raw binary data can be included in-line, the chances are that any SIP compression on the access link will end up expanding this portion of the message. (That is unless the compressor in use is specifically designed with the requirement to handle arbitrary binary data efficiently. But since the compressor is chosen by the edge proxy, how can you know this ?)

I would expect SIP compressors to be optimised to handle text-based messages and, if only for this reason, I think we should generally try and stick with text based signalling within the SIP message (and yes, we do have to do something about S/MIME encryption here!). As I mentioned at the 3GPP/IETF workshop that we have to pay continuing attention to the compressibility of SIP messages.

There have been many threads on the general undesirability of using SIP to transport large content files around. Further, on a 3GPP-specific note, this approach would make it much more difficult to get any kind of reliable idea of the bandwidth/QoS requirements for the signalling-specific radio resource. Whilst you may wish to allow this resource to be used for content as well, I do not think people should be mandated to do this.

Finally, one of your requirements is to cope with devices of various form-factors/capabilities and the ability to render multi-media content is one capability which varies greatly from device to device - I really do not want to send a video clip even once to a device which can't render it.

I do not see what the big deal is with including a URI for any such content in the Presence Document. This has so many advantages:

a) The content is only sent when it changes (even with your proposal, it is sent at least every time a watcher subscribes)

b) The content is only sent to devices which can render it
c) The content need only be sent when the device actually needs to render it

Jonathan explained how security could easily be made no worse than for in-line content.

On charging you solution is to require that this data is charged in the same way as the rest of SIP signalling - but this solution does not imply that the data is carried *in* SIP signalling. If this is what you want to do, then just allow HTTP requests to a local HTTP-proxy (designated for this purpose) to use the signalling resource.

Until we've bottomed out this in-line content question, I don't see how we can conclude on whether partial notifications are valuable or not.

Regards,

Mark

-----Original Message-----
From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com]
Sent: 28 January 2003 07:35
To: simple@ietf.org
Subject: [Simple] New I-Ds on partial notification


Hi,
Here are links to two new drafts which deal with partial presence notifications.
Requirements are discussed here:
http://www.ietf.org/internet-drafts/draft-lonnfors-simple-presinfo-deliv-reqs-00.txt
A Presence service implemented using SIMPLE has some constraints for
delivering presence information to devices with low data processing
capabilities, small display, and limited battery power. Other
limitations can be caused by the interface between the terminal and
the network, i.e. over radio links with high latency and low
bandwidth. This memo presents requirements for a solution that aids
in reducing the impacts of those constrains and increasing
efficiency.
And the actual solution is described here:
http://www.ietf.org/internet-drafts/draft-lonnofors-simple-partial-notify-00.txt
A Presence service implemented using SIMPLE has some constraints for
delivering presence information to devices with low data processing
capabilities, small display, and limited battery power. Other
limitations can be caused by the interface between the terminal and
the network, i.e. over radio links with high latency and low
bandwidth. This memo presents a solution that aids in reducing the
impact of those constrains and increasing efficiency, by introducing
a new MIME-type partial notifications and a Require header
extension partial-notification.
All comments are most welcome.
Regards
- Mikko

------_=_NextPart_001_01C2CD3A.BB9B44AC-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 5 12:49:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03600 for ; Wed, 5 Feb 2003 12:49:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15HtCC10551 for simple-archive@odin.ietf.org; Wed, 5 Feb 2003 12:55:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HtCJ10548 for ; Wed, 5 Feb 2003 12:55:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03585 for ; Wed, 5 Feb 2003 12:48:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15Ht8J10538; Wed, 5 Feb 2003 12:55:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HsFJ10495 for ; Wed, 5 Feb 2003 12:54:15 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03529 for ; Wed, 5 Feb 2003 12:47:40 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h15Hrvm16421 for ; Wed, 5 Feb 2003 19:53:57 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Feb 2003 19:51:17 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 19:51:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] New I-Ds on partial notification Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945148@esebe013.ntc.nokia.com> Thread-Topic: [Simple] New I-Ds on partial notification Thread-Index: AcLNO9rxjQ9y+5jBQceLP1mG7efPpAAAPa5Q To: , X-OriginalArrivalTime: 05 Feb 2003 17:51:16.0751 (UTC) FILETIME=[2E8E59F0:01C2CD3F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h15HsFJ10496 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Feb 2003 19:51:16 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Is this really so? I would hope SIP compression doesn't break because of large (binary) content in the message payload. It would mean sending a jpeg mug shot in an INVITE will also break it, along with MESSAGE with any multimedia in it. And I agree, base64 encoding may not be the best way. How about including the content using cids and a MIME multipart? Just a thought. Cheers, Aki -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 05 February, 2003 19:21 To: simple@ietf.org Subject: RE: [Simple] New I-Ds on partial notification One more reason why in-line content breaks SIP Compression: Most compression schemes have a limit on how far they can 'reach back' into the message stream to reference repeated strings. This distance may be further limited by the UDVM memory. Depending on the compression scheme, large in-line content may cause all useful state to be lost, so that the compression ratio drops right down. ...Mark -----Original Message----- From: Watson, Mark [MOP:EP10:EXCH] Sent: 05 February 2003 15:48 To: 'mikko.lonnfors@nokia.com'; simple@ietf.org Subject: RE: [Simple] New I-Ds on partial notification I am really skeptical about the suggestion that large binary data content will be included in-line in the presence document itself. How will this be done ? Unless I mis-understand, the presence document is an XML document encoding in UTF-8 - i.e. it's a text document. Can you really include raw binary data in-line ?? What content-transfer-encoding will you use ? How will a standard XML parser react to this ? Does XML have a mechanisms for indicating that arbitrary binary data follows and indicating the length of that data ? If the binary data is e.g. base64 encoded, then you've immediately broken your efficiency requirement. Even if the raw binary data can be included in-line, the chances are that any SIP compression on the access link will end up expanding this portion of the message. (That is unless the compressor in use is specifically designed with the requirement to handle arbitrary binary data efficiently. But since the compressor is chosen by the edge proxy, how can you know this ?) I would expect SIP compressors to be optimised to handle text-based messages and, if only for this reason, I think we should generally try and stick with text based signalling within the SIP message (and yes, we do have to do something about S/MIME encryption here!). As I mentioned at the 3GPP/IETF workshop that we have to pay continuing attention to the compressibility of SIP messages. There have been many threads on the general undesirability of using SIP to transport large content files around. Further, on a 3GPP-specific note, this approach would make it much more difficult to get any kind of reliable idea of the bandwidth/QoS requirements for the signalling-specific radio resource. Whilst you may wish to allow this resource to be used for content as well, I do not think people should be mandated to do this. Finally, one of your requirements is to cope with devices of various form-factors/capabilities and the ability to render multi-media content is one capability which varies greatly from device to device - I really do not want to send a video clip even once to a device which can't render it. I do not see what the big deal is with including a URI for any such content in the Presence Document. This has so many advantages: a) The content is only sent when it changes (even with your proposal, it is sent at least every time a watcher subscribes) b) The content is only sent to devices which can render it c) The content need only be sent when the device actually needs to render it Jonathan explained how security could easily be made no worse than for in-line content. On charging you solution is to require that this data is charged in the same way as the rest of SIP signalling - but this solution does not imply that the data is carried *in* SIP signalling. If this is what you want to do, then just allow HTTP requests to a local HTTP-proxy (designated for this purpose) to use the signalling resource. Until we've bottomed out this in-line content question, I don't see how we can conclude on whether partial notifications are valuable or not. Regards, Mark -----Original Message----- From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com] Sent: 28 January 2003 07:35 To: simple@ietf.org Subject: [Simple] New I-Ds on partial notification Hi, Here are links to two new drafts which deal with partial presence notifications. Requirements are discussed here: http://www.ietf.org/internet-drafts/draft-lonnfors-simple-presinfo-deliv-reqs-00.txt A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents requirements for a solution that aids in reducing the impacts of those constrains and increasing efficiency. And the actual solution is described here: http://www.ietf.org/internet-drafts/draft-lonnofors-simple-partial-notify-00.txt A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and increasing efficiency, by introducing a new MIME-type partial notifications and a Require header extension partial-notification. All comments are most welcome. Regards - Mikko _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 5 13:21:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05381 for ; Wed, 5 Feb 2003 13:21:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15IRbh12409 for simple-archive@odin.ietf.org; Wed, 5 Feb 2003 13:27:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15IRbJ12406 for ; Wed, 5 Feb 2003 13:27:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05363 for ; Wed, 5 Feb 2003 13:20:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15IRTJ12394; Wed, 5 Feb 2003 13:27:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15IOEJ12283 for ; Wed, 5 Feb 2003 13:24:14 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05198 for ; Wed, 5 Feb 2003 13:17:35 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (europem01.nt.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h15ILAP03688; Wed, 5 Feb 2003 18:21:10 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DCH8HVB; Wed, 5 Feb 2003 18:21:10 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1DBH5J7B>; Wed, 5 Feb 2003 18:20:21 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'aki.niemi@nokia.com'" , simple@ietf.org Subject: RE: [Simple] New I-Ds on partial notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CD43.3D399704" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Feb 2003 18:20:19 -0000 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_01C2CD43.3D399704 Content-Type: text/plain; charset="iso-8859-1" Aki, Well, it depends on the compression algorithm used. Certainly the simple ones do little more that send a string of pairs to reference strings which occured earlier in the data stream - of course with some way of escaping to literal data. So, certainly, large in-band binary content will reduce the effectiveness of these schemes. You could mitigate this by ensuring that the static dictionary never goes out of view, or, for example, only storing the first X octets of each message, where X is chosen to usually cover the headers and SDP. Other schemes build up a dictionary of codewords e.g. in LZW then the codebook is built up by allocating a new codeword for the previous phase plus the next character. Common phrases will end up appearing in more codewords and in longer referenced strings. I think this would not be so affected by raw binary data, since this wouldn't disrupt the codebook already built. However, I'm not so sure this is the best scheme for SIP signalling, since it takes quite a while to build up the codebook. You want, for example, to be referencing back to the entire Request URI when it appears again in the To field a few octets later, and then do the same in subsequent requests/responses - not sure LZW would get you this. DEFLATE, if I remember correctly, does LZW & then Huffman encodes the result. In my personal opinion, binary content in SIP messages, including the Caller Photo & Multimedia Messages is a bad thing per se and Content Indirection should always be used. (As Jonathan mentioned, the existing MMS does not send the content with the notification of the message - you have to fetch it). Having said that, referencing out from the Presence Document to something which might be at a URL or might be in another MIME part of the Notification might provide a way forward - of course I'd still say that these other MIME parts should be Content-Indirected :-), but at least you have solved the encoding problem and brought the compression problems into the same space as Caller-photos etc. ...Mark > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: 05 February 2003 17:51 > To: Watson, Mark [MOP:EP10:EXCH]; simple@ietf.org > Subject: RE: [Simple] New I-Ds on partial notification > > > Is this really so? I would hope SIP compression doesn't break > because of large (binary) content in the message payload. It > would mean sending a jpeg mug shot in an INVITE will also > break it, along with MESSAGE with any multimedia in it. > > And I agree, base64 encoding may not be the best way. How > about including the content using cids and a MIME multipart? > Just a thought. > > Cheers, > Aki > > > -----Original Message----- > From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] > Sent: 05 February, 2003 19:21 > To: simple@ietf.org > Subject: RE: [Simple] New I-Ds on partial notification > > > One more reason why in-line content breaks SIP Compression: > Most compression schemes have a limit on how far they can > 'reach back' into the message stream to reference repeated > strings. This distance may be further limited by the UDVM > memory. Depending on the compression scheme, large in-line > content may cause all useful state to be lost, so that the > compression ratio drops right down. > > ...Mark > -----Original Message----- > From: Watson, Mark [MOP:EP10:EXCH] > Sent: 05 February 2003 15:48 > To: 'mikko.lonnfors@nokia.com'; simple@ietf.org > Subject: RE: [Simple] New I-Ds on partial notification > > > I am really skeptical about the suggestion that large binary > data content will be included in-line in the presence > document itself. How will this be done ? > Unless I mis-understand, the presence document is an XML > document encoding in UTF-8 - i.e. it's a text document. Can > you really include raw binary data in-line ?? What > content-transfer-encoding will you use ? How will a standard > XML parser react to this ? Does XML have a mechanisms for > indicating that arbitrary binary data follows and indicating > the length of that data ? > If the binary data is e.g. base64 encoded, then you've > immediately broken your efficiency requirement. Even if the > raw binary data can be included in-line, the chances are that > any SIP compression on the access link will end up expanding > this portion of the message. (That is unless the compressor > in use is specifically designed with the requirement to > handle arbitrary binary data efficiently. But since the > compressor is chosen by the edge proxy, how can you know this ?) > I would expect SIP compressors to be optimised to handle > text-based messages and, if only for this reason, I think we > should generally try and stick with text based signalling > within the SIP message (and yes, we do have to do something > about S/MIME encryption here!). As I mentioned at the > 3GPP/IETF workshop that we have to pay continuing attention > to the compressibility of SIP messages. > There have been many threads on the general undesirability of > using SIP to transport large content files around. Further, > on a 3GPP-specific note, this approach would make it much > more difficult to get any kind of reliable idea of the > bandwidth/QoS requirements for the signalling-specific radio > resource. Whilst you may wish to allow this resource to be > used for content as well, I do not think people should be > mandated to do this. > Finally, one of your requirements is to cope with devices of > various form-factors/capabilities and the ability to render > multi-media content is one capability which varies greatly > from device to device - I really do not want to send a video > clip even once to a device which can't render it. > I do not see what the big deal is with including a URI for > any such content in the Presence Document. This has so many > advantages: > a) The content is only sent when it changes (even with your > proposal, it is sent at least every time a watcher subscribes) > b) The content is only sent to devices which can render it > c) The content need only be sent when the device actually > needs to render it > Jonathan explained how security could easily be made no worse > than for in-line content. > On charging you solution is to require that this data is > charged in the same way as the rest of SIP signalling - but > this solution does not imply that the data is carried *in* > SIP signalling. If this is what you want to do, then just > allow HTTP requests to a local HTTP-proxy (designated for > this purpose) to use the signalling resource. > Until we've bottomed out this in-line content question, I > don't see how we can conclude on whether partial > notifications are valuable or not. > Regards, > Mark > -----Original Message----- > From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com] > Sent: 28 January 2003 07:35 > To: simple@ietf.org > Subject: [Simple] New I-Ds on partial notification > > > Hi, > Here are links to two new drafts which deal with partial > presence notifications. > Requirements are discussed here: > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-pres > info-deliv-reqs-00.txt > A Presence service implemented using SIMPLE has some constraints for > delivering presence information to devices with low data processing > capabilities, small display, and limited battery power. Other > limitations can be caused by the interface between the terminal and > the network, i.e. over radio links with high latency and low > bandwidth. This memo presents requirements for a solution that aids > in reducing the impacts of those constrains and increasing > efficiency. > And the actual solution is described here: > http://www.ietf.org/internet-drafts/draft-lonnofors-simple-par > tial-notify-00.txt > A Presence service implemented using SIMPLE has some constraints for > delivering presence information to devices with low data processing > capabilities, small display, and limited battery power. Other > limitations can be caused by the interface between the terminal and > the network, i.e. over radio links with high latency and low > bandwidth. This memo presents a solution that aids in reducing the > impact of those constrains and increasing efficiency, by introducing > a new MIME-type partial notifications and a Require header > extension partial-notification. > All comments are most welcome. > Regards > - Mikko > ------_=_NextPart_001_01C2CD43.3D399704 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] New I-Ds on partial notification

Aki,

Well, it depends on the compression algorithm used. = Certainly the simple ones do little more that send a string of = <offset,length> pairs to reference strings which occured earlier = in the data stream - of course with some way of escaping to literal = data. So, certainly, large in-band binary content will reduce the = effectiveness of these schemes.

You could mitigate this by ensuring that the static = dictionary never goes out of view, or, for example, only storing the = first X octets of each message, where X is chosen to usually cover the = headers and SDP.

Other schemes build up a dictionary of codewords e.g. = in LZW then the codebook is built up by allocating a new codeword for = the previous phase plus the next character. Common phrases will end up = appearing in more codewords and in longer referenced strings. I think = this would not be so affected by raw binary data, since this wouldn't = disrupt the codebook already built.

However, I'm not so sure this is the best scheme for = SIP signalling, since it takes quite a while to build up the codebook. = You want, for example, to be referencing back to the entire Request URI = when it appears again in the To field a few octets later, and then do = the same in subsequent requests/responses - not sure LZW would get you = this.

DEFLATE, if I remember correctly, does LZW & then = Huffman encodes the result.

In my personal opinion, binary content in SIP = messages, including the Caller Photo & Multimedia Messages is a bad = thing per se and Content Indirection should always be used. (As = Jonathan mentioned, the existing MMS does not send the content with the = notification of the message - you have to fetch it).

Having said that, referencing out from the Presence = Document to something which might be at a URL or might be in another = MIME part of the Notification might provide a way forward - of course = I'd still say that these other MIME parts should be Content-Indirected = :-), but at least you have solved the encoding problem and brought the = compression problems into the same space as Caller-photos = etc.

...Mark

> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: 05 February 2003 17:51
> To: Watson, Mark [MOP:EP10:EXCH]; = simple@ietf.org
> Subject: RE: [Simple] New I-Ds on partial = notification
>
>
> Is this really so? I would hope SIP compression = doesn't break
> because of large (binary) content in the = message payload. It
> would mean sending a jpeg mug shot in an INVITE = will also
> break it, along with MESSAGE with any = multimedia in it.
>
> And I agree, base64 encoding may not be the = best way. How
> about including the content using cids and a = MIME multipart?
> Just a thought.
>
> Cheers,
> Aki
>
>
> -----Original Message-----
> From: ext Mark Watson [mailto:mwatson@nortelnetworks= .com]
> Sent: 05 February, 2003 19:21
> To: simple@ietf.org
> Subject: RE: [Simple] New I-Ds on partial = notification
>
>
> One more reason why in-line content breaks SIP = Compression:
> Most compression schemes have a limit on how = far they can
> 'reach back' into the message stream to = reference repeated
> strings. This distance may be further limited = by the UDVM
> memory. Depending on the compression scheme, = large in-line
> content may cause all useful state to be lost, = so that the
> compression ratio drops right down.
>
> ...Mark
> -----Original Message-----
> From: Watson, Mark [MOP:EP10:EXCH]
> Sent: 05 February 2003 15:48
> To: 'mikko.lonnfors@nokia.com'; = simple@ietf.org
> Subject: RE: [Simple] New I-Ds on partial = notification
>
>
> I am really skeptical about the suggestion that = large binary
> data content will be included in-line in the = presence
> document itself. How will this be done ?
> Unless I mis-understand, the presence document = is an XML
> document encoding in UTF-8 - i.e. it's a text = document. Can
> you really include raw binary data in-line ?? = What
> content-transfer-encoding will you use ? How = will a standard
> XML parser react to this ? Does XML have a = mechanisms for
> indicating that arbitrary binary data follows = and indicating
> the length of that data ?
> If the binary data is e.g. base64 encoded, then = you've
> immediately broken your efficiency requirement. = Even if the
> raw binary data can be included in-line, the = chances are that
> any SIP compression on the access link will end = up expanding
> this portion of the message. (That is unless = the compressor
> in use is specifically designed with the = requirement to
> handle arbitrary binary data efficiently. But = since the
> compressor is chosen by the edge proxy, how can = you know this ?)
> I would expect SIP compressors to be optimised = to handle
> text-based messages and, if only for this = reason, I think we
> should generally try and stick with text based = signalling
> within the SIP message (and yes, we do have to = do something
> about S/MIME encryption here!). As I mentioned = at the
> 3GPP/IETF workshop that we have to pay = continuing attention
> to the compressibility of SIP messages.
> There have been many threads on the general = undesirability of
> using SIP to transport large content files = around. Further,
> on a 3GPP-specific note, this approach would = make it much
> more difficult to get any kind of reliable idea = of the
> bandwidth/QoS requirements for the = signalling-specific radio
> resource. Whilst you may wish to allow this = resource to be
> used for content as well, I do not think people = should be
> mandated to do this.
> Finally, one of your requirements is to cope = with devices of
> various form-factors/capabilities and the = ability to render
> multi-media content is one capability which = varies greatly
> from device to device - I really do not want to = send a video
> clip even once to a device which can't render = it.
> I do not see what the big deal is with = including a URI for
> any such content in the Presence Document. This = has so many
> advantages:
> a) The content is only sent when it changes = (even with your
> proposal, it is sent at least every time a = watcher subscribes)
> b) The content is only sent to devices which = can render it
> c) The content need only be sent when the = device actually
> needs to render it
> Jonathan explained how security could easily be = made no worse
> than for in-line content.
> On charging you solution is to require that = this data is
> charged in the same way as the rest of SIP = signalling - but
> this solution does not imply that the data is = carried *in*
> SIP signalling. If this is what you want to do, = then just
> allow HTTP requests to a local HTTP-proxy = (designated for
> this purpose) to use the signalling = resource.
> Until we've bottomed out this in-line content = question, I
> don't see how we can conclude on whether = partial
> notifications are valuable or not.
> Regards,
> Mark
> -----Original Message-----
> From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com= ]
> Sent: 28 January 2003 07:35
> To: simple@ietf.org
> Subject: [Simple] New I-Ds on partial = notification
>
>
> Hi,
> Here are links to two new drafts which deal = with partial
> presence notifications.
> Requirements are discussed here:
> http://www.ietf.org/internet-drafts/draft-lonnfors-sim= ple-pres
> info-deliv-reqs-00.txt
> A Presence service implemented using SIMPLE has = some constraints for
> delivering presence information to devices with = low data processing
> capabilities, small display, and limited = battery power. Other
> limitations can be caused by the interface = between the terminal and
> the network, i.e. over radio links with high = latency and low
> bandwidth. This memo presents requirements for = a solution that aids
> in reducing the impacts of those constrains and = increasing
> efficiency.
> And the actual solution is described here: =
> http://www.ietf.org/internet-drafts/draft-lonnofors-si= mple-par
> tial-notify-00.txt
> A Presence service implemented using SIMPLE has = some constraints for
> delivering presence information to devices with = low data processing
> capabilities, small display, and limited = battery power. Other
> limitations can be caused by the interface = between the terminal and
> the network, i.e. over radio links with high = latency and low
> bandwidth. This memo presents a solution that = aids in reducing the
> impact of those constrains and increasing = efficiency, by introducing
> a new MIME-type partial notifications and a = Require header
> extension partial-notification.
> All comments are most welcome.
> Regards
> - Mikko
>

------_=_NextPart_001_01C2CD43.3D399704-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 5 16:21:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11204 for ; Wed, 5 Feb 2003 16:21:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15LRVT24186 for simple-archive@odin.ietf.org; Wed, 5 Feb 2003 16:27:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15LRVJ24183 for ; Wed, 5 Feb 2003 16:27:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11192 for ; Wed, 5 Feb 2003 16:20:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15LROJ24173; Wed, 5 Feb 2003 16:27:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15LQbJ24140 for ; Wed, 5 Feb 2003 16:26:37 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11157 for ; Wed, 5 Feb 2003 16:19:58 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h15LNST26618; Wed, 5 Feb 2003 15:23:28 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LNXBKHD>; Wed, 5 Feb 2003 15:23:28 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E07BBEE65@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "Peterson, Jon" , "Simpletons (E-mail)" Subject: RE: [Simple] PUBLISH: a dialog? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CD5C.D0EFFFB0" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Feb 2003 15:23:24 -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_01C2CD5C.D0EFFFB0 Content-Type: text/plain; charset="ISO-8859-1" More comments from left field... I'd argue that we keep the idea of a token (ala Stream) that identifies a particular source, and not try to hassle with the overhead of a dialog. Here's the scenario that I'm looking at: We have several PUAs all publishing their presence information into a compositor, but the compositor is using this information to provide both a per-PUA indication of status, and an overall presence status. If this is the case then a policy may be used based on the per-PUA presence information to come up with the overall view of that user's presence. The trouble begins when we bring reality into the picture. Let's say one of the PUA clients crashes, or loses network connectivity for long periods of time (which I'm sure we won't run into often as all software is highly reliable, and all networks never experience intermittant outages to a particular node on the network), so here's the rub: how do we know where to restore their presence information back to? If we have a simple, globally-unique (or as unique as we can make it) identifier, that identifies a UNIQUE INSTANCE of a particular PUA, and not just a particular run-time instance (ie. it's set once, and never reset ever again, like a serial number), we can correctly continue to compose an overall presence document even though the client may crash, the network may crap out, or some other unforseen tragedy befalls our poor PUA. Although I agree with the idea of having something dialog-like to preserve ordering, etc., I think we've already shown that it can be handled in other ways. Similiarly, I would rather not solve the need to have a way to identify a particular PUA instance by coupling it with the transport mechanism it uses to get that information to us. If we say that they simply need to initiate a dialog, we can't necessarily say that the PUA will be able to recover from the dialogue being dropped without making demands that the callid and tags being used must be used from now on, forever, and ever, amen, which is pretty much what we get around with having a Stream header. Besides, what if we're getting the information forwarded to us at the compositor through some sort of BBUA (which, they will) and they're not using a deterministic algorithm that always maps an input callid and tag to the same output tag and call id across dialogs? Thoughts? Brian -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Wednesday, February 05, 2003 5:09 AM To: Simpletons (E-mail) Subject: [Simple] PUBLISH: a dialog? The SIMPLE minutes reflect a consensus in the room at IETF 55 that the PUBLISH method should initiate a dialog. In preparation for a revision of the PUBLISH document, this matter merits some further discussion. Some identifiers associated with publication persist beyond the scope of a particular SIP transaction. For example, it is useful for a compositor to know that a set of PUBLISH requests all came from the same device, and to know the order in which they were sent. It may also be desirable to let one device overwrite presence information that was published by a different device, which entails some shared identifiers outside the context of a dialog. draft-olson-simple-publish-01 contains a Stream header that provides a longer-term identifier than the ordinary instance identification methods of a dialog (the tags in the To and From headers and the Call-ID). It has also been argued that the sequencing of publications need not rely on something like a CSeq header, since the Date header or something internal to the presence information body (for example, the element in PIDF bodies) could provide temporal ordering information. For these reasons, draft-olson-simple-publish-01 states that PUBLISH does not establish a dialog. However, it isn't clear today if it is necessary to have a longer-term identifier in the headers of the PUBLISH method, considering that the presence information itself may contain its own identifiers (like the tuple ID in PIDF) that could be reused as needed (such as the case in which one device overwrites presence published by another). When we were first working on PUBLISH, we were influenced by a use case in which a presence compositor combined presence documents without actually reading their contents (perhaps because the presence information is encrypted, or the documents used a format that the compositor didn't understand), which would argue that the longer-term identifier used by the compositor should not be placed in the presence information itself. Ultimately, this use case might not be that significant, though; a compositor that cannot understand presence information might not be able to do its job for unrelated reasons. If at all possible, we should avoid authoring a new header that establishes a pseudo-dialog - REGISTER has taught us that creating a one-off from the dialog model is ill advised. So, we'd like some opinions on this. Should PUBLISH initiate a dialog, and use traditional dialog identifiers instead of the existing Stream header? Jon Peterson NeuStar, Inc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01C2CD5C.D0EFFFB0 Content-Type: text/html; charset="ISO-8859-1" RE: [Simple] PUBLISH: a dialog?

More comments from left field...

I'd argue that we keep the idea of a token (ala Stream) that identifies a particular source,
and not try to hassle with the overhead of a dialog. Here's the scenario that I'm looking
at:

We have several PUAs all publishing their presence information into a compositor, but the
compositor is using this information to provide both a per-PUA indication of status, and
an overall presence status. If this is the case then a policy may be used based on the
per-PUA presence information to come up with the overall view of that user's presence.

The trouble begins when we bring reality into the picture. Let's say one of the PUA clients
crashes, or loses network connectivity for long periods of time (which I'm sure we won't
run into often as all software is highly reliable, and all networks never experience
intermittant outages to a particular node on the network), so here's the rub: how do we
know where to restore their presence information back to?

If we have a simple, globally-unique (or as unique as we can make it) identifier, that
identifies a UNIQUE INSTANCE of a particular PUA, and not just a particular run-time instance
(ie. it's set once, and never reset ever again, like a serial number), we can correctly
continue to compose an overall presence document even though the client may crash, the
network may crap out, or some other unforseen tragedy befalls our poor PUA.

Although I agree with the idea of having something dialog-like to preserve ordering, etc., I
think we've already shown that it can be handled in other ways. Similiarly, I would rather
not solve the need to have a way to identify a particular PUA instance by coupling it with the
transport mechanism it uses to get that information to us.

If we say that they simply need to initiate a dialog, we can't necessarily say that the PUA
will be able to recover from the dialogue being dropped without making demands that the callid
and tags being used must be used from now on, forever, and ever, amen, which is pretty much
what we get around with having a Stream header. Besides, what if we're getting the information
forwarded to us at the compositor through some sort of BBUA (which, they will) and they're
not using a deterministic algorithm that always maps an input callid and tag to the same output
tag and call id across dialogs?

Thoughts?

Brian

-----Original Message-----
From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: Wednesday, February 05, 2003 5:09 AM
To: Simpletons (E-mail)
Subject: [Simple] PUBLISH: a dialog?



The SIMPLE minutes reflect a consensus in the room at IETF 55 that the
PUBLISH method should initiate a dialog. In preparation for a revision of
the PUBLISH document, this matter merits some further discussion.

Some identifiers associated with publication persist beyond the scope of a
particular SIP transaction. For example, it is useful for a compositor to
know that a set of PUBLISH requests all came from the same device, and to
know the order in which they were sent. It may also be desirable to let one
device overwrite presence information that was published by a different
device, which entails some shared identifiers outside the context of a
dialog.

draft-olson-simple-publish-01 contains a Stream header that provides a
longer-term identifier than the ordinary instance identification methods of
a dialog (the tags in the To and From headers and the Call-ID). It has also
been argued that the sequencing of publications need not rely on something
like a CSeq header, since the Date header or something internal to the
presence information body (for example, the <timestamp> element in PIDF
bodies) could provide temporal ordering information. For these reasons,
draft-olson-simple-publish-01 states that PUBLISH does not establish a
dialog.

However, it isn't clear today if it is necessary to have a longer-term
identifier in the headers of the PUBLISH method, considering that the
presence information itself may contain its own identifiers (like the tuple
ID in PIDF) that could be reused as needed (such as the case in which one
device overwrites presence published by another). When we were first working
on PUBLISH, we were influenced by a use case in which a presence compositor
combined presence documents without actually reading their contents (perhaps
because the presence information is encrypted, or the documents used a
format that the compositor didn't understand), which would argue that the
longer-term identifier used by the compositor should not be placed in the
presence information itself. Ultimately, this use case might not be that
significant, though; a compositor that cannot understand presence
information might not be able to do its job for unrelated reasons. If at all
possible, we should avoid authoring a new header that establishes a
pseudo-dialog - REGISTER has taught us that creating a one-off from the
dialog model is ill advised.

So, we'd like some opinions on this. Should PUBLISH initiate a dialog, and
use traditional dialog identifiers instead of the existing Stream header?

Jon Peterson
NeuStar, Inc.
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

------_=_NextPart_001_01C2CD5C.D0EFFFB0-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 5 18:48:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15646 for ; Wed, 5 Feb 2003 18:48:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15NsFa06961 for simple-archive@odin.ietf.org; Wed, 5 Feb 2003 18:54:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15NsFp06958 for ; Wed, 5 Feb 2003 18:54:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15618 for ; Wed, 5 Feb 2003 18:47:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15NsBp06950; Wed, 5 Feb 2003 18:54:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15Nrtp06929 for ; Wed, 5 Feb 2003 18:53:55 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15613 for ; Wed, 5 Feb 2003 18:47:13 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h15NrVm21989 for ; Thu, 6 Feb 2003 01:53:31 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Feb 2003 01:50:51 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 01:50:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] New I-Ds on partial notification Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD229@esebe013.ntc.nokia.com> Thread-Topic: [Simple] New I-Ds on partial notification Thread-Index: AcLNQ13JHQP4Cqa9Sla4oye7yF7mBgAGO7MwAAAGm8A= To: Cc: X-OriginalArrivalTime: 05 Feb 2003 23:50:50.0836 (UTC) FILETIME=[69B67940:01C2CD71] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h15Nrup06930 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Feb 2003 01:50:50 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Mark, Some comments inline. > -----Original Message----- > From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] [snip] > In my personal opinion, binary content in SIP messages, > including the Caller Photo & Multimedia Messages is a bad > thing per se and Content Indirection should always be used. > (As Jonathan mentioned, the existing MMS does not send the > content with the notification of the message - you have to > fetch it). I happen to agree with you. CI is a very good idea in general. However, there are issues with it in my opinion, which need to be addressed. For example, CI specs intentionally leave out the publishing part - you simply push the content to a repository and get the URL by some means. Now take the scenario where CI is used in presence. For security reasons, you'd like to get a _different_ random URI per individual watcher. That means subscribing first to winfo, and doing some multiplication function on the CI URI, publish (?!) the same document individually for each watcher... Yikes. The other option is to leave all of this for the PS/composer to take care of. Either way, it's not a straight forward piece of machinery, and needs some text in a spec, IMHO. Also, I don't know whether the notify/fetch is actually a feature of MMS - or a bug (meaning that since there is no way to really push the content all the way, there's a need to first notify). At least my phone currently doesn't prompt me, but goes and fetches the MM automagically. > Having said that, referencing out from the Presence Document > to something which might be at a URL or might be in another > MIME part of the Notification might provide a way forward - > of course I'd still say that these other MIME parts should be > Content-Indirected :-), but at least you have solved the > encoding problem and brought the compression problems into > the same space as Caller-photos etc. Yes, I think we are on the same page here. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 5 20:24:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17719 for ; Wed, 5 Feb 2003 20:24:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h161UFP11532 for simple-archive@odin.ietf.org; Wed, 5 Feb 2003 20:30:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h161UFp11529 for ; Wed, 5 Feb 2003 20:30:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17714 for ; Wed, 5 Feb 2003 20:23:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h161UBp11519; Wed, 5 Feb 2003 20:30:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h161TTp11480 for ; Wed, 5 Feb 2003 20:29:29 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17690 for ; Wed, 5 Feb 2003 20:22:44 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h161QNLc018119; Wed, 5 Feb 2003 19:26:23 -0600 From: "Dean Willis" To: Cc: Subject: RE: [Simple] New I-Ds on partial notification Message-ID: <00ee01c2cd7e$b8511490$43084080@txdwillis> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1D7FD@esebe004.ntc.nokia.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Feb 2003 19:26:05 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I didn't want to imply that it would be free. Points was that > operators would like to implement service based charging for > some services. For example without signaling context being > free users would have to pay for > unanswered calls. So what keeps me from putting the information I want transmitted into the body of an INVITE, which my confederate then does not answer (or declines)? I could probably come up with steganographic techniques to allow me to do Napster-like file sharing using INVITES with fairly normal (and LEGAL) SDP bodies . . . Hey, that's pretty cool, I think I'll work on it in my copious free time. Consider this an IPR declaration. It'll make a nice April 1 RFC. What do you think of "Parasitic Peer-to-Peer Networking using SDP Steganography over SIP in 3G Networks" as a title? Followup, if any, should probably be in a different forum, as this issue really isn't a SIMPLE thing. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 5 23:21:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22009 for ; Wed, 5 Feb 2003 23:21:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h164SCV20196 for simple-archive@odin.ietf.org; Wed, 5 Feb 2003 23:28:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h164SBp20193 for ; Wed, 5 Feb 2003 23:28:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21995 for ; Wed, 5 Feb 2003 23:21:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h164S7p20180; Wed, 5 Feb 2003 23:28:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h164Rsp20166 for ; Wed, 5 Feb 2003 23:27:54 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21989 for ; Wed, 5 Feb 2003 23:21:06 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h164OmYH017276; Wed, 5 Feb 2003 23:24:48 -0500 (EST) Message-ID: <3E41E38C.7090801@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: krisztian.kiss@nokia.com CC: pkyzivat@cisco.com, jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] PUBLISH: a dialog? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Feb 2003 23:24:44 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am still on the fence on this issue. Some responses and thoughts inline: krisztian.kiss@nokia.com wrote: > Hi All, > > I am supporting the dialog initiating PUBLISH method, since that > seems to be a step forward to meet some of the requirements posted to > SIMPLE list recently: > http://mailman.dynamicsoft.com/pipermail/simple/2002-December/002103.html > First, I believe the dialog concept would be preferable to provide > "feedback" to the PUA about the actual result of the publishing > transaction, whether the published XML was successfully composed to > the presence document or not. I agree with that, but I dont see why you need a dialog. I had in mind that the response to PUBLISH is a 200 OK if the published data was accepted, and the response contains the "raw" presence data from other publishers. This raw data could be used by a PUA to, for example, overwrite the presence data from another PUA. > Secondly, in a multi-PUA scenario, a > dialog would also be useful to provide feedback about other PUAs' > activities, e.g. the publishing PUA could learn the presence > information (including the tuple ids) published by other PUAs. I am not as sure there is a need to know when the published data changes, as to be able to fetch it. Considering our one and only use case (going home and then setting the presence from my PC at work to unavailable, since i left it running), the home device doesn't need to know about changes in published information. It just needs to query to find out the set of published data. Does anyone have some use cases to motivate a notification feature on the publication side? Jon Peterson wrote: > However, it isn't clear today if it is necessary to have a longer-term > identifier in the headers of the PUBLISH method, considering that the > presence information itself may contain its own identifiers (like the tuple > ID in PIDF) that could be reused as needed (such as the case in which one > device overwrites presence published by another). I think that, if the only thing you need sequencing for is to determine the most recent tuple or status, the identifiers in the tuples, along with the timestamps, will suffice. You also need to know the source of the publisher, but you don't need a dialog for that. I would argue that the need for some kind of sequencing beyond the timestamps in the tuples arises if we support differential (not partial) publication. In that case, I think you do need some kind of sequencing outside of the tuple id. But, if we don't do that, even partial publication doesn't need sequencing outside of the pidf. The counter-arguments is that its probably a good thing to provide sequencing of published presence data independent of the document type. We may have other formats beyond pidf for specific vertical sources of presence data. The real benefit of the dialog state is the efficiency of avoiding going through proxies for updates and refreshes. You WILL need to refresh, because published presence is soft-state. Managing the soft-state may actually be hard if there is no sequencing provided by the SIP mechanism. The Call-ID/CSeq are required in REGISTER in order to do this. Here is an argument against dialogs. One can imagine that a PUA might actually be this big server that is, for example, collecting geolocation for a large number of users and publishing it into the presence system. It would be nice to not require additional state on that box in order to do the publication. If it could periodically sample the geoloc, construct a presence doc, timestamp it, and send it in a PUBLISH, without needing to remember the call-id or cseq, that would be a good thing, I think. One final comment. If we do add dialog support, we need to add the machinery to clean them up. There needs to be a way for both sides to indicate termination of the dialog. -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 00:05:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23041 for ; Thu, 6 Feb 2003 00:05:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h165CBf22551 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 00:12:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h165CBp22548 for ; Thu, 6 Feb 2003 00:12:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23030 for ; Thu, 6 Feb 2003 00:05:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h165C7p22540; Thu, 6 Feb 2003 00:12:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h165BFp22511 for ; Thu, 6 Feb 2003 00:11:15 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23016 for ; Thu, 6 Feb 2003 00:04:27 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h16584YH017281; Thu, 6 Feb 2003 00:08:04 -0500 (EST) Message-ID: <3E41EDB0.9040907@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: mwatson@nortelnetworks.com, simple@ietf.org Subject: Re: [Simple] New I-Ds on partial notification References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD229@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Feb 2003 00:08:00 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. aki.niemi@nokia.com wrote: > >> In my personal opinion, binary content in SIP messages, including >> the Caller Photo & Multimedia Messages is a bad thing per se and >> Content Indirection should always be used. (As Jonathan mentioned, >> the existing MMS does not send the content with the notification of >> the message - you have to fetch it). > > > I happen to agree with you. CI is a very good idea in general. > However, there are issues with it in my opinion, which need to be > addressed. For example, CI specs intentionally leave out the > publishing part - you simply push the content to a repository and get > the URL by some means. Well, as I have argued, there are multiple ways to do this. INdeed, several are already standardized, include webdav and regular HTTP PUT. Indeed, I know of webdav servers that have recently been sold specifically for IM apps using content indirection. > Now take the scenario where CI is used in > presence. For security reasons, you'd like to get a _different_ > random URI per individual watcher. If the URI is random, which I agree it has to be, what is the benefit of it being random AND different for each watcher? > That means subscribing first to > winfo, and doing some multiplication function on the CI URI, publish > (?!) the same document individually for each watcher... Yikes. I dont follow that... I must admit I am still confused on the technical problems with CI for large presence content. Can you provide a crisp and detailed summary of the problems that you see? It seems the biggest beef is this mysterious charging problem that still eludes me... Anyway, practically speaking how often does my picture change? Seems like the easiest thing is that, from my pc, i put the thing on my web page and then just include the URI to it in my presence document. > The > other option is to leave all of this for the PS/composer to take care > of. Either way, it's not a straight forward piece of machinery, and > needs some text in a spec, IMHO. IMHO, all of the protocol machinery needed for this exists. In that case, I think a description of how it gets integrated probably belongs in the architecture doc that Avshalom and Tony H. are working on. > > Also, I don't know whether the notify/fetch is actually a feature of > MMS - or a bug (meaning that since there is no way to really push the > content all the way, there's a need to first notify). At least my > phone currently doesn't prompt me, but goes and fetches the MM > automagically. A bug? You must be kidding! I think this is a critical feature! Are you telling me that you REALLY want to ALWAYS pay for someone else picture of their kids that they put in a presence doc or IM???? Maybe your phone always pulls it, but perhaps its time to get a new phone ;) -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 00:43:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24229 for ; Thu, 6 Feb 2003 00:43:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h165oBB24119 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 00:50:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h165oAp24116 for ; Thu, 6 Feb 2003 00:50:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24217 for ; Thu, 6 Feb 2003 00:43:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h165o6p24108; Thu, 6 Feb 2003 00:50:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h165nVp24082 for ; Thu, 6 Feb 2003 00:49:31 -0500 Received: from smtp012.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24210 for ; Thu, 6 Feb 2003 00:42:41 -0500 (EST) Received: from 12-235-146-159.client.attbi.com (HELO cranberry) (seancolson@12.235.146.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Feb 2003 05:46:20 -0000 Reply-To: From: "Sean Olson" To: "'Jonathan Rosenberg'" , Cc: , , Subject: RE: [Simple] PUBLISH: a dialog? Message-ID: <000301c2cda3$1708a100$6501a8c0@cranberry> 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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E41E38C.7090801@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Feb 2003 21:46:26 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dialog state for PUBLISH will be a mistake. The more I think about it, the clearer it becomes to me that PUBLISH should be a fixed-up REGISTER. The hardest problem is figuring out when and how to tear down dialog state for PUBLISH particularly if it is the compositor that wants to tear down the dialog. I am recommending that we use Call-ID/CSeq in PUBLISH in an analogous way to the way it is used in REGISTER itself. -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Wednesday, February 05, 2003 8:25 PM To: krisztian.kiss@nokia.com Cc: pkyzivat@cisco.com; jon.peterson@neustar.biz; simple@ietf.org Subject: Re: [Simple] PUBLISH: a dialog? I am still on the fence on this issue. Some responses and thoughts inline: krisztian.kiss@nokia.com wrote: > Hi All, > > I am supporting the dialog initiating PUBLISH method, since that > seems to be a step forward to meet some of the requirements posted to > SIMPLE list recently: > http://mailman.dynamicsoft.com/pipermail/simple/2002-December/002103.htm l > First, I believe the dialog concept would be preferable to provide > "feedback" to the PUA about the actual result of the publishing > transaction, whether the published XML was successfully composed to > the presence document or not. I agree with that, but I dont see why you need a dialog. I had in mind that the response to PUBLISH is a 200 OK if the published data was accepted, and the response contains the "raw" presence data from other publishers. This raw data could be used by a PUA to, for example, overwrite the presence data from another PUA. > Secondly, in a multi-PUA scenario, a > dialog would also be useful to provide feedback about other PUAs' > activities, e.g. the publishing PUA could learn the presence > information (including the tuple ids) published by other PUAs. I am not as sure there is a need to know when the published data changes, as to be able to fetch it. Considering our one and only use case (going home and then setting the presence from my PC at work to unavailable, since i left it running), the home device doesn't need to know about changes in published information. It just needs to query to find out the set of published data. Does anyone have some use cases to motivate a notification feature on the publication side? Jon Peterson wrote: > However, it isn't clear today if it is necessary to have a longer-term > identifier in the headers of the PUBLISH method, considering that the > presence information itself may contain its own identifiers (like the > tuple ID in PIDF) that could be reused as needed (such as the case in > which one device overwrites presence published by another). I think that, if the only thing you need sequencing for is to determine the most recent tuple or status, the identifiers in the tuples, along with the timestamps, will suffice. You also need to know the source of the publisher, but you don't need a dialog for that. I would argue that the need for some kind of sequencing beyond the timestamps in the tuples arises if we support differential (not partial) publication. In that case, I think you do need some kind of sequencing outside of the tuple id. But, if we don't do that, even partial publication doesn't need sequencing outside of the pidf. The counter-arguments is that its probably a good thing to provide sequencing of published presence data independent of the document type. We may have other formats beyond pidf for specific vertical sources of presence data. The real benefit of the dialog state is the efficiency of avoiding going through proxies for updates and refreshes. You WILL need to refresh, because published presence is soft-state. Managing the soft-state may actually be hard if there is no sequencing provided by the SIP mechanism. The Call-ID/CSeq are required in REGISTER in order to do this. Here is an argument against dialogs. One can imagine that a PUA might actually be this big server that is, for example, collecting geolocation for a large number of users and publishing it into the presence system. It would be nice to not require additional state on that box in order to do the publication. If it could periodically sample the geoloc, construct a presence doc, timestamp it, and send it in a PUBLISH, without needing to remember the call-id or cseq, that would be a good thing, I think. One final comment. If we do add dialog support, we need to add the machinery to clean them up. There needs to be a way for both sides to indicate termination of the dialog. -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 01:01:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24551 for ; Thu, 6 Feb 2003 01:01:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16686T25335 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 01:08:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16686p25332 for ; Thu, 6 Feb 2003 01:08:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24546 for ; Thu, 6 Feb 2003 01:01:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16683p25324; Thu, 6 Feb 2003 01:08:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1667tp25305 for ; Thu, 6 Feb 2003 01:07:55 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24540 for ; Thu, 6 Feb 2003 01:01:05 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1664mYH017306 for ; Thu, 6 Feb 2003 01:04:48 -0500 (EST) Message-ID: <3E41FAFB.8000707@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Invisible and RPIDS Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Feb 2003 01:04:43 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I wanted to discuss an interesting feature of existing IM systems, so as to explore how it fits in our evolving presence/RPIDS work. The feature is "invisible". On several systems, you can set your status to invisible. To all watchers, your status is offline, but they can still send you IM, and you will receive them. One can imagine other behaviors, where in invisible mode, I don't receive IM - they are archived, and I retrieve them when I return to visible mode. The concept extends to voice too; one can imagine publishing invisible for a phone, which means watchers see it as CLOSED (using pidf terminology), but calls to it will actually still succeed. I would argue that this is an example of a "transformational policy". That is, there is some PIDF status extension defined to represent invisible. However, there is also a presence policy that says this: IF the watcher is "IM App" don't change anything IF the watcher is anyone else remove all status but basic set basic to CLOSED Its a transformational policy, because its not just restricting who sees what, its changing one of the statuses (basic) from OPEN to CLOSED depending on the watcher. Note that I have also modeled the IM app as a watcher. Thats because the IM app will use the presence status to determine how to handle an IM sent to the user. Here, by IM app, I mean some kind of application server that receives IMs targeted to a user, and applies forwarding, retry, storage and blocking policies. As far as pidf is concerned, one might generalize this as a "visibility" status which indicates various shades of visibility. "invisible" means that I wish for nothing to be revealed to watchers. "partly visible" might mean that only basic is revealed, and everything else is stripped. Another way to view this is that a tuple can represent an application, such as an IM app, a chess game app, or something. There are specific statuses defined for each app, meant for the consumption of an application server in the network, but also visible to watchers, possibly after the application of a transformational policy at the presence server. Thus, the "IM states" might be: open for messages open for high priority only invisible text-only These have a particular interpretation by an IM app server - they would be used to guide its blocking and archiving policy. Note that we have not yet, afaik, discussed the notion that a tuple can represent an application, as opposed to a device or media type. The lines are blurry, no doubt.... -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 01:23:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24929 for ; Thu, 6 Feb 2003 01:23:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h166UCT25971 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 01:30:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h166UCp25968 for ; Thu, 6 Feb 2003 01:30:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24917 for ; Thu, 6 Feb 2003 01:23:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h166U6p25959; Thu, 6 Feb 2003 01:30:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h166TFp25906 for ; Thu, 6 Feb 2003 01:29:15 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24907 for ; Thu, 6 Feb 2003 01:22:23 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h166PaB21827; Thu, 6 Feb 2003 00:25:36 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LNXB31C>; Thu, 6 Feb 2003 00:25:36 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E07BBF26D@zrc2c012.us.nortel.com> From: "Brian Stucker" To: seancolson@yahoo.com, "'Jonathan Rosenberg'" , krisztian.kiss@nokia.com Cc: pkyzivat@cisco.com, jon.peterson@neustar.biz, simple@ietf.org Subject: RE: [Simple] PUBLISH: a dialog? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CDA8.8F1C46B0" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Feb 2003 00:25:35 -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_01C2CDA8.8F1C46B0 Content-Type: text/plain; charset="ISO-8859-1" Although I'm agreeing with you in principle, why do we want to tie ourselves to the callid/cseq? We have no idea what perils may befall those fields as they are not guaranteed to be opaque as they traverse a network with things like BBUAs in them. Why not have the Stream field left in so we know for sure nobody's mucking with our unique identifier? -----Original Message----- From: Sean Olson [mailto:seancolson@yahoo.com] Sent: Wednesday, February 05, 2003 11:46 PM To: 'Jonathan Rosenberg'; krisztian.kiss@nokia.com Cc: pkyzivat@cisco.com; jon.peterson@neustar.biz; simple@ietf.org Subject: RE: [Simple] PUBLISH: a dialog? Dialog state for PUBLISH will be a mistake. The more I think about it, the clearer it becomes to me that PUBLISH should be a fixed-up REGISTER. The hardest problem is figuring out when and how to tear down dialog state for PUBLISH particularly if it is the compositor that wants to tear down the dialog. I am recommending that we use Call-ID/CSeq in PUBLISH in an analogous way to the way it is used in REGISTER itself. -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Wednesday, February 05, 2003 8:25 PM To: krisztian.kiss@nokia.com Cc: pkyzivat@cisco.com; jon.peterson@neustar.biz; simple@ietf.org Subject: Re: [Simple] PUBLISH: a dialog? I am still on the fence on this issue. Some responses and thoughts inline: krisztian.kiss@nokia.com wrote: > Hi All, > > I am supporting the dialog initiating PUBLISH method, since that > seems to be a step forward to meet some of the requirements posted to > SIMPLE list recently: > http://mailman.dynamicsoft.com/pipermail/simple/2002-December/002103.htm l > First, I believe the dialog concept would be preferable to provide > "feedback" to the PUA about the actual result of the publishing > transaction, whether the published XML was successfully composed to > the presence document or not. I agree with that, but I dont see why you need a dialog. I had in mind that the response to PUBLISH is a 200 OK if the published data was accepted, and the response contains the "raw" presence data from other publishers. This raw data could be used by a PUA to, for example, overwrite the presence data from another PUA. > Secondly, in a multi-PUA scenario, a > dialog would also be useful to provide feedback about other PUAs' > activities, e.g. the publishing PUA could learn the presence > information (including the tuple ids) published by other PUAs. I am not as sure there is a need to know when the published data changes, as to be able to fetch it. Considering our one and only use case (going home and then setting the presence from my PC at work to unavailable, since i left it running), the home device doesn't need to know about changes in published information. It just needs to query to find out the set of published data. Does anyone have some use cases to motivate a notification feature on the publication side? Jon Peterson wrote: > However, it isn't clear today if it is necessary to have a longer-term > identifier in the headers of the PUBLISH method, considering that the > presence information itself may contain its own identifiers (like the > tuple ID in PIDF) that could be reused as needed (such as the case in > which one device overwrites presence published by another). I think that, if the only thing you need sequencing for is to determine the most recent tuple or status, the identifiers in the tuples, along with the timestamps, will suffice. You also need to know the source of the publisher, but you don't need a dialog for that. I would argue that the need for some kind of sequencing beyond the timestamps in the tuples arises if we support differential (not partial) publication. In that case, I think you do need some kind of sequencing outside of the tuple id. But, if we don't do that, even partial publication doesn't need sequencing outside of the pidf. The counter-arguments is that its probably a good thing to provide sequencing of published presence data independent of the document type. We may have other formats beyond pidf for specific vertical sources of presence data. The real benefit of the dialog state is the efficiency of avoiding going through proxies for updates and refreshes. You WILL need to refresh, because published presence is soft-state. Managing the soft-state may actually be hard if there is no sequencing provided by the SIP mechanism. The Call-ID/CSeq are required in REGISTER in order to do this. Here is an argument against dialogs. One can imagine that a PUA might actually be this big server that is, for example, collecting geolocation for a large number of users and publishing it into the presence system. It would be nice to not require additional state on that box in order to do the publication. If it could periodically sample the geoloc, construct a presence doc, timestamp it, and send it in a PUBLISH, without needing to remember the call-id or cseq, that would be a good thing, I think. One final comment. If we do add dialog support, we need to add the machinery to clean them up. There needs to be a way for both sides to indicate termination of the dialog. -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01C2CDA8.8F1C46B0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] PUBLISH: a dialog?

Although I'm agreeing with you in principle, why do = we want to tie ourselves to the callid/cseq?

We have no idea what perils may befall those fields = as they are not guaranteed to be opaque as they traverse a network with = things like BBUAs in them.

Why not have the Stream field left in so we know for = sure nobody's mucking with our unique identifier?

-----Original Message-----
From: Sean Olson [mailto:seancolson@yahoo.com]
Sent: Wednesday, February 05, 2003 11:46 PM
To: 'Jonathan Rosenberg'; = krisztian.kiss@nokia.com
Cc: pkyzivat@cisco.com; jon.peterson@neustar.biz; = simple@ietf.org
Subject: RE: [Simple] PUBLISH: a dialog?


Dialog state for PUBLISH will be a mistake. The more = I think about it,
the clearer it
becomes to me that PUBLISH should be a fixed-up = REGISTER. The hardest
problem is figuring
out when and how to tear down dialog state for = PUBLISH particularly if
it is the compositor
that wants to tear down the dialog. I am = recommending that we use
Call-ID/CSeq in PUBLISH in
an analogous way to the way it is used in REGISTER = itself.

-----Original Message-----
From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] = On Behalf Of
Jonathan Rosenberg
Sent: Wednesday, February 05, 2003 8:25 PM
To: krisztian.kiss@nokia.com
Cc: pkyzivat@cisco.com; jon.peterson@neustar.biz; = simple@ietf.org
Subject: Re: [Simple] PUBLISH: a dialog?


I am still on the fence on this issue. Some responses = and thoughts
inline:

krisztian.kiss@nokia.com wrote:
 > Hi All,
 >
 > I am supporting the dialog initiating = PUBLISH method, since that  >
seems to be a step forward to meet some of the = requirements posted to  >
SIMPLE list recently:  >
http://mailman.dynamicsoft.com/pipermail/simple/2002-D= ecember/002103.htm
l
 >  First, I believe the dialog concept = would be preferable to provide
> "feedback" to the PUA about the = actual result of the publishing  >
transaction, whether the published XML was = successfully composed to  >
the presence document or not.

I agree with that, but I dont see why you need a = dialog. I had in mind
that the response to PUBLISH is a 200 OK if the = published data was
accepted, and the response contains the = "raw" presence data from other
publishers. This raw data could be used by a PUA to, = for example,
overwrite the presence data from another PUA.

 > Secondly, in a multi-PUA scenario, = a
 > dialog would also be useful to provide = feedback about other PUAs'  >
activities, e.g. the publishing PUA could learn the = presence  >
information (including the tuple ids) published by = other PUAs.

I am not as sure there is a need to know when the = published data
changes, as to be able to fetch it. Considering our = one and only use
case (going home and then setting the presence from = my PC at work to
unavailable, since i left it running), the home = device doesn't need to
know about changes in published information. It just = needs to query to
find out the set of published data.

Does anyone have some use cases to motivate a = notification feature on
the publication side?

Jon Peterson wrote:
> However, it isn't clear today if it is = necessary to have a longer-term

> identifier in the headers of the PUBLISH method, = considering that the
> presence information itself may contain its own = identifiers (like the
> tuple ID in PIDF) that could be reused as = needed (such as the case in
> which one device overwrites presence published = by another).

I think that, if the only thing you need sequencing = for is to determine
the most recent tuple or status, the identifiers in = the tuples, along
with the timestamps, will suffice. You also need to = know the source of
the publisher, but you don't need a dialog for = that.

I would argue that the need for some kind of = sequencing beyond the
timestamps in the tuples arises if we support = differential (not partial)

publication. In that case, I think you do need some = kind of sequencing
outside of the tuple id. But, if we don't do that, = even partial
publication doesn't need sequencing outside of the = pidf.

The counter-arguments is that its probably a good = thing to provide
sequencing of published presence data independent of = the document type.
We may have other formats beyond pidf for specific = vertical sources of
presence data.

The real benefit of the dialog state is the = efficiency of avoiding going

through proxies for updates and refreshes. You WILL = need to refresh,
because published presence is soft-state. Managing = the soft-state may
actually be hard if there is no sequencing provided = by the SIP
mechanism. The Call-ID/CSeq are required in REGISTER = in order to do
this.

Here is an argument against dialogs. One can imagine = that a PUA might
actually be this big server that is, for example, = collecting geolocation

for a large number of users and publishing it into = the presence system.
It would be nice to not require additional state on = that box in order to

do the publication. If it could periodically sample = the geoloc,
construct a presence doc, timestamp it, and send it = in a PUBLISH,
without needing to remember the call-id or cseq, = that would be a good
thing, I think.


One final comment. If we do add dialog support, we = need to add the
machinery to clean them up. There needs to be a way = for both sides to
indicate termination of the dialog.

-Jonathan R.

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

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

------_=_NextPart_001_01C2CDA8.8F1C46B0-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 03:58:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09079 for ; Thu, 6 Feb 2003 03:58:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1695Kw13659 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 04:05:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1695Kp13656 for ; Thu, 6 Feb 2003 04:05:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09061 for ; Thu, 6 Feb 2003 03:58:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1695Fp13635; Thu, 6 Feb 2003 04:05:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1694Ap13538 for ; Thu, 6 Feb 2003 04:04:10 -0500 Received: from il-tlv-smtpout2.icomverse.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09037 for ; Thu, 6 Feb 2003 03:57:15 -0500 (EST) Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h1690eR10018; Thu, 6 Feb 2003 11:00:40 +0200 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Feb 2003 11:00:45 +0200 Message-ID: <385D702A9C11D511A9E90008C7160AD505454037@ismail1.comverse.com> From: Cnaan Oded To: "'simple@ietf.org'" Cc: "'Jonathan Rosenberg'" Subject: RE: [Simple] Invisible and RPIDS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CDBE.3B30290C" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Feb 2003 11:00:44 +0200 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_01C2CDBE.3B30290C Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Note that we have not yet, afaik, discussed the notion that a > tuple can represent an application, as opposed to a device or media type. The > lines are blurry, no doubt.... > > -Jonathan R. > -- As far as I understand, tuples may represent any object (e.g., device, service etc.) as long as they are consistent and that there is an agreement between the PS and the watcher what these tuples represent. It seems to me that there are clear use cases for having tuples represent objects other than devices. Following Jonathan's example of an IM app, consider a case where a certain user is registered to 2 services, IM and Gaming, and assuming, for sake of the example, that these services are not interconnected. An IM app may want to receive only the 'IM Service" tuple that it has been publishing as this is the only information relevant for its users. Gaming information is not relevant for the IM app as it does not populate this information to the watchers. Note that composing a document in a 'service-view' means that the information is arranged in a different order and that attributes not relevant to that service are left out. For example, an "IM-service" tuple may include the devices, from which the user is connected to the IM, their capabilities, the status and so on. The question is how should watchers know what kind of object tuples represent in the document they receive from the PS. You can also argue that the watcher should be able to request the PS to compose the document using a given representation scheme. It seems that currently there are no mechanisms in SIMPLE for doing that. Oded C. ------_=_NextPart_001_01C2CDBE.3B30290C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Invisible and RPIDS

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>
> Note that we have not yet, afaik, discussed the = notion that a
> tuple can represent an application, as opposed = to a device or media type. The
> lines are blurry, no doubt....
>
> -Jonathan R.
> --

As far as I understand, tuples may represent any = object (e.g., device, service etc.) as long as they are consistent and = that there is an agreement between the PS and the watcher what these = tuples represent.

It seems to me that there are clear use cases for = having tuples represent objects other than devices. Following = Jonathan's example of an IM app, consider a case where a certain user = is registered to 2 services, IM and Gaming, and assuming, for sake of = the example, that these services are not interconnected. An IM app may = want to receive only the 'IM Service" tuple that it has been = publishing as this is the only information relevant for its users. = Gaming information is not relevant for the IM app as it does not = populate this information to the watchers.

Note that composing a document in a 'service-view' = means that the information is arranged in a different order and that = attributes not relevant to that service are left out. For example, an = "IM-service" tuple may include the devices, from which the = user is connected to the IM, their capabilities, the status and so = on.

The question is how should watchers know what kind of = object tuples represent in the document they receive from the PS. You = can also argue that the watcher should be able to request the PS to = compose the document using a given representation scheme. It seems that = currently there are no mechanisms in SIMPLE for doing that.

Oded C.

------_=_NextPart_001_01C2CDBE.3B30290C-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 07:38:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15869 for ; Thu, 6 Feb 2003 07:38:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16CjKY29525 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 07:45:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16CjKp29522 for ; Thu, 6 Feb 2003 07:45:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15849 for ; Thu, 6 Feb 2003 07:38:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16CjGp29512; Thu, 6 Feb 2003 07:45:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Ciqp29475 for ; Thu, 6 Feb 2003 07:44:52 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15840 for ; Thu, 6 Feb 2003 07:37:53 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h16CiBm09931 for ; Thu, 6 Feb 2003 14:44:12 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Feb 2003 14:41:31 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 14:41:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] New I-Ds on partial notification Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194514A@esebe013.ntc.nokia.com> Thread-Topic: [Simple] New I-Ds on partial notification Thread-Index: AcLNncAyzqwWiusMSful2+0mHzNfewANio/Q To: Cc: , X-OriginalArrivalTime: 06 Feb 2003 12:41:30.0803 (UTC) FILETIME=[12E18030:01C2CDDD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16Ciqp29480 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Feb 2003 14:41:30 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Inline. > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] [snip] > > Also, I don't know whether the notify/fetch is actually a > feature of > > MMS - or a bug (meaning that since there is no way to > really push the > > content all the way, there's a need to first notify). At least my > > phone currently doesn't prompt me, but goes and fetches the MM > > automagically. > > A bug? You must be kidding! I think this is a critical > feature! Are you > telling me that you REALLY want to ALWAYS pay for someone > else picture > of their kids that they put in a presence doc or IM???? Maybe > your phone > always pulls it, but perhaps its time to get a new phone ;) Aha! I think we're in the core of the charging problem here. The MMS charging model is "sender pays". So receiving an MMS is always free for me. With this model, the only inconvenience experienced by me is having to delete those family pics of my friends, since receiving them had flat rate or no charging on it. Anyway, I agree we should probably try to write up the problem description in a clearer way. It seems that the authorization/storage concerns aren't that major after all, so the essence is probably this charging issue. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 09:00:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18055 for ; Thu, 6 Feb 2003 09:00:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16E6qS01518 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 09:06:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16E6qp01515 for ; Thu, 6 Feb 2003 09:06:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17998 for ; Thu, 6 Feb 2003 08:59:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16E6Xp01463; Thu, 6 Feb 2003 09:06:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16E5Qp01383 for ; Thu, 6 Feb 2003 09:05:26 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17929 for ; Thu, 6 Feb 2003 08:58:22 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h16E4em19461 for ; Thu, 6 Feb 2003 16:04:41 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Feb 2003 16:02:00 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 16:02:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CDE8.51240C46" Subject: RE: [Simple] New I-Ds on partial notification Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1D80B@esebe004.ntc.nokia.com> Thread-Topic: [Simple] New I-Ds on partial notification Thread-Index: AcLNRAifmfKfCEzdRpqD4ZaESzg1GQAbdVuQ To: , , X-OriginalArrivalTime: 06 Feb 2003 14:02:00.0368 (UTC) FILETIME=[5186A300:01C2CDE8] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Feb 2003 16:01:59 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2CDE8.51240C46 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 One issue seems to be that how does CI (using HTTP) help in case of compression? What I mean is that you probably want to compress all the protocol data to and from your UA. If compression fails with SIP how is it better with HTTP? Or are you saying that there should not be any compression for HTTP? And if you then want to compress HTTP you probably need dictionaries for HTTP and also your HTTP server and UA would need to support it.=20 =20 - Mikko=20 -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com]=20 Sent: 05 February, 2003 20:20 To: Niemi Aki (NMP/Helsinki); simple@ietf.org Subject: RE: [Simple] New I-Ds on partial notification =09 =09 Aki,=20 Well, it depends on the compression algorithm used. Certainly the simple ones do little more that send a string of pairs to reference strings which occured earlier in the data stream - of course with some way of escaping to literal data. So, certainly, large in-band binary content will reduce the effectiveness of these schemes. You could mitigate this by ensuring that the static dictionary never goes out of view, or, for example, only storing the first X octets of each message, where X is chosen to usually cover the headers and SDP. Other schemes build up a dictionary of codewords e.g. in LZW then the codebook is built up by allocating a new codeword for the previous phase plus the next character. Common phrases will end up appearing in more codewords and in longer referenced strings. I think this would not be so affected by raw binary data, since this wouldn't disrupt the codebook already built. However, I'm not so sure this is the best scheme for SIP signalling, since it takes quite a while to build up the codebook. You want, for example, to be referencing back to the entire Request URI when it appears again in the To field a few octets later, and then do the same in subsequent requests/responses - not sure LZW would get you this. DEFLATE, if I remember correctly, does LZW & then Huffman encodes the result.=20 In my personal opinion, binary content in SIP messages, including the Caller Photo & Multimedia Messages is a bad thing per se and Content Indirection should always be used. (As Jonathan mentioned, the existing MMS does not send the content with the notification of the message - you have to fetch it). Having said that, referencing out from the Presence Document to something which might be at a URL or might be in another MIME part of the Notification might provide a way forward - of course I'd still say that these other MIME parts should be Content-Indirected :-), but at least you have solved the encoding problem and brought the compression problems into the same space as Caller-photos etc. ...Mark=20 > -----Original Message-----=20 > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]=20 > Sent: 05 February 2003 17:51=20 > To: Watson, Mark [MOP:EP10:EXCH]; simple@ietf.org=20 > Subject: RE: [Simple] New I-Ds on partial notification=20 >=20 >=20 > Is this really so? I would hope SIP compression doesn't break=20 > because of large (binary) content in the message payload. It=20 > would mean sending a jpeg mug shot in an INVITE will also=20 > break it, along with MESSAGE with any multimedia in it.=20 >=20 > And I agree, base64 encoding may not be the best way. How=20 > about including the content using cids and a MIME multipart?=20 > Just a thought.=20 >=20 > Cheers,=20 > Aki=20 >=20 >=20 > -----Original Message-----=20 > From: ext Mark Watson [mailto:mwatson@nortelnetworks.com]=20 > Sent: 05 February, 2003 19:21=20 > To: simple@ietf.org=20 > Subject: RE: [Simple] New I-Ds on partial notification=20 >=20 >=20 > One more reason why in-line content breaks SIP Compression:=20 > Most compression schemes have a limit on how far they can=20 > 'reach back' into the message stream to reference repeated=20 > strings. This distance may be further limited by the UDVM=20 > memory. Depending on the compression scheme, large in-line=20 > content may cause all useful state to be lost, so that the=20 > compression ratio drops right down.=20 >=20 > ...Mark=20 > -----Original Message-----=20 > From: Watson, Mark [MOP:EP10:EXCH]=20 > Sent: 05 February 2003 15:48=20 > To: 'mikko.lonnfors@nokia.com'; simple@ietf.org=20 > Subject: RE: [Simple] New I-Ds on partial notification=20 >=20 >=20 > I am really skeptical about the suggestion that large binary=20 > data content will be included in-line in the presence=20 > document itself. How will this be done ?=20 > Unless I mis-understand, the presence document is an XML=20 > document encoding in UTF-8 - i.e. it's a text document. Can=20 > you really include raw binary data in-line ?? What=20 > content-transfer-encoding will you use ? How will a standard=20 > XML parser react to this ? Does XML have a mechanisms for=20 > indicating that arbitrary binary data follows and indicating=20 > the length of that data ?=20 > If the binary data is e.g. base64 encoded, then you've=20 > immediately broken your efficiency requirement. Even if the=20 > raw binary data can be included in-line, the chances are that=20 > any SIP compression on the access link will end up expanding=20 > this portion of the message. (That is unless the compressor=20 > in use is specifically designed with the requirement to=20 > handle arbitrary binary data efficiently. But since the=20 > compressor is chosen by the edge proxy, how can you know this ?)=20 > I would expect SIP compressors to be optimised to handle=20 > text-based messages and, if only for this reason, I think we=20 > should generally try and stick with text based signalling=20 > within the SIP message (and yes, we do have to do something=20 > about S/MIME encryption here!). As I mentioned at the=20 > 3GPP/IETF workshop that we have to pay continuing attention=20 > to the compressibility of SIP messages.=20 > There have been many threads on the general undesirability of=20 > using SIP to transport large content files around. Further,=20 > on a 3GPP-specific note, this approach would make it much=20 > more difficult to get any kind of reliable idea of the=20 > bandwidth/QoS requirements for the signalling-specific radio=20 > resource. Whilst you may wish to allow this resource to be=20 > used for content as well, I do not think people should be=20 > mandated to do this.=20 > Finally, one of your requirements is to cope with devices of=20 > various form-factors/capabilities and the ability to render=20 > multi-media content is one capability which varies greatly=20 > from device to device - I really do not want to send a video=20 > clip even once to a device which can't render it.=20 > I do not see what the big deal is with including a URI for=20 > any such content in the Presence Document. This has so many=20 > advantages:=20 > a) The content is only sent when it changes (even with your=20 > proposal, it is sent at least every time a watcher subscribes) > b) The content is only sent to devices which can render it=20 > c) The content need only be sent when the device actually=20 > needs to render it=20 > Jonathan explained how security could easily be made no worse=20 > than for in-line content.=20 > On charging you solution is to require that this data is=20 > charged in the same way as the rest of SIP signalling - but=20 > this solution does not imply that the data is carried *in*=20 > SIP signalling. If this is what you want to do, then just=20 > allow HTTP requests to a local HTTP-proxy (designated for=20 > this purpose) to use the signalling resource.=20 > Until we've bottomed out this in-line content question, I=20 > don't see how we can conclude on whether partial=20 > notifications are valuable or not.=20 > Regards,=20 > Mark=20 > -----Original Message-----=20 > From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com]=20 > Sent: 28 January 2003 07:35=20 > To: simple@ietf.org=20 > Subject: [Simple] New I-Ds on partial notification=20 >=20 >=20 > Hi,=20 > Here are links to two new drafts which deal with partial=20 > presence notifications.=20 > Requirements are discussed here:=20 > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-pres > info-deliv-reqs-00.txt=20 > A Presence service implemented using SIMPLE has some constraints for=20 > delivering presence information to devices with low data processing=20 > capabilities, small display, and limited battery power. Other=20 > limitations can be caused by the interface between the terminal and=20 > the network, i.e. over radio links with high latency and low=20 > bandwidth. This memo presents requirements for a solution that aids=20 > in reducing the impacts of those constrains and increasing=20 > efficiency.=20 > And the actual solution is described here:=20 > http://www.ietf.org/internet-drafts/draft-lonnofors-simple-par > tial-notify-00.txt=20 > A Presence service implemented using SIMPLE has some constraints for=20 > delivering presence information to devices with low data processing=20 > capabilities, small display, and limited battery power. Other=20 > limitations can be caused by the interface between the terminal and=20 > the network, i.e. over radio links with high latency and low=20 > bandwidth. This memo presents a solution that aids in reducing the=20 > impact of those constrains and increasing efficiency, by introducing=20 > a new MIME-type partial notifications and a Require header=20 > extension partial-notification.=20 > All comments are most welcome.=20 > Regards=20 > - Mikko=20 >=20 ------_=_NextPart_001_01C2CDE8.51240C46 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
One=20 issue seems to be that how does CI (using HTTP) help in case of = compression?=20 What I mean is that you probably want to compress all the protocol = data to=20 and from your UA. If compression fails with SIP how is it better = with HTTP?=20 Or are you saying that there should not be any compression for=20 HTTP? And if you then want to compress HTTP you probably need = dictionaries=20 for HTTP and also your HTTP server and UA would need to support it.=20
 
-=20 Mikko 
-----Original Message-----
From: ext = Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: 05 February, 2003 = 20:20
To: Niemi Aki (NMP/Helsinki);=20 simple@ietf.org
Subject: RE: [Simple] New I-Ds on partial=20 notification

Aki,

Well, it depends on the compression algorithm used. = Certainly=20 the simple ones do little more that send a string of = <offset,length>=20 pairs to reference strings which occured earlier in the data stream - = of=20 course with some way of escaping to literal data. So, certainly, large = in-band=20 binary content will reduce the effectiveness of these = schemes.

You could mitigate this by ensuring that the static = dictionary=20 never goes out of view, or, for example, only storing the first X = octets of=20 each message, where X is chosen to usually cover the headers and=20 SDP.

Other schemes build up a dictionary of codewords = e.g. in LZW=20 then the codebook is built up by allocating a new codeword for the = previous=20 phase plus the next character. Common phrases will end up appearing in = more=20 codewords and in longer referenced strings. I think this would not be = so=20 affected by raw binary data, since this wouldn't disrupt the codebook = already=20 built.

However, I'm not so sure this is the best scheme for = SIP=20 signalling, since it takes quite a while to build up the codebook. You = want,=20 for example, to be referencing back to the entire Request URI when it = appears=20 again in the To field a few octets later, and then do the same in = subsequent=20 requests/responses - not sure LZW would get you this.

DEFLATE, if I remember correctly, does LZW & = then Huffman=20 encodes the result.

In my personal opinion, binary content in SIP = messages,=20 including the Caller Photo & Multimedia Messages is a bad thing = per se and=20 Content Indirection should always be used. (As Jonathan mentioned, the = existing MMS does not send the content with the notification of the = message -=20 you have to fetch it).

Having said that, referencing out from the Presence = Document=20 to something which might be at a URL or might be in another MIME part = of the=20 Notification might provide a way forward - of course I'd still say = that these=20 other MIME parts should be Content-Indirected :-), but at least you = have=20 solved the encoding problem and brought the compression problems into = the same=20 space as Caller-photos etc.

...Mark

> -----Original Message-----
>=20 From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]=20
> Sent: 05 February 2003 17:51
> To: Watson, Mark [MOP:EP10:EXCH]; simple@ietf.org =
> Subject: RE: [Simple] New I-Ds on partial = notification=20
>
> =
> Is this really so? I would hope SIP compression doesn't = break=20
> because of large (binary) content in = the message=20 payload. It
> would mean sending a jpeg = mug shot in=20 an INVITE will also
> break it, along = with MESSAGE=20 with any multimedia in it.
> =
> And I agree, base64 encoding may not be the best way. = How=20
> about including the content using cids = and a MIME=20 multipart?
> Just a thought. =
>
> Cheers,
>=20 Aki
>
> =
> -----Original Message-----
> From: ext=20 Mark Watson [mailto:mwatson@nortelnetworks.= com]=20
> Sent: 05 February, 2003 19:21
> To: simple@ietf.org
> = Subject: RE:=20 [Simple] New I-Ds on partial notification
>=20
>
> One more = reason why=20 in-line content breaks SIP Compression:
> = Most=20 compression schemes have a limit on how far they can
> 'reach back' into the message stream to reference = repeated=20
> strings. This distance may be further = limited by=20 the UDVM
> memory. Depending on the = compression=20 scheme, large in-line
> content may cause = all=20 useful state to be lost, so that the
> = compression=20 ratio drops right down.
> =
> ...Mark
> -----Original=20 Message-----
> From: Watson, Mark = [MOP:EP10:EXCH]=20
> Sent: 05 February 2003 15:48 =
> To: 'mikko.lonnfors@nokia.com'; simple@ietf.org =
> Subject: RE: [Simple] New I-Ds on partial = notification=20
>
> =
> I am really skeptical about the suggestion that large = binary=20
> data content will be included in-line = in the=20 presence
> document itself. How will this = be done=20 ?
> Unless I mis-understand, the presence = document=20 is an XML
> document encoding in UTF-8 - = i.e. it's=20 a text document. Can
> you really include = raw=20 binary data in-line ?? What
>=20 content-transfer-encoding will you use ? How will a standard =
> XML parser react to this ? Does XML have a mechanisms = for=20
> indicating that arbitrary binary data = follows and=20 indicating
> the length of that data = ?=20
> If the binary data is e.g. base64 encoded, = then you've=20
> immediately broken your efficiency = requirement.=20 Even if the
> raw binary data can be = included=20 in-line, the chances are that
> any SIP = compression=20 on the access link will end up expanding
> this=20 portion of the message. (That is unless the compressor =
> in use is specifically designed with the requirement to=20
> handle arbitrary binary data = efficiently. But=20 since the
> compressor is chosen by the = edge proxy,=20 how can you know this ?)
> I would expect = SIP=20 compressors to be optimised to handle
> = text-based=20 messages and, if only for this reason, I think we
>=20 should generally try and stick with text based signalling =
> within the SIP message (and yes, we do have to do = something=20
> about S/MIME encryption here!). As I = mentioned at=20 the
> 3GPP/IETF workshop that we have to = pay=20 continuing attention
> to the = compressibility of=20 SIP messages.
> There have been many = threads on the=20 general undesirability of
> using SIP to = transport=20 large content files around. Further,
> on = a=20 3GPP-specific note, this approach would make it much
> more difficult to get any kind of reliable idea of the=20
> bandwidth/QoS requirements for the=20 signalling-specific radio
> resource. = Whilst you=20 may wish to allow this resource to be
> = used for=20 content as well, I do not think people should be
>=20 mandated to do this.
> Finally, one of = your=20 requirements is to cope with devices of
> = various=20 form-factors/capabilities and the ability to render
> multi-media content is one capability which varies = greatly=20
> from device to device - I really do not = want to=20 send a video
> clip even once to a device = which=20 can't render it.
> I do not see what the = big deal=20 is with including a URI for
> any such = content in=20 the Presence Document. This has so many
> = advantages:
> a) The content is only sent = when it=20 changes (even with your
> proposal, it is = sent at=20 least every time a watcher subscribes)
> = b) The=20 content is only sent to devices which can render it
> c) The content need only be sent when the device = actually=20
> needs to render it
>=20 Jonathan explained how security could easily be made no worse =
> than for in-line content.
> = On charging=20 you solution is to require that this data is
>=20 charged in the same way as the rest of SIP signalling - but =
> this solution does not imply that the data is carried = *in*=20
> SIP signalling. If this is what you = want to do,=20 then just
> allow HTTP requests to a = local=20 HTTP-proxy (designated for
> this = purpose) to use=20 the signalling resource.
> Until we've = bottomed out=20 this in-line content question, I
> don't = see how we=20 can conclude on whether partial
> = notifications are=20 valuable or not.
> Regards, =
> Mark
> -----Original = Message-----=20
> From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com<= /A>]=20
> Sent: 28 January 2003 07:35 =
> To: simple@ietf.org
> = Subject: [Simple]=20 New I-Ds on partial notification
> =
>
> Hi,
> Here=20 are links to two new drafts which deal with partial
> presence notifications.
> = Requirements=20 are discussed here:
> h= ttp://www.ietf.org/internet-drafts/draft-lonnfors-simple-pres =
> info-deliv-reqs-00.txt
> A=20 Presence service implemented using SIMPLE has some constraints for=20
> delivering presence information to = devices with=20 low data processing
> capabilities, small = display,=20 and limited battery power. Other
> = limitations can=20 be caused by the interface between the terminal and
> the network, i.e. over radio links with high latency and = low=20
> bandwidth. This memo presents = requirements for a=20 solution that aids
> in reducing the = impacts of=20 those constrains and increasing
> = efficiency.=20
> And the actual solution is described = here:=20
> h= ttp://www.ietf.org/internet-drafts/draft-lonnofors-simple-par =
> tial-notify-00.txt
> A=20 Presence service implemented using SIMPLE has some constraints for=20
> delivering presence information to = devices with=20 low data processing
> capabilities, small = display,=20 and limited battery power. Other
> = limitations can=20 be caused by the interface between the terminal and
> the network, i.e. over radio links with high latency and = low=20
> bandwidth. This memo presents a = solution that=20 aids in reducing the
> impact of those = constrains=20 and increasing efficiency, by introducing
> a new=20 MIME-type partial notifications and a Require header
> extension partial-notification.
> All=20 comments are most welcome.
> Regards=20
> - Mikko
>=20

=00 ------_=_NextPart_001_01C2CDE8.51240C46-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 09:07:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18190 for ; Thu, 6 Feb 2003 09:07:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16EE6t02414 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 09:14:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16EE5p02408 for ; Thu, 6 Feb 2003 09:14:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18175 for ; Thu, 6 Feb 2003 09:07:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16EE2p02400; Thu, 6 Feb 2003 09:14:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16ED5p02357 for ; Thu, 6 Feb 2003 09:13:05 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18166 for ; Thu, 6 Feb 2003 09:06:04 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h16E9eSO001221 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Feb 2003 09:09:41 -0500 (EST) Message-ID: <3E426CAF.4030209@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@ietf.org Subject: Re: [Simple] Invisible and RPIDS References: <3E41FAFB.8000707@dynamicsoft.com> In-Reply-To: <3E41FAFB.8000707@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Feb 2003 09:09:51 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I believe this can be done already in RPIDS. I could label certain states with keywords that are recognized by my policy script, which then transforms them into the appropriate tuples before delivery to watchers. (Or, the transformation could depend on the presence data itself, e.g., on time of day or other clues. For example, I could automatically declare myself selectively invisible when my says 'meeting'.) This doesn't seem fundamentally different from other selection or filtering requirements. Thus, I'm not sure we want to create a custom mechanism for this. Jonathan Rosenberg wrote: > I wanted to discuss an interesting feature of existing IM systems, so as > to explore how it fits in our evolving presence/RPIDS work. > > The feature is "invisible". On several systems, you can set your status > to invisible. To all watchers, your status is offline, but they can > still send you IM, and you will receive them. One can imagine other > behaviors, where in invisible mode, I don't receive IM - they are > archived, and I retrieve them when I return to visible mode. > > The concept extends to voice too; one can imagine publishing invisible > for a phone, which means watchers see it as CLOSED (using pidf > terminology), but calls to it will actually still succeed. > > I would argue that this is an example of a "transformational policy". > That is, there is some PIDF status extension defined to represent > invisible. However, there is also a presence policy that says this: > > IF the watcher is "IM App" > don't change anything > IF the watcher is anyone else > remove all status but basic > set basic to CLOSED > > Its a transformational policy, because its not just restricting who sees > what, its changing one of the statuses (basic) from OPEN to CLOSED > depending on the watcher. > > Note that I have also modeled the IM app as a watcher. Thats because the > IM app will use the presence status to determine how to handle an IM > sent to the user. Here, by IM app, I mean some kind of application > server that receives IMs targeted to a user, and applies forwarding, > retry, storage and blocking policies. > > As far as pidf is concerned, one might generalize this as a "visibility" > status which indicates various shades of visibility. "invisible" means > that I wish for nothing to be revealed to watchers. "partly visible" > might mean that only basic is revealed, and everything else is stripped. > > Another way to view this is that a tuple can represent an application, > such as an IM app, a chess game app, or something. There are specific > statuses defined for each app, meant for the consumption of an > application server in the network, but also visible to watchers, > possibly after the application of a transformational policy at the > presence server. Thus, the "IM states" might be: > > open for messages > open for high priority only > invisible > text-only > > These have a particular interpretation by an IM app server - they would > be used to guide its blocking and archiving policy. > > Note that we have not yet, afaik, discussed the notion that a tuple can > represent an application, as opposed to a device or media type. The > lines are blurry, no doubt.... > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 09:14:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18393 for ; Thu, 6 Feb 2003 09:14:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16ELDK02741 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 09:21:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16ELDp02736 for ; Thu, 6 Feb 2003 09:21:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18388 for ; Thu, 6 Feb 2003 09:14:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16EL5p02726; Thu, 6 Feb 2003 09:21:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16EKup02711 for ; Thu, 6 Feb 2003 09:20:56 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18380 for ; Thu, 6 Feb 2003 09:13:55 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (europem01.nt.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h16EHTP26316; Thu, 6 Feb 2003 14:17:29 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DCH0Q0Y; Thu, 6 Feb 2003 14:17:30 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1LVBWTQD>; Thu, 6 Feb 2003 14:17:17 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'mikko.lonnfors@nokia.com'" , aki.niemi@nokia.com, simple@ietf.org Subject: RE: [Simple] New I-Ds on partial notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CDEA.72EE1B66" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Feb 2003 14:17:15 -0000 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_01C2CDEA.72EE1B66 Content-Type: text/plain; charset="iso-8859-1" Mikko, I would expect SIGCOMP compressors to be highly optimised for SIP. You can achieve extremely high compression gains if you choose the right compressor. My point below was not just that arbitrary data included inline would not compress well, but that the presence of this data might reduce the effectiveness of the compression on the rest of the SIP messages, because of the effect this arbitrary data has on the (dynamic) dictionary. A key feature of SIP messages is that they contain a few long strings which are then repeated in their entirity a few lines later or in later messages. Basically these are the URIs which appear in To/From/Via/Route/Record-Route but there are also things like the pre-conditions attributes in the SDP which are very verbose and may be repeated for every media line. A compression scheme which can efficiently reference these strings appearing earlier in the message, or in a previous message, will work well for SIP. If there's 10k of in-line content in a message which blows out the dynamic dictionary, then you may lose this ability to reference. (But then if there's 10k of content in the message I'm not so sure why you care about reducing the SIP message headers from 900 to 400 octets, or whatever.) It would be wise to compress HTTP traffic as well - in fact it would not be unwise to compress all traffic on the wireless link (I think most analog modems use some form of compression on the low-bandwidth links that they provide) using some generic compression scheme. Compression for HTTP (or generic) traffic wouldn't need a specific dictionary. There aren't enough HTTP Headers, compared to the size of the arbitrary HTTP bodies, for it to be worth bothering. SIP is different, because we expect the majority of octets of most messages to be SIP headers or SDP. If you put large in-line content in SIP, you make it just like HTTP in this respect - you might as well use generic compression at the link layer instead of SIGCOMP. ...Mark -----Original Message----- From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com] Sent: 06 February 2003 14:02 To: Watson, Mark [MOP:EP10:EXCH]; aki.niemi@nokia.com; simple@ietf.org Subject: RE: [Simple] New I-Ds on partial notification Hi, One issue seems to be that how does CI (using HTTP) help in case of compression? What I mean is that you probably want to compress all the protocol data to and from your UA. If compression fails with SIP how is it better with HTTP? Or are you saying that there should not be any compression for HTTP? And if you then want to compress HTTP you probably need dictionaries for HTTP and also your HTTP server and UA would need to support it. - Mikko -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: 05 February, 2003 20:20 To: Niemi Aki (NMP/Helsinki); simple@ietf.org Subject: RE: [Simple] New I-Ds on partial notification Aki, Well, it depends on the compression algorithm used. Certainly the simple ones do little more that send a string of pairs to reference strings which occured earlier in the data stream - of course with some way of escaping to literal data. So, certainly, large in-band binary content will reduce the effectiveness of these schemes. You could mitigate this by ensuring that the static dictionary never goes out of view, or, for example, only storing the first X octets of each message, where X is chosen to usually cover the headers and SDP. Other schemes build up a dictionary of codewords e.g. in LZW then the codebook is built up by allocating a new codeword for the previous phase plus the next character. Common phrases will end up appearing in more codewords and in longer referenced strings. I think this would not be so affected by raw binary data, since this wouldn't disrupt the codebook already built. However, I'm not so sure this is the best scheme for SIP signalling, since it takes quite a while to build up the codebook. You want, for example, to be referencing back to the entire Request URI when it appears again in the To field a few octets later, and then do the same in subsequent requests/responses - not sure LZW would get you this. DEFLATE, if I remember correctly, does LZW & then Huffman encodes the result. In my personal opinion, binary content in SIP messages, including the Caller Photo & Multimedia Messages is a bad thing per se and Content Indirection should always be used. (As Jonathan mentioned, the existing MMS does not send the content with the notification of the message - you have to fetch it). Having said that, referencing out from the Presence Document to something which might be at a URL or might be in another MIME part of the Notification might provide a way forward - of course I'd still say that these other MIME parts should be Content-Indirected :-), but at least you have solved the encoding problem and brought the compression problems into the same space as Caller-photos etc. ...Mark > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: 05 February 2003 17:51 > To: Watson, Mark [MOP:EP10:EXCH]; simple@ietf.org > Subject: RE: [Simple] New I-Ds on partial notification > > > Is this really so? I would hope SIP compression doesn't break > because of large (binary) content in the message payload. It > would mean sending a jpeg mug shot in an INVITE will also > break it, along with MESSAGE with any multimedia in it. > > And I agree, base64 encoding may not be the best way. How > about including the content using cids and a MIME multipart? > Just a thought. > > Cheers, > Aki > > > -----Original Message----- > From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] > Sent: 05 February, 2003 19:21 > To: simple@ietf.org > Subject: RE: [Simple] New I-Ds on partial notification > > > One more reason why in-line content breaks SIP Compression: > Most compression schemes have a limit on how far they can > 'reach back' into the message stream to reference repeated > strings. This distance may be further limited by the UDVM > memory. Depending on the compression scheme, large in-line > content may cause all useful state to be lost, so that the > compression ratio drops right down. > > ...Mark > -----Original Message----- > From: Watson, Mark [MOP:EP10:EXCH] > Sent: 05 February 2003 15:48 > To: 'mikko.lonnfors@nokia.com'; simple@ietf.org > Subject: RE: [Simple] New I-Ds on partial notification > > > I am really skeptical about the suggestion that large binary > data content will be included in-line in the presence > document itself. How will this be done ? > Unless I mis-understand, the presence document is an XML > document encoding in UTF-8 - i.e. it's a text document. Can > you really include raw binary data in-line ?? What > content-transfer-encoding will you use ? How will a standard > XML parser react to this ? Does XML have a mechanisms for > indicating that arbitrary binary data follows and indicating > the length of that data ? > If the binary data is e.g. base64 encoded, then you've > immediately broken your efficiency requirement. Even if the > raw binary data can be included in-line, the chances are that > any SIP compression on the access link will end up expanding > this portion of the message. (That is unless the compressor > in use is specifically designed with the requirement to > handle arbitrary binary data efficiently. But since the > compressor is chosen by the edge proxy, how can you know this ?) > I would expect SIP compressors to be optimised to handle > text-based messages and, if only for this reason, I think we > should generally try and stick with text based signalling > within the SIP message (and yes, we do have to do something > about S/MIME encryption here!). As I mentioned at the > 3GPP/IETF workshop that we have to pay continuing attention > to the compressibility of SIP messages. > There have been many threads on the general undesirability of > using SIP to transport large content files around. Further, > on a 3GPP-specific note, this approach would make it much > more difficult to get any kind of reliable idea of the > bandwidth/QoS requirements for the signalling-specific radio > resource. Whilst you may wish to allow this resource to be > used for content as well, I do not think people should be > mandated to do this. > Finally, one of your requirements is to cope with devices of > various form-factors/capabilities and the ability to render > multi-media content is one capability which varies greatly > from device to device - I really do not want to send a video > clip even once to a device which can't render it. > I do not see what the big deal is with including a URI for > any such content in the Presence Document. This has so many > advantages: > a) The content is only sent when it changes (even with your > proposal, it is sent at least every time a watcher subscribes) > b) The content is only sent to devices which can render it > c) The content need only be sent when the device actually > needs to render it > Jonathan explained how security could easily be made no worse > than for in-line content. > On charging you solution is to require that this data is > charged in the same way as the rest of SIP signalling - but > this solution does not imply that the data is carried *in* > SIP signalling. If this is what you want to do, then just > allow HTTP requests to a local HTTP-proxy (designated for > this purpose) to use the signalling resource. > Until we've bottomed out this in-line content question, I > don't see how we can conclude on whether partial > notifications are valuable or not. > Regards, > Mark > -----Original Message----- > From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com] > Sent: 28 January 2003 07:35 > To: simple@ietf.org > Subject: [Simple] New I-Ds on partial notification > > > Hi, > Here are links to two new drafts which deal with partial > presence notifications. > Requirements are discussed here: > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-pres > info-deliv-reqs-00.txt > A Presence service implemented using SIMPLE has some constraints for > delivering presence information to devices with low data processing > capabilities, small display, and limited battery power. Other > limitations can be caused by the interface between the terminal and > the network, i.e. over radio links with high latency and low > bandwidth. This memo presents requirements for a solution that aids > in reducing the impacts of those constrains and increasing > efficiency. > And the actual solution is described here: > http://www.ietf.org/internet-drafts/draft-lonnofors-simple-par > tial-notify-00.txt > A Presence service implemented using SIMPLE has some constraints for > delivering presence information to devices with low data processing > capabilities, small display, and limited battery power. Other > limitations can be caused by the interface between the terminal and > the network, i.e. over radio links with high latency and low > bandwidth. This memo presents a solution that aids in reducing the > impact of those constrains and increasing efficiency, by introducing > a new MIME-type partial notifications and a Require header > extension partial-notification. > All comments are most welcome. > Regards > - Mikko > ------_=_NextPart_001_01C2CDEA.72EE1B66 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] New I-Ds on partial notification

Mikko,

I would expect SIGCOMP compressors to be highly = optimised for SIP. You can achieve extremely high compression gains if = you choose the right compressor. My point below was not just that = arbitrary data included inline would not compress well, but that the = presence of this data might reduce the effectiveness of the compression = on the rest of the SIP messages, because of the effect this arbitrary = data has on the (dynamic) dictionary.

A key feature of SIP messages is that they contain a = few long strings which are then repeated in their entirity a few lines = later or in later messages. Basically these are the URIs which appear = in To/From/Via/Route/Record-Route but there are also things like the = pre-conditions attributes in the SDP which are very verbose and may be = repeated for every media line.

A compression scheme which can efficiently reference = these strings appearing earlier in the message, or in a previous = message, will work well for SIP. If there's 10k of in-line content in a = message which blows out the dynamic dictionary, then you may lose this = ability to reference. (But then if there's 10k of content in the = message I'm not so sure why you care about reducing the SIP message = headers from 900 to 400 octets, or whatever.)

It would be wise to compress HTTP traffic as well - = in fact it would not be unwise to compress all traffic on the wireless = link (I think most analog modems use some form of compression on the = low-bandwidth links that they provide) using some generic compression = scheme.

Compression for HTTP (or generic) traffic wouldn't = need a specific dictionary. There aren't enough HTTP Headers, compared = to the size of the arbitrary HTTP bodies, for it to be worth bothering. = SIP is different, because we expect the majority of octets of most = messages to be SIP headers or SDP. If you put large in-line content in = SIP, you make it just like HTTP in this respect - you might as well use = generic compression at the link layer instead of SIGCOMP.

...Mark


-----Original Message-----
From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com= ]
Sent: 06 February 2003 14:02
To: Watson, Mark [MOP:EP10:EXCH]; = aki.niemi@nokia.com; simple@ietf.org
Subject: RE: [Simple] New I-Ds on partial = notification


Hi,
 
One issue seems to be that how does CI (using HTTP) = help in case of compression? What I mean is that you probably want to = compress all the protocol data to and from your UA. If compression = fails with SIP how is it better with HTTP? Or are you saying that there = should not be any compression for HTTP? And if you then want to = compress HTTP you probably need dictionaries for HTTP and also your = HTTP server and UA would need to support it.

 
- Mikko
-----Original Message-----
From: ext Mark Watson [mailto:mwatson@nortelnetworks= .com]
Sent: 05 February, 2003 20:20
To: Niemi Aki (NMP/Helsinki); simple@ietf.org
Subject: RE: [Simple] New I-Ds on partial = notification


Aki,
Well, it depends on the compression algorithm used. = Certainly the simple ones do little more that send a string of = <offset,length> pairs to reference strings which occured earlier = in the data stream - of course with some way of escaping to literal = data. So, certainly, large in-band binary content will reduce the = effectiveness of these schemes.

You could mitigate this by ensuring that the static = dictionary never goes out of view, or, for example, only storing the = first X octets of each message, where X is chosen to usually cover the = headers and SDP.

Other schemes build up a dictionary of codewords e.g. = in LZW then the codebook is built up by allocating a new codeword for = the previous phase plus the next character. Common phrases will end up = appearing in more codewords and in longer referenced strings. I think = this would not be so affected by raw binary data, since this wouldn't = disrupt the codebook already built.

However, I'm not so sure this is the best scheme for = SIP signalling, since it takes quite a while to build up the codebook. = You want, for example, to be referencing back to the entire Request URI = when it appears again in the To field a few octets later, and then do = the same in subsequent requests/responses - not sure LZW would get you = this.

DEFLATE, if I remember correctly, does LZW & then = Huffman encodes the result.
In my personal opinion, binary content in SIP = messages, including the Caller Photo & Multimedia Messages is a bad = thing per se and Content Indirection should always be used. (As = Jonathan mentioned, the existing MMS does not send the content with the = notification of the message - you have to fetch it).

Having said that, referencing out from the Presence = Document to something which might be at a URL or might be in another = MIME part of the Notification might provide a way forward - of course = I'd still say that these other MIME parts should be Content-Indirected = :-), but at least you have solved the encoding problem and brought the = compression problems into the same space as Caller-photos = etc.

...Mark
> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] =
> Sent: 05 February 2003 17:51
> To: Watson, Mark [MOP:EP10:EXCH]; = simple@ietf.org
> Subject: RE: [Simple] New I-Ds on partial = notification
>
>
> Is this really so? I would hope SIP compression = doesn't break
> because of large (binary) content in the = message payload. It
> would mean sending a jpeg mug shot in an INVITE = will also
> break it, along with MESSAGE with any = multimedia in it.
>
> And I agree, base64 encoding may not be the = best way. How
> about including the content using cids and a = MIME multipart?
> Just a thought.
>
> Cheers,
> Aki
>
>
> -----Original Message-----
> From: ext Mark Watson [mailto:mwatson@nortelnetworks= .com]
> Sent: 05 February, 2003 19:21
> To: simple@ietf.org
> Subject: RE: [Simple] New I-Ds on partial = notification
>
>
> One more reason why in-line content breaks SIP = Compression:
> Most compression schemes have a limit on how = far they can
> 'reach back' into the message stream to = reference repeated
> strings. This distance may be further limited = by the UDVM
> memory. Depending on the compression scheme, = large in-line
> content may cause all useful state to be lost, = so that the
> compression ratio drops right down.
>
> ...Mark
> -----Original Message-----
> From: Watson, Mark [MOP:EP10:EXCH]
> Sent: 05 February 2003 15:48
> To: 'mikko.lonnfors@nokia.com'; simple@ietf.org =
> Subject: RE: [Simple] New I-Ds on partial = notification
>
>
> I am really skeptical about the suggestion that = large binary
> data content will be included in-line in the = presence
> document itself. How will this be done ? =
> Unless I mis-understand, the presence document = is an XML
> document encoding in UTF-8 - i.e. it's a text = document. Can
> you really include raw binary data in-line ?? = What
> content-transfer-encoding will you use ? How = will a standard
> XML parser react to this ? Does XML have a = mechanisms for
> indicating that arbitrary binary data follows = and indicating
> the length of that data ?
> If the binary data is e.g. base64 encoded, then = you've
> immediately broken your efficiency requirement. = Even if the
> raw binary data can be included in-line, the = chances are that
> any SIP compression on the access link will end = up expanding
> this portion of the message. (That is unless = the compressor
> in use is specifically designed with the = requirement to
> handle arbitrary binary data efficiently. But = since the
> compressor is chosen by the edge proxy, how can = you know this ?)
> I would expect SIP compressors to be optimised = to handle
> text-based messages and, if only for this = reason, I think we
> should generally try and stick with text based = signalling
> within the SIP message (and yes, we do have to = do something
> about S/MIME encryption here!). As I mentioned = at the
> 3GPP/IETF workshop that we have to pay = continuing attention
> to the compressibility of SIP messages.
> There have been many threads on the general = undesirability of
> using SIP to transport large content files = around. Further,
> on a 3GPP-specific note, this approach would = make it much
> more difficult to get any kind of reliable idea = of the
> bandwidth/QoS requirements for the = signalling-specific radio
> resource. Whilst you may wish to allow this = resource to be
> used for content as well, I do not think people = should be
> mandated to do this.
> Finally, one of your requirements is to cope = with devices of
> various form-factors/capabilities and the = ability to render
> multi-media content is one capability which = varies greatly
> from device to device - I really do not want to = send a video
> clip even once to a device which can't render = it.
> I do not see what the big deal is with = including a URI for
> any such content in the Presence Document. This = has so many
> advantages:
> a) The content is only sent when it changes = (even with your
> proposal, it is sent at least every time a = watcher subscribes)
> b) The content is only sent to devices which = can render it
> c) The content need only be sent when the = device actually
> needs to render it
> Jonathan explained how security could easily be = made no worse
> than for in-line content.
> On charging you solution is to require that = this data is
> charged in the same way as the rest of SIP = signalling - but
> this solution does not imply that the data is = carried *in*
> SIP signalling. If this is what you want to do, = then just
> allow HTTP requests to a local HTTP-proxy = (designated for
> this purpose) to use the signalling resource. =
> Until we've bottomed out this in-line content = question, I
> don't see how we can conclude on whether = partial
> notifications are valuable or not.
> Regards,
> Mark
> -----Original Message-----
> From: mikko.lonnfors@nokia.com [mailto:mikko.lonnfors@nokia.com= ]
> Sent: 28 January 2003 07:35
> To: simple@ietf.org
> Subject: [Simple] New I-Ds on partial = notification
>
>
> Hi,
> Here are links to two new drafts which deal = with partial
> presence notifications.
> Requirements are discussed here:
> http://www.ietf.org/internet-drafts/draft-lonnfors-sim= ple-pres
> info-deliv-reqs-00.txt
> A Presence service implemented using SIMPLE has = some constraints for
> delivering presence information to devices with = low data processing
> capabilities, small display, and limited = battery power. Other
> limitations can be caused by the interface = between the terminal and
> the network, i.e. over radio links with high = latency and low
> bandwidth. This memo presents requirements for = a solution that aids
> in reducing the impacts of those constrains and = increasing
> efficiency.
> And the actual solution is described here: =
> http://www.ietf.org/internet-drafts/draft-lonnofors-si= mple-par
> tial-notify-00.txt
> A Presence service implemented using SIMPLE has = some constraints for
> delivering presence information to devices with = low data processing
> capabilities, small display, and limited = battery power. Other
> limitations can be caused by the interface = between the terminal and
> the network, i.e. over radio links with high = latency and low
> bandwidth. This memo presents a solution that = aids in reducing the
> impact of those constrains and increasing = efficiency, by introducing
> a new MIME-type partial notifications and a = Require header
> extension partial-notification.
> All comments are most welcome.
> Regards
> - Mikko
>

------_=_NextPart_001_01C2CDEA.72EE1B66-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 09:42:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19655 for ; Thu, 6 Feb 2003 09:42:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16En8T04608 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 09:49:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16En8p04605 for ; Thu, 6 Feb 2003 09:49:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19598 for ; Thu, 6 Feb 2003 09:42:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16En4p04577; Thu, 6 Feb 2003 09:49:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Emfp04525 for ; Thu, 6 Feb 2003 09:48:41 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19585 for ; Thu, 6 Feb 2003 09:41:41 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20987; Thu, 6 Feb 2003 09:45:16 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16522; Thu, 6 Feb 2003 09:45:16 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Feb 2003 09:45:15 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5DE6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , simple@ietf.org Subject: RE: [Simple] Invisible and RPIDS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Feb 2003 09:45:11 -0500 Can you explain why invisible is the desired state? Is it really only used because the current presence systems don't have a rich way to make watcher-dependent presence? Would the actual requirement be that for some watchers you are open, and for others you are closed? I do agree this is transformation state. I think there is no need to actually standardize invisible; your presence state is closed to a watcher. If your IM system still accepts messages, that's a local decision it makes. I'm a little confused by: > presence server. Thus, the "IM states" might be: > > open for messages > open for high priority only > invisible > text-only My confusion is that "invisible" is your state, "open for messages" is in conflict with "invisible". What I think you mean is that you are differentiating between state published by a presentity to the PS, from the state a watcher obtains from the PS, and you are trying to include in the presentity-to-PS exchange, instructions for how it should interpret invisible. I think that's a slippery slope we don't want to go down at the moment - how the principal creates rulesets for the PS. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, February 06, 2003 1:05 AM > To: simple@ietf.org > Subject: [Simple] Invisible and RPIDS > > > I wanted to discuss an interesting feature of existing IM > systems, so as > to explore how it fits in our evolving presence/RPIDS work. > > The feature is "invisible". On several systems, you can set > your status > to invisible. To all watchers, your status is offline, but they can > still send you IM, and you will receive them. One can imagine other > behaviors, where in invisible mode, I don't receive IM - they are > archived, and I retrieve them when I return to visible mode. > > The concept extends to voice too; one can imagine publishing > invisible > for a phone, which means watchers see it as CLOSED (using pidf > terminology), but calls to it will actually still succeed. > > I would argue that this is an example of a "transformational policy". > That is, there is some PIDF status extension defined to represent > invisible. However, there is also a presence policy that says this: > > IF the watcher is "IM App" > don't change anything > IF the watcher is anyone else > remove all status but basic > set basic to CLOSED > > Its a transformational policy, because its not just > restricting who sees > what, its changing one of the statuses (basic) from OPEN to CLOSED > depending on the watcher. > > Note that I have also modeled the IM app as a watcher. Thats > because the > IM app will use the presence status to determine how to handle an IM > sent to the user. Here, by IM app, I mean some kind of application > server that receives IMs targeted to a user, and applies forwarding, > retry, storage and blocking policies. > > As far as pidf is concerned, one might generalize this as a > "visibility" > status which indicates various shades of visibility. > "invisible" means > that I wish for nothing to be revealed to watchers. "partly visible" > might mean that only basic is revealed, and everything else > is stripped. > > Another way to view this is that a tuple can represent an > application, > such as an IM app, a chess game app, or something. There are specific > statuses defined for each app, meant for the consumption of an > application server in the network, but also visible to watchers, > possibly after the application of a transformational policy at the > presence server. Thus, the "IM states" might be: > > open for messages > open for high priority only > invisible > text-only > > These have a particular interpretation by an IM app server - > they would > be used to guide its blocking and archiving policy. > > Note that we have not yet, afaik, discussed the notion that a > tuple can > represent an application, as opposed to a device or media type. The > lines are blurry, no doubt.... > > -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@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 10:31:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22235 for ; Thu, 6 Feb 2003 10:31:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16FbdB08601 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 10:37:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Fbdp08598 for ; Thu, 6 Feb 2003 10:37:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22177 for ; Thu, 6 Feb 2003 10:30:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16FbZp08563; Thu, 6 Feb 2003 10:37:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16FaKp07784 for ; Thu, 6 Feb 2003 10:36:20 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22074 for ; Thu, 6 Feb 2003 10:29:19 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h16FWtYH017454; Thu, 6 Feb 2003 10:32:56 -0500 (EST) Message-ID: <3E428022.6030908@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: simple@ietf.org Subject: Re: [Simple] Invisible and RPIDS References: <3E41FAFB.8000707@dynamicsoft.com> <3E426CAF.4030209@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Feb 2003 10:32:50 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I believe this can be done already in RPIDS. I could label certain > states with keywords that are recognized by my policy script, which then > transforms them into the appropriate tuples before delivery to watchers. I am less worried about the transformations, as I am about the notion of certain presence states being designed specifically for interpretation by an application (IM in this case). > (Or, the transformation could depend on the presence data itself, e.g., > on time of day or other clues. For example, I could automatically > declare myself selectively invisible when my says 'meeting'.) Right. As I said, the transformation part is just part of the policy, letting certain watchers see certain things, and others see different things. The issue really is that I have one watcher in particular, the IM app, for which I want it to do something very specific when my presence state has a particular value. This would seem to require some kind of standardization of states. Brian writes: > I do agree this is transformation state. I think > there is no need to actually standardize invisible; > your presence state is closed to a watcher. If your > IM system still accepts messages, that's a local decision > it makes. I think thats the big question. Existing systems area using presence to allow the presentity to CONTROL the behavior of the application by specifically setting the state. Thus, for the behavior to be predictable by the client, you would need to somehow standardize the states and the behavior they are supposed to imply. -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 10:34:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22355 for ; Thu, 6 Feb 2003 10:34:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16Ff6w08849 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 10:41:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Ff6p08845 for ; Thu, 6 Feb 2003 10:41:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22328 for ; Thu, 6 Feb 2003 10:34:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Ff2p08816; Thu, 6 Feb 2003 10:41:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16FeTp08756 for ; Thu, 6 Feb 2003 10:40:29 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22300 for ; Thu, 6 Feb 2003 10:33:28 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h16Fbrvd001277; Thu, 6 Feb 2003 10:37:53 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAZ24350; Thu, 6 Feb 2003 10:41:59 -0500 (EST) Message-ID: <3E428117.20601@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seancolson@yahoo.com CC: "'Jonathan Rosenberg'" , krisztian.kiss@nokia.com, jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] PUBLISH: a dialog? References: <000301c2cda3$1708a100$6501a8c0@cranberry> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Feb 2003 10:36:55 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Sean that we ought to think of PUBLISH as a fixed-up REGISTER. But I agree with Brian that using Call-ID/CSeq as they are used in REGISTER is probably a mistake, and fails to learn from the mistakes of REGISTER. It would be nice if use of dialogs for PUBLISH was optional. If there will be substantial traffic, then it may be useful to set up a dialog. If there isn't substantial traffic, or if the endpoints don't want to bear the cost (as in the case Jonathan described) it might be better to forego a dialog. Using the dialog mechanism of 3261, there is the option of sending PUBLISH messages through a dialog established for some other purpose, such as a subscription. If we even want to *permit* that, then we can't use Call-ID/CSeq in some conflicting way. What we don't get with 3261 is a way to have an "optionally dialog establishing" method. If PUBLISH isn't dialog establishing, but we want to use it in a dialog and don't have one already, there is no perfectly suited mechanism to get one. One possibility might be to make a medialess invite. But there are many problems with that. It seems like an ugly solution. An obvious technique might be for the publisher to subscribe to its own presence - something that is likely to be common. Then it could send PUBLISH within the resulting dialog. Or, we could consider a mechanism for "optionally dialog creating" methods. Paul Sean Olson wrote: > Dialog state for PUBLISH will be a mistake. The more I think about it, > the clearer it > becomes to me that PUBLISH should be a fixed-up REGISTER. The hardest > problem is figuring > out when and how to tear down dialog state for PUBLISH particularly if > it is the compositor > that wants to tear down the dialog. I am recommending that we use > Call-ID/CSeq in PUBLISH in > an analogous way to the way it is used in REGISTER itself. > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of > Jonathan Rosenberg > Sent: Wednesday, February 05, 2003 8:25 PM > To: krisztian.kiss@nokia.com > Cc: pkyzivat@cisco.com; jon.peterson@neustar.biz; simple@ietf.org > Subject: Re: [Simple] PUBLISH: a dialog? > > > I am still on the fence on this issue. Some responses and thoughts > inline: > > krisztian.kiss@nokia.com wrote: > > Hi All, > > > > I am supporting the dialog initiating PUBLISH method, since that > > seems to be a step forward to meet some of the requirements posted to > > SIMPLE list recently: > > http://mailman.dynamicsoft.com/pipermail/simple/2002-December/002103.htm > l > > First, I believe the dialog concept would be preferable to provide > >>"feedback" to the PUA about the actual result of the publishing > > > transaction, whether the published XML was successfully composed to > > the presence document or not. > > I agree with that, but I dont see why you need a dialog. I had in mind > that the response to PUBLISH is a 200 OK if the published data was > accepted, and the response contains the "raw" presence data from other > publishers. This raw data could be used by a PUA to, for example, > overwrite the presence data from another PUA. > > > Secondly, in a multi-PUA scenario, a > > dialog would also be useful to provide feedback about other PUAs' > > activities, e.g. the publishing PUA could learn the presence > > information (including the tuple ids) published by other PUAs. > > I am not as sure there is a need to know when the published data > changes, as to be able to fetch it. Considering our one and only use > case (going home and then setting the presence from my PC at work to > unavailable, since i left it running), the home device doesn't need to > know about changes in published information. It just needs to query to > find out the set of published data. > > Does anyone have some use cases to motivate a notification feature on > the publication side? > > Jon Peterson wrote: > >>However, it isn't clear today if it is necessary to have a longer-term > > >>identifier in the headers of the PUBLISH method, considering that the >>presence information itself may contain its own identifiers (like the >>tuple ID in PIDF) that could be reused as needed (such as the case in >>which one device overwrites presence published by another). > > > I think that, if the only thing you need sequencing for is to determine > the most recent tuple or status, the identifiers in the tuples, along > with the timestamps, will suffice. You also need to know the source of > the publisher, but you don't need a dialog for that. > > I would argue that the need for some kind of sequencing beyond the > timestamps in the tuples arises if we support differential (not partial) > > publication. In that case, I think you do need some kind of sequencing > outside of the tuple id. But, if we don't do that, even partial > publication doesn't need sequencing outside of the pidf. > > The counter-arguments is that its probably a good thing to provide > sequencing of published presence data independent of the document type. > We may have other formats beyond pidf for specific vertical sources of > presence data. > > The real benefit of the dialog state is the efficiency of avoiding going > > through proxies for updates and refreshes. You WILL need to refresh, > because published presence is soft-state. Managing the soft-state may > actually be hard if there is no sequencing provided by the SIP > mechanism. The Call-ID/CSeq are required in REGISTER in order to do > this. > > Here is an argument against dialogs. One can imagine that a PUA might > actually be this big server that is, for example, collecting geolocation > > for a large number of users and publishing it into the presence system. > It would be nice to not require additional state on that box in order to > > do the publication. If it could periodically sample the geoloc, > construct a presence doc, timestamp it, and send it in a PUBLISH, > without needing to remember the call-id or cseq, that would be a good > thing, I think. > > > One final comment. If we do add dialog support, we need to add the > machinery to clean them up. There needs to be a way for both sides to > indicate termination of the dialog. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 10:53:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23400 for ; Thu, 6 Feb 2003 10:53:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16G08P10160 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 11:00:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16G08p10157 for ; Thu, 6 Feb 2003 11:00:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23369 for ; Thu, 6 Feb 2003 10:53:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16G05p10148; Thu, 6 Feb 2003 11:00:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Fxnp10084 for ; Thu, 6 Feb 2003 10:59:49 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23358 for ; Thu, 6 Feb 2003 10:52:47 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h16FuNSO010022 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Feb 2003 10:56:24 -0500 (EST) Message-ID: <3E4285B2.6050104@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@ietf.org Subject: Re: [Simple] Invisible and RPIDS References: <3E41FAFB.8000707@dynamicsoft.com> <3E426CAF.4030209@cs.columbia.edu> <3E428022.6030908@dynamicsoft.com> In-Reply-To: <3E428022.6030908@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Feb 2003 10:56:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> I believe this can be done already in RPIDS. I could label certain >> states with keywords that are recognized by my policy script, which >> then transforms them into the appropriate tuples before delivery to >> watchers. > > > I am less worried about the transformations, as I am about the notion of > certain presence states being designed specifically for interpretation > by an application (IM in this case). Why create an application-specific solution when a generic solution works? > >> (Or, the transformation could depend on the presence data itself, >> e.g., on time of day or other clues. For example, I could >> automatically declare myself selectively invisible when my >> says 'meeting'.) > > > Right. As I said, the transformation part is just part of the policy, > letting certain watchers see certain things, and others see different > things. The issue really is that I have one watcher in particular, the > IM app, for which I want it to do something very specific when my > presence state has a particular value. This would seem to require some > kind of standardization of states. Why? Why can't my IM app be part of the same policy transformation machinery that generates handling instructions for, say, SIP INVITEs? > > Brian writes: > >> I do agree this is transformation state. I think >> there is no need to actually standardize invisible; >> your presence state is closed to a watcher. If your >> IM system still accepts messages, that's a local decision >> it makes. > > > I think thats the big question. Existing systems area using presence to > allow the presentity to CONTROL the behavior of the application by > specifically setting the state. Thus, for the behavior to be predictable > by the client, you would need to somehow standardize the states and the > behavior they are supposed to imply. Why can't this be done by each implementation, given that the details may differ significantly? We already have the ability to indicate, via callerprefs, "closed to IM" (maybe - that may require a discussion on the expressiveness of our current media types; I had raised this issue earlier) or "closed to MESSAGE". > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 10:55:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23453 for ; Thu, 6 Feb 2003 10:55:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16G24n10270 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 11:02:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16G24p10267 for ; Thu, 6 Feb 2003 11:02:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23442 for ; Thu, 6 Feb 2003 10:55:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16G21p10254; Thu, 6 Feb 2003 11:02:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16G1Ep10217 for ; Thu, 6 Feb 2003 11:01:14 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23417 for ; Thu, 6 Feb 2003 10:54:13 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26067; Thu, 6 Feb 2003 10:57:50 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02846; Thu, 6 Feb 2003 10:57:49 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Feb 2003 10:57:49 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5DEA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" Cc: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RPIDS: Capabilities in tuples and Caller Prefs Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Feb 2003 10:57:47 -0500 The RPIDS work has had a couple of threads running amongst the authors and contributors. Now that the latest draft is out, we've been asked to put any further discussions on the list, which is most appropriate. This message is a continuation of one such thread. Jonathan and I have been having a discussion of whether the presence information includes a set of PS-manufactured contact uris that correspond to the devices enumerated in the presence document. Jonathan proposes that there be an arbitrary categorization of information in the document, and each tuple have a contact address that is specific to that category. The presence system would then work with the outbound proxy for the IM/Voice/Video devices to direct this contact uri to the appropriate device. I would prefer that there be a small number (one is good) of "well known" addresses that is my contact address, and a caller use Caller Prefs to cause the call (IM/whatever) to get to the right device. So, with that, I pick up the thread. > > is from me, > is from Jonathan > > What the heck do we need separate contact addresses manufactured > > by the presence agent for? If you send a call to my > > sip uri with some SDP, my proxy can get it to the "right" device. > > How does it know which is the right device? On a separate > thread on this > topic, we concluded, I believe, that presence represented a sort of > contract. When the PA advertised a tuple with certain sets of > capabilities (is a cell phone, supports video), it was the > responsibility of the PA to construct a URI such that the > caller, doing > nothing other than invoking a call to that URI, would get its call > routed to one or more UA that are accuratedly described by those > capabilities. Generally, this means that the PA will need to > know which > tuple the caller tried to reach, in order to do this. I think this is all caller prefs. I don't understand why we would ever define something in SIMPLE that was not representable in caller prefs with respect to how a caller expressed which device (or really, which capabilities) a future call was to be routed to. I don't see any way this limits presence, or puts undue burden on caller prefs. > > Let me elaborate on your example. Lets say you've got a PC > and a phone. > You advertise one tuple for video (calls to which should get > routed to > the PC) and one for audio (calls to which get routed to both > the PC and > the phone). A watcher clicks on the "video" tuple. However, > by default, > their device does not ask for video streams - it uses an > audio stream in > the initial call setup, and adds video once the call > completes. If the > URI you use in both contacts is the same, how is the proxy to > know that > this call was for the PC alone? There is no video in the SDP. The caller prefs requests video even if the SDP doesn't have it. > > The problem is less contrived when the presence represents > devices, such > as PC and cell phone. Presumably, when the watcher chooses the cell > phone, a call should go to the cell phone and NOT the PC. How > would the > proxy know to do that? The only reasonably way was to have > the PA come > up with a URI which had that effect, using whatever technique > it likes. Again I think caller prefs gives you the capability you need. > > > If you want to influence what that is, caller prefs can do that > > (but it's up to me to actually decide). > > We also talked about this. You dont want the watcher to have > to come up > with the appropriate set of caller prefs to route the call to the > desired device. You can use caller prefs only in the sense > that the PA > can include a contact URI in the presence doc like this: > > sip:brian@marconi.com;Require-Contact=*;mobility="mobile" If the caller wants to force a call to my cell, this looks like a reasonable uri to me, whether the caller created it because it understands the syntax of caller prefs or, if you prefer, because that is the contact uri in the presence document. It's a heck of a lot better than the prior uri you suggested. > All the caller needs to do is make a call to this URI. It > doesn't need > to know how to build the caller prefs headers. I really think that a rich presence system will find it easy to build a uri with caller prefs. I further think that it's not appropriate to invent a new way for a watcher/caller to express preferences for how his call is handled. Caller Prefs is how we do that. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 13:57:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00293 for ; Thu, 6 Feb 2003 13:57:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16J4Dt23243 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 14:04:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16J4Cp23240 for ; Thu, 6 Feb 2003 14:04:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00268 for ; Thu, 6 Feb 2003 13:57:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16J47p23227; Thu, 6 Feb 2003 14:04:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16J3Yp23189 for ; Thu, 6 Feb 2003 14:03:34 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00241 for ; Thu, 6 Feb 2003 13:56:27 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h16J2jm18347 for ; Thu, 6 Feb 2003 21:02:45 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Feb 2003 21:00:04 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 21:00:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] PUBLISH: a dialog? Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194514C@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: a dialog? Thread-Index: AcLN9dXXEusUbvJOSOa8tGILsn9WtgAGxbBA To: , Cc: , , , X-OriginalArrivalTime: 06 Feb 2003 19:00:04.0771 (UTC) FILETIME=[F575F730:01C2CE11] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16J3Yp23190 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Feb 2003 21:00:04 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Paul, One way to get this optionality is to use the SUBSCRIBE/NOTIFY methodology. I.e., have PUBLISH always create a dialog, but also allow the infinitely short dialog created by a PUBLISH using Expires: 0. It would sort of be a "push" of presence, similar to "fetch" in the subscription side. Cheers, Aki > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 06 February, 2003 17:37 > To: seancolson@yahoo.com > Cc: 'Jonathan Rosenberg'; Kiss Krisztian (NRC/Tampere); > jon.peterson@neustar.biz; simple@ietf.org > Subject: Re: [Simple] PUBLISH: a dialog? > > > I agree with Sean that we ought to think of PUBLISH as a fixed-up > REGISTER. But I agree with Brian that using Call-ID/CSeq as they are > used in REGISTER is probably a mistake, and fails to learn from the > mistakes of REGISTER. > > It would be nice if use of dialogs for PUBLISH was optional. If there > will be substantial traffic, then it may be useful to set up > a dialog. > If there isn't substantial traffic, or if the endpoints don't want to > bear the cost (as in the case Jonathan described) it might be > better to > forego a dialog. > > Using the dialog mechanism of 3261, there is the option of sending > PUBLISH messages through a dialog established for some other purpose, > such as a subscription. If we even want to *permit* that, > then we can't > use Call-ID/CSeq in some conflicting way. > > What we don't get with 3261 is a way to have an "optionally dialog > establishing" method. If PUBLISH isn't dialog establishing, > but we want > to use it in a dialog and don't have one already, there is no > perfectly > suited mechanism to get one. One possibility might be to make a > medialess invite. But there are many problems with that. It > seems like > an ugly solution. > > An obvious technique might be for the publisher to subscribe > to its own > presence - something that is likely to be common. Then it could send > PUBLISH within the resulting dialog. > > Or, we could consider a mechanism for "optionally dialog > creating" methods. > > Paul > > Sean Olson wrote: > > Dialog state for PUBLISH will be a mistake. The more I > think about it, > > the clearer it > > becomes to me that PUBLISH should be a fixed-up REGISTER. > The hardest > > problem is figuring > > out when and how to tear down dialog state for PUBLISH > particularly if > > it is the compositor > > that wants to tear down the dialog. I am recommending that we use > > Call-ID/CSeq in PUBLISH in > > an analogous way to the way it is used in REGISTER itself. > > > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] > On Behalf Of > > Jonathan Rosenberg > > Sent: Wednesday, February 05, 2003 8:25 PM > > To: krisztian.kiss@nokia.com > > Cc: pkyzivat@cisco.com; jon.peterson@neustar.biz; simple@ietf.org > > Subject: Re: [Simple] PUBLISH: a dialog? > > > > > > I am still on the fence on this issue. Some responses and thoughts > > inline: > > > > krisztian.kiss@nokia.com wrote: > > > Hi All, > > > > > > I am supporting the dialog initiating PUBLISH method, > since that > > > seems to be a step forward to meet some of the requirements > posted to > > > SIMPLE list recently: > > > > http://mailman.dynamicsoft.com/pipermail/simple/2002-December/ > 002103.htm > > l > > > First, I believe the dialog concept would be preferable > to provide > > > >>"feedback" to the PUA about the actual result of the publishing > > > > > transaction, whether the published XML was successfully > composed to > > > the presence document or not. > > > > I agree with that, but I dont see why you need a dialog. I > had in mind > > that the response to PUBLISH is a 200 OK if the published data was > > accepted, and the response contains the "raw" presence data > from other > > publishers. This raw data could be used by a PUA to, for example, > > overwrite the presence data from another PUA. > > > > > Secondly, in a multi-PUA scenario, a > > > dialog would also be useful to provide feedback about > other PUAs' > > > activities, e.g. the publishing PUA could learn the presence > > > information (including the tuple ids) published by other PUAs. > > > > I am not as sure there is a need to know when the published data > > changes, as to be able to fetch it. Considering our one and > only use > > case (going home and then setting the presence from my PC > at work to > > unavailable, since i left it running), the home device > doesn't need to > > know about changes in published information. It just needs > to query to > > find out the set of published data. > > > > Does anyone have some use cases to motivate a notification > feature on > > the publication side? > > > > Jon Peterson wrote: > > > >>However, it isn't clear today if it is necessary to have a > longer-term > > > > > >>identifier in the headers of the PUBLISH method, > considering that the > >>presence information itself may contain its own identifiers > (like the > >>tuple ID in PIDF) that could be reused as needed (such as > the case in > >>which one device overwrites presence published by another). > > > > > > I think that, if the only thing you need sequencing for is > to determine > > the most recent tuple or status, the identifiers in the > tuples, along > > with the timestamps, will suffice. You also need to know > the source of > > the publisher, but you don't need a dialog for that. > > > > I would argue that the need for some kind of sequencing beyond the > > timestamps in the tuples arises if we support differential > (not partial) > > > > publication. In that case, I think you do need some kind of > sequencing > > outside of the tuple id. But, if we don't do that, even partial > > publication doesn't need sequencing outside of the pidf. > > > > The counter-arguments is that its probably a good thing to provide > > sequencing of published presence data independent of the > document type. > > We may have other formats beyond pidf for specific vertical > sources of > > presence data. > > > > The real benefit of the dialog state is the efficiency of > avoiding going > > > > through proxies for updates and refreshes. You WILL need to > refresh, > > because published presence is soft-state. Managing the > soft-state may > > actually be hard if there is no sequencing provided by the SIP > > mechanism. The Call-ID/CSeq are required in REGISTER in order to do > > this. > > > > Here is an argument against dialogs. One can imagine that a > PUA might > > actually be this big server that is, for example, > collecting geolocation > > > > for a large number of users and publishing it into the > presence system. > > It would be nice to not require additional state on that > box in order to > > > > do the publication. If it could periodically sample the geoloc, > > construct a presence doc, timestamp it, and send it in a PUBLISH, > > without needing to remember the call-id or cseq, that would > be a good > > thing, I think. > > > > > > One final comment. If we do add dialog support, we need to add the > > machinery to clean them up. There needs to be a way for > both sides to > > indicate termination of the dialog. > > > > -Jonathan R. > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 6 14:36:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01486 for ; Thu, 6 Feb 2003 14:36:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16JhBS25817 for simple-archive@odin.ietf.org; Thu, 6 Feb 2003 14:43:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16JhBp25814 for ; Thu, 6 Feb 2003 14:43:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01477 for ; Thu, 6 Feb 2003 14:36:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Jh6p25806; Thu, 6 Feb 2003 14:43:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Jggp25785 for ; Thu, 6 Feb 2003 14:42:42 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01463 for ; Thu, 6 Feb 2003 14:35:34 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h16JbWxQ020772; Thu, 6 Feb 2003 14:37:33 -0500 (EST) Received: from dynamicsoft.com (NJ-AKRISTENSEN.dynamicsoft.com [63.113.46.102]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 11J5VV9G; Thu, 6 Feb 2003 14:39:13 -0500 Message-ID: <3E42B9E1.6030304@dynamicsoft.com> From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: pkyzivat@cisco.com, seancolson@yahoo.com, jdrosen@dynamicsoft.com, krisztian.kiss@nokia.com, jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] PUBLISH: a dialog? References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194514C@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Feb 2003 14:39:13 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Another option might be to follow the MESSAGE "methodology"; allow PUBLISH to be sent in a dialog-less mode or within an INVITE initiated dialog. Then obviously BYE could be used by either party to terminate the dialog. Anders aki.niemi@nokia.com wrote: > Hi Paul, > > One way to get this optionality is to use the SUBSCRIBE/NOTIFY methodology. I.e., have PUBLISH always create a dialog, but also allow the infinitely short dialog created by a PUBLISH using Expires: 0. > > It would sort of be a "push" of presence, similar to "fetch" in the subscription side. > > Cheers, > Aki > > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: 06 February, 2003 17:37 >>To: seancolson@yahoo.com >>Cc: 'Jonathan Rosenberg'; Kiss Krisztian (NRC/Tampere); >>jon.peterson@neustar.biz; simple@ietf.org >>Subject: Re: [Simple] PUBLISH: a dialog? >> >> >>I agree with Sean that we ought to think of PUBLISH as a fixed-up >>REGISTER. But I agree with Brian that using Call-ID/CSeq as they are >>used in REGISTER is probably a mistake, and fails to learn from the >>mistakes of REGISTER. >> >>It would be nice if use of dialogs for PUBLISH was optional. If there >>will be substantial traffic, then it may be useful to set up >>a dialog. >>If there isn't substantial traffic, or if the endpoints don't want to >>bear the cost (as in the case Jonathan described) it might be >>better to >>forego a dialog. >> >>Using the dialog mechanism of 3261, there is the option of sending >>PUBLISH messages through a dialog established for some other purpose, >>such as a subscription. If we even want to *permit* that, >>then we can't >>use Call-ID/CSeq in some conflicting way. >> >>What we don't get with 3261 is a way to have an "optionally dialog >>establishing" method. If PUBLISH isn't dialog establishing, >>but we want >>to use it in a dialog and don't have one already, there is no >>perfectly >>suited mechanism to get one. One possibility might be to make a >>medialess invite. But there are many problems with that. It >>seems like >>an ugly solution. >> >>An obvious technique might be for the publisher to subscribe >>to its own >>presence - something that is likely to be common. Then it could send >>PUBLISH within the resulting dialog. >> >>Or, we could consider a mechanism for "optionally dialog >>creating" methods. >> >> Paul >> >>Sean Olson wrote: >> >>>Dialog state for PUBLISH will be a mistake. The more I >> >>think about it, >> >>>the clearer it >>>becomes to me that PUBLISH should be a fixed-up REGISTER. >> >>The hardest >> >>>problem is figuring >>>out when and how to tear down dialog state for PUBLISH >> >>particularly if >> >>>it is the compositor >>>that wants to tear down the dialog. I am recommending that we use >>>Call-ID/CSeq in PUBLISH in >>>an analogous way to the way it is used in REGISTER itself. >>> >>>-----Original Message----- >>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >> >>On Behalf Of >> >>>Jonathan Rosenberg >>>Sent: Wednesday, February 05, 2003 8:25 PM >>>To: krisztian.kiss@nokia.com >>>Cc: pkyzivat@cisco.com; jon.peterson@neustar.biz; simple@ietf.org >>>Subject: Re: [Simple] PUBLISH: a dialog? >>> >>> >>>I am still on the fence on this issue. Some responses and thoughts >>>inline: >>> >>>krisztian.kiss@nokia.com wrote: >>> > Hi All, >>> > >>> > I am supporting the dialog initiating PUBLISH method, >> >>since that > >> >>>seems to be a step forward to meet some of the requirements >> >>posted to > >> >>>SIMPLE list recently: > >>> >>http://mailman.dynamicsoft.com/pipermail/simple/2002-December/ >>002103.htm >> >>>l >>> > First, I believe the dialog concept would be preferable >> >>to provide >> >>>>"feedback" to the PUA about the actual result of the publishing > >>> >>>transaction, whether the published XML was successfully >> >>composed to > >> >>>the presence document or not. >>> >>>I agree with that, but I dont see why you need a dialog. I >> >>had in mind >> >>>that the response to PUBLISH is a 200 OK if the published data was >>>accepted, and the response contains the "raw" presence data >> >>from other >> >>>publishers. This raw data could be used by a PUA to, for example, >>>overwrite the presence data from another PUA. >>> >>> > Secondly, in a multi-PUA scenario, a >>> > dialog would also be useful to provide feedback about >> >>other PUAs' > >> >>>activities, e.g. the publishing PUA could learn the presence > >>>information (including the tuple ids) published by other PUAs. >>> >>>I am not as sure there is a need to know when the published data >>>changes, as to be able to fetch it. Considering our one and >> >>only use >> >>>case (going home and then setting the presence from my PC >> >>at work to >> >>>unavailable, since i left it running), the home device >> >>doesn't need to >> >>>know about changes in published information. It just needs >> >>to query to >> >>>find out the set of published data. >>> >>>Does anyone have some use cases to motivate a notification >> >>feature on >> >>>the publication side? >>> >>>Jon Peterson wrote: >>> >>> >>>>However, it isn't clear today if it is necessary to have a >>> >>longer-term >> >>> >>>>identifier in the headers of the PUBLISH method, >>> >>considering that the >> >>>>presence information itself may contain its own identifiers >>> >>(like the >> >>>>tuple ID in PIDF) that could be reused as needed (such as >>> >>the case in >> >>>>which one device overwrites presence published by another). >>> >>> >>>I think that, if the only thing you need sequencing for is >> >>to determine >> >>>the most recent tuple or status, the identifiers in the >> >>tuples, along >> >>>with the timestamps, will suffice. You also need to know >> >>the source of >> >>>the publisher, but you don't need a dialog for that. >>> >>>I would argue that the need for some kind of sequencing beyond the >>>timestamps in the tuples arises if we support differential >> >>(not partial) >> >>>publication. In that case, I think you do need some kind of >> >>sequencing >> >>>outside of the tuple id. But, if we don't do that, even partial >>>publication doesn't need sequencing outside of the pidf. >>> >>>The counter-arguments is that its probably a good thing to provide >>>sequencing of published presence data independent of the >> >>document type. >> >>>We may have other formats beyond pidf for specific vertical >> >>sources of >> >>>presence data. >>> >>>The real benefit of the dialog state is the efficiency of >> >>avoiding going >> >>>through proxies for updates and refreshes. You WILL need to >> >>refresh, >> >>>because published presence is soft-state. Managing the >> >>soft-state may >> >>>actually be hard if there is no sequencing provided by the SIP >>>mechanism. The Call-ID/CSeq are required in REGISTER in order to do >>>this. >>> >>>Here is an argument against dialogs. One can imagine that a >> >>PUA might >> >>>actually be this big server that is, for example, >> >>collecting geolocation >> >>>for a large number of users and publishing it into the >> >>presence system. >> >>>It would be nice to not require additional state on that >> >>box in order to >> >>>do the publication. If it could periodically sample the geoloc, >>>construct a presence doc, timestamp it, and send it in a PUBLISH, >>>without needing to remember the call-id or cseq, that would >> >>be a good >> >>>thing, I think. >>> >>> >>>One final comment. If we do add dialog support, we need to add the >>>machinery to clean them up. There needs to be a way for >> >>both sides to >> >>>indicate termination of the dialog. >>> >>>-Jonathan R. >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 7 00:29:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17792 for ; Fri, 7 Feb 2003 00:29:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h175acX28169 for simple-archive@odin.ietf.org; Fri, 7 Feb 2003 00:36:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h175acp28166 for ; Fri, 7 Feb 2003 00:36:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17778 for ; Fri, 7 Feb 2003 00:29:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h175aXp28158; Fri, 7 Feb 2003 00:36:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h175ZRp28128 for ; Fri, 7 Feb 2003 00:35:27 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17753 for ; Fri, 7 Feb 2003 00:28:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.78]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h175VHYH019913; Fri, 7 Feb 2003 00:31:18 -0500 (EST) Message-ID: <3E4344A1.4050206@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: simple@ietf.org Subject: Re: [Simple] Invisible and RPIDS References: <3E41FAFB.8000707@dynamicsoft.com> <3E426CAF.4030209@cs.columbia.edu> <3E428022.6030908@dynamicsoft.com> <3E4285B2.6050104@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Feb 2003 00:31:13 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >>> I believe this can be done already in RPIDS. I could label certain >>> states with keywords that are recognized by my policy script, which >>> then transforms them into the appropriate tuples before delivery to >>> watchers. >> >> >> >> I am less worried about the transformations, as I am about the notion >> of certain presence states being designed specifically for >> interpretation by an application (IM in this case). > > > Why create an application-specific solution when a generic solution works? What is the generic solution? > >> >>> (Or, the transformation could depend on the presence data itself, >>> e.g., on time of day or other clues. For example, I could >>> automatically declare myself selectively invisible when my >>> says 'meeting'.) >> >> >> >> Right. As I said, the transformation part is just part of the policy, >> letting certain watchers see certain things, and others see different >> things. The issue really is that I have one watcher in particular, the >> IM app, for which I want it to do something very specific when my >> presence state has a particular value. This would seem to require some >> kind of standardization of states. > > > Why? Why can't my IM app be part of the same policy transformation > machinery that generates handling instructions for, say, SIP INVITEs? I don't follow your analogy, but let me provide a specific case. Lets say I want to set my presence status to something which tells an IM app to block IMs to me except high priority ones. There are two approaches to that: 1. set my basic presence status to OPEN, and set my activity to "busy" or something like that. Then, set a transformation policy which sets this to CLOSED for everyone but the IM app. The IM app is then configured to know that busy/OPEN means block all but high priority IM. Perhaps this is what you mean by the generic solution. 2. set my basic status to OPEN, set my activity to "busy", and also set my IM-app status to "block-all-but-high-priority". The same transformation policy sets this to CLOSED for everyone but the IM app. However, the IM app looks at the IM-app status which gives it an explicit directive. If we want these to be interoperable across clients/IM applications, they would need to be standardized. The main issue with case 1 is that my client, on my providers IM app, may do the right thing, but if my client connects to a different provider with a different IM app, the IM app behavior might be different. Now, that said, there are cases where an application does something on my behalf as a side-effect of a presence change. In those cases, I dont want to mandate those application behaviors. However, the question is whether people think there is a need to provide EXPLICIT directives to applications through presence. -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 7 00:48:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18191 for ; Fri, 7 Feb 2003 00:48:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h175tDf29571 for simple-archive@odin.ietf.org; Fri, 7 Feb 2003 00:55:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h175tCp29568 for ; Fri, 7 Feb 2003 00:55:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18161 for ; Fri, 7 Feb 2003 00:47:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h175t8p29534; Fri, 7 Feb 2003 00:55:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h175sop29492 for ; Fri, 7 Feb 2003 00:54:50 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18144 for ; Fri, 7 Feb 2003 00:47:30 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.78]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h175pCYH019923; Fri, 7 Feb 2003 00:51:12 -0500 (EST) Message-ID: <3E43494C.7010205@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: pkyzivat@cisco.com, seancolson@yahoo.com, krisztian.kiss@nokia.com, jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] PUBLISH: a dialog? References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194514C@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Feb 2003 00:51:08 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Unfortunately, the element which decides whether this is a dialog (the PUA) may not be the one who really wants it to be (the proxy, to avoid getting swamped with messages). Anyway, I don't want to complicate things by trying to come up with a method which can either create a dialog or not. I think thats a recipe for trouble. Sending PUBLISH over a dialog created by somethign else is better, but will introduce complexity into the compositor, which know will have to handle PUA which set up dialogs and those which don't. -Jonathan R. aki.niemi@nokia.com wrote: > Hi Paul, > > One way to get this optionality is to use the SUBSCRIBE/NOTIFY methodology. I.e., have PUBLISH always create a dialog, but also allow the infinitely short dialog created by a PUBLISH using Expires: 0. > > It would sort of be a "push" of presence, similar to "fetch" in the subscription side. > > Cheers, > Aki > > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: 06 February, 2003 17:37 >>To: seancolson@yahoo.com >>Cc: 'Jonathan Rosenberg'; Kiss Krisztian (NRC/Tampere); >>jon.peterson@neustar.biz; simple@ietf.org >>Subject: Re: [Simple] PUBLISH: a dialog? >> >> >>I agree with Sean that we ought to think of PUBLISH as a fixed-up >>REGISTER. But I agree with Brian that using Call-ID/CSeq as they are >>used in REGISTER is probably a mistake, and fails to learn from the >>mistakes of REGISTER. >> >>It would be nice if use of dialogs for PUBLISH was optional. If there >>will be substantial traffic, then it may be useful to set up >>a dialog. >>If there isn't substantial traffic, or if the endpoints don't want to >>bear the cost (as in the case Jonathan described) it might be >>better to >>forego a dialog. >> >>Using the dialog mechanism of 3261, there is the option of sending >>PUBLISH messages through a dialog established for some other purpose, >>such as a subscription. If we even want to *permit* that, >>then we can't >>use Call-ID/CSeq in some conflicting way. >> >>What we don't get with 3261 is a way to have an "optionally dialog >>establishing" method. If PUBLISH isn't dialog establishing, >>but we want >>to use it in a dialog and don't have one already, there is no >>perfectly >>suited mechanism to get one. One possibility might be to make a >>medialess invite. But there are many problems with that. It >>seems like >>an ugly solution. >> >>An obvious technique might be for the publisher to subscribe >>to its own >>presence - something that is likely to be common. Then it could send >>PUBLISH within the resulting dialog. >> >>Or, we could consider a mechanism for "optionally dialog >>creating" methods. >> >> Paul >> >>Sean Olson wrote: >> >>>Dialog state for PUBLISH will be a mistake. The more I >> >>think about it, >> >>>the clearer it >>>becomes to me that PUBLISH should be a fixed-up REGISTER. >> >>The hardest >> >>>problem is figuring >>>out when and how to tear down dialog state for PUBLISH >> >>particularly if >> >>>it is the compositor >>>that wants to tear down the dialog. I am recommending that we use >>>Call-ID/CSeq in PUBLISH in >>>an analogous way to the way it is used in REGISTER itself. >>> >>>-----Original Message----- >>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] >> >>On Behalf Of >> >>>Jonathan Rosenberg >>>Sent: Wednesday, February 05, 2003 8:25 PM >>>To: krisztian.kiss@nokia.com >>>Cc: pkyzivat@cisco.com; jon.peterson@neustar.biz; simple@ietf.org >>>Subject: Re: [Simple] PUBLISH: a dialog? >>> >>> >>>I am still on the fence on this issue. Some responses and thoughts >>>inline: >>> >>>krisztian.kiss@nokia.com wrote: >>> > Hi All, >>> > >>> > I am supporting the dialog initiating PUBLISH method, >> >>since that > >> >>>seems to be a step forward to meet some of the requirements >> >>posted to > >> >>>SIMPLE list recently: > >>> >>http://mailman.dynamicsoft.com/pipermail/simple/2002-December/ >>002103.htm >> >>>l >>> > First, I believe the dialog concept would be preferable >> >>to provide >> >>>>"feedback" to the PUA about the actual result of the publishing > >>> >>>transaction, whether the published XML was successfully >> >>composed to > >> >>>the presence document or not. >>> >>>I agree with that, but I dont see why you need a dialog. I >> >>had in mind >> >>>that the response to PUBLISH is a 200 OK if the published data was >>>accepted, and the response contains the "raw" presence data >> >>from other >> >>>publishers. This raw data could be used by a PUA to, for example, >>>overwrite the presence data from another PUA. >>> >>> > Secondly, in a multi-PUA scenario, a >>> > dialog would also be useful to provide feedback about >> >>other PUAs' > >> >>>activities, e.g. the publishing PUA could learn the presence > >>>information (including the tuple ids) published by other PUAs. >>> >>>I am not as sure there is a need to know when the published data >>>changes, as to be able to fetch it. Considering our one and >> >>only use >> >>>case (going home and then setting the presence from my PC >> >>at work to >> >>>unavailable, since i left it running), the home device >> >>doesn't need to >> >>>know about changes in published information. It just needs >> >>to query to >> >>>find out the set of published data. >>> >>>Does anyone have some use cases to motivate a notification >> >>feature on >> >>>the publication side? >>> >>>Jon Peterson wrote: >>> >>> >>>>However, it isn't clear today if it is necessary to have a >>> >>longer-term >> >>> >>>>identifier in the headers of the PUBLISH method, >>> >>considering that the >> >>>>presence information itself may contain its own identifiers >>> >>(like the >> >>>>tuple ID in PIDF) that could be reused as needed (such as >>> >>the case in >> >>>>which one device overwrites presence published by another). >>> >>> >>>I think that, if the only thing you need sequencing for is >> >>to determine >> >>>the most recent tuple or status, the identifiers in the >> >>tuples, along >> >>>with the timestamps, will suffice. You also need to know >> >>the source of >> >>>the publisher, but you don't need a dialog for that. >>> >>>I would argue that the need for some kind of sequencing beyond the >>>timestamps in the tuples arises if we support differential >> >>(not partial) >> >>>publication. In that case, I think you do need some kind of >> >>sequencing >> >>>outside of the tuple id. But, if we don't do that, even partial >>>publication doesn't need sequencing outside of the pidf. >>> >>>The counter-arguments is that its probably a good thing to provide >>>sequencing of published presence data independent of the >> >>document type. >> >>>We may have other formats beyond pidf for specific vertical >> >>sources of >> >>>presence data. >>> >>>The real benefit of the dialog state is the efficiency of >> >>avoiding going >> >>>through proxies for updates and refreshes. You WILL need to >> >>refresh, >> >>>because published presence is soft-state. Managing the >> >>soft-state may >> >>>actually be hard if there is no sequencing provided by the SIP >>>mechanism. The Call-ID/CSeq are required in REGISTER in order to do >>>this. >>> >>>Here is an argument against dialogs. One can imagine that a >> >>PUA might >> >>>actually be this big server that is, for example, >> >>collecting geolocation >> >>>for a large number of users and publishing it into the >> >>presence system. >> >>>It would be nice to not require additional state on that >> >>box in order to >> >>>do the publication. If it could periodically sample the geoloc, >>>construct a presence doc, timestamp it, and send it in a PUBLISH, >>>without needing to remember the call-id or cseq, that would >> >>be a good >> >>>thing, I think. >>> >>> >>>One final comment. If we do add dialog support, we need to add the >>>machinery to clean them up. There needs to be a way for >> >>both sides to >> >>>indicate termination of the dialog. >>> >>>-Jonathan R. >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 7 09:30:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12391 for ; Fri, 7 Feb 2003 09:30:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17EbGs07533 for simple-archive@odin.ietf.org; Fri, 7 Feb 2003 09:37:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17EbGp07530 for ; Fri, 7 Feb 2003 09:37:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12377 for ; Fri, 7 Feb 2003 09:29:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17EbAp07457; Fri, 7 Feb 2003 09:37:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Eamp07102 for ; Fri, 7 Feb 2003 09:36:48 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12369 for ; Fri, 7 Feb 2003 09:29:18 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h17EWtSh024586 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Feb 2003 09:32:56 -0500 (EST) Message-ID: <3E43C39C.10409@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@ietf.org Subject: Re: [Simple] Invisible and RPIDS References: <3E41FAFB.8000707@dynamicsoft.com> <3E426CAF.4030209@cs.columbia.edu> <3E428022.6030908@dynamicsoft.com> <3E4285B2.6050104@cs.columbia.edu> <3E4344A1.4050206@dynamicsoft.com> In-Reply-To: <3E4344A1.4050206@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Feb 2003 09:33:00 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I don't follow your analogy, but let me provide a specific case. Lets > say I want to set my presence status to something which tells an IM app > to block IMs to me except high priority ones. There are two approaches > to that: > > 1. set my basic presence status to OPEN, and set my activity to "busy" > or something like that. Then, set a transformation policy which sets > this to CLOSED for everyone but the IM app. The IM app is then > configured to know that busy/OPEN means block all but high priority IM. > Perhaps this is what you mean by the generic solution. > > 2. set my basic status to OPEN, set my activity to "busy", and also set > my IM-app status to "block-all-but-high-priority". The same > transformation policy sets this to CLOSED for everyone but the IM app. > However, the IM app looks at the IM-app status which gives it an > explicit directive. If we want these to be interoperable across > clients/IM applications, they would need to be standardized. Different solution: create a tuple that has the following properties: basic status: open priority: urgent media: IM category: busy basic status: closed priority: - media: !IM category: busy Then, my proxy uses this to create a policy that says "unless the IM is marked urgent, block; block all other SIP requests" This seems pretty predictable; clearly, any of this relies on my IM service being aware of my presence. > > Now, that said, there are cases where an application does something on > my behalf as a side-effect of a presence change. In those cases, I dont > want to mandate those application behaviors. However, the question is > whether people think there is a need to provide EXPLICIT directives to > applications through presence. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 7 10:21:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13267 for ; Fri, 7 Feb 2003 10:21:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17FSAd10020 for simple-archive@odin.ietf.org; Fri, 7 Feb 2003 10:28:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17FSAp10017 for ; Fri, 7 Feb 2003 10:28:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13262 for ; Fri, 7 Feb 2003 10:20:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17FS6p10009; Fri, 7 Feb 2003 10:28:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17FRop09988 for ; Fri, 7 Feb 2003 10:27:50 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13257 for ; Fri, 7 Feb 2003 10:20:19 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07322; Fri, 7 Feb 2003 10:23:58 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29504; Fri, 7 Feb 2003 10:23:59 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Feb 2003 10:23:58 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5DFA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: simple@ietf.org Subject: RE: [Simple] Invisible and RPIDS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Feb 2003 10:23:57 -0500 I really think heads us in the wrong direction. I believe that what your presence state is, and how that influences your call behavior could be arbitrarily complex, and that it's not something the user makes up on the fly - it's a script of some kind (or some GUI that creates the same effect however mechanized). It's not appropriate to send how you want your calls handled from presentity to PS. You send your actual state, and your script/UI/whatever ruleset determines how that should affect a call, as well as how your state is represented to a given watcher. We might need more expressiveness in what your state is, but we don't need any expressiveness in how calls should be handled as a result of that state. If your state is "busy", and you when you are "busy" you want all but high priority IMs to be refused, that's a fine ruleset. If we need to have lots of nuance on "busy", or we need to have a way to select one ruleset from a collection of them, fine, but let's not try to make the presentity-to-ps interface the point at which you describe how you want your incoming proxy to handle calls. That's pretty close to Jonathan's #1. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, February 07, 2003 9:33 AM > To: Jonathan Rosenberg > Cc: simple@ietf.org > Subject: Re: [Simple] Invisible and RPIDS > > > > I don't follow your analogy, but let me provide a specific > case. Lets > > say I want to set my presence status to something which > tells an IM app > > to block IMs to me except high priority ones. There are two > approaches > > to that: > > > > 1. set my basic presence status to OPEN, and set my > activity to "busy" > > or something like that. Then, set a transformation policy > which sets > > this to CLOSED for everyone but the IM app. The IM app is then > > configured to know that busy/OPEN means block all but high > priority IM. > > Perhaps this is what you mean by the generic solution. > > > > 2. set my basic status to OPEN, set my activity to "busy", > and also set > > my IM-app status to "block-all-but-high-priority". The same > > transformation policy sets this to CLOSED for everyone but > the IM app. > > However, the IM app looks at the IM-app status which gives it an > > explicit directive. If we want these to be interoperable across > > clients/IM applications, they would need to be standardized. > > Different solution: create a tuple that has the following properties: > > basic status: open > priority: urgent > media: IM > category: busy > > > basic status: closed > priority: - > media: !IM > category: busy > > > Then, my proxy uses this to create a policy that says > > "unless the IM is marked urgent, block; block all other SIP requests" > > This seems pretty predictable; clearly, any of this relies on my IM > service being aware of my presence. > > > > > Now, that said, there are cases where an application does > something on > > my behalf as a side-effect of a presence change. In those > cases, I dont > > want to mandate those application behaviors. However, the > question is > > whether people think there is a need to provide EXPLICIT > directives to > > applications through presence. > > > > -Jonathan R. > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 7 10:34:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13547 for ; Fri, 7 Feb 2003 10:34:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17FfLt11160 for simple-archive@odin.ietf.org; Fri, 7 Feb 2003 10:41:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17FfLp11157 for ; Fri, 7 Feb 2003 10:41:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13523 for ; Fri, 7 Feb 2003 10:33:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17FfFp11149; Fri, 7 Feb 2003 10:41:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Fe1p11098 for ; Fri, 7 Feb 2003 10:40:01 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13513 for ; Fri, 7 Feb 2003 10:32:30 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h17FZno21860; Fri, 7 Feb 2003 09:35:49 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LNXCC2Q>; Fri, 7 Feb 2003 09:35:50 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E07C70245@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "Rosen, Brian" , "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: simple@ietf.org Subject: RE: [Simple] Invisible and RPIDS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CEBE.9799EAB0" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Feb 2003 09:35:50 -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_01C2CEBE.9799EAB0 Content-Type: text/plain; charset="ISO-8859-1" I'd agree with Brian. Otherwise, we're going to be uploading scripts with our presence state and the interface will just grow and grow and grow. Brian -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Friday, February 07, 2003 9:24 AM To: 'Henning Schulzrinne'; Jonathan Rosenberg Cc: simple@ietf.org Subject: RE: [Simple] Invisible and RPIDS I really think heads us in the wrong direction. I believe that what your presence state is, and how that influences your call behavior could be arbitrarily complex, and that it's not something the user makes up on the fly - it's a script of some kind (or some GUI that creates the same effect however mechanized). It's not appropriate to send how you want your calls handled from presentity to PS. You send your actual state, and your script/UI/whatever ruleset determines how that should affect a call, as well as how your state is represented to a given watcher. We might need more expressiveness in what your state is, but we don't need any expressiveness in how calls should be handled as a result of that state. If your state is "busy", and you when you are "busy" you want all but high priority IMs to be refused, that's a fine ruleset. If we need to have lots of nuance on "busy", or we need to have a way to select one ruleset from a collection of them, fine, but let's not try to make the presentity-to-ps interface the point at which you describe how you want your incoming proxy to handle calls. That's pretty close to Jonathan's #1. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, February 07, 2003 9:33 AM > To: Jonathan Rosenberg > Cc: simple@ietf.org > Subject: Re: [Simple] Invisible and RPIDS > > > > I don't follow your analogy, but let me provide a specific > case. Lets > > say I want to set my presence status to something which > tells an IM app > > to block IMs to me except high priority ones. There are two > approaches > > to that: > > > > 1. set my basic presence status to OPEN, and set my > activity to "busy" > > or something like that. Then, set a transformation policy > which sets > > this to CLOSED for everyone but the IM app. The IM app is then > > configured to know that busy/OPEN means block all but high > priority IM. > > Perhaps this is what you mean by the generic solution. > > > > 2. set my basic status to OPEN, set my activity to "busy", > and also set > > my IM-app status to "block-all-but-high-priority". The same > > transformation policy sets this to CLOSED for everyone but > the IM app. > > However, the IM app looks at the IM-app status which gives it an > > explicit directive. If we want these to be interoperable across > > clients/IM applications, they would need to be standardized. > > Different solution: create a tuple that has the following properties: > > basic status: open > priority: urgent > media: IM > category: busy > > > basic status: closed > priority: - > media: !IM > category: busy > > > Then, my proxy uses this to create a policy that says > > "unless the IM is marked urgent, block; block all other SIP requests" > > This seems pretty predictable; clearly, any of this relies on my IM > service being aware of my presence. > > > > > Now, that said, there are cases where an application does > something on > > my behalf as a side-effect of a presence change. In those > cases, I dont > > want to mandate those application behaviors. However, the > question is > > whether people think there is a need to provide EXPLICIT > directives to > > applications through presence. > > > > -Jonathan R. > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01C2CEBE.9799EAB0 Content-Type: text/html; charset="ISO-8859-1" RE: [Simple] Invisible and RPIDS

I'd agree with Brian. Otherwise, we're going to be uploading
scripts with our presence state and the interface will just
grow and grow and grow.

Brian

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, February 07, 2003 9:24 AM
To: 'Henning Schulzrinne'; Jonathan Rosenberg
Cc: simple@ietf.org
Subject: RE: [Simple] Invisible and RPIDS


I really think heads us in the wrong direction.
I believe that what your presence state is, and how that
influences your call behavior could be arbitrarily complex,
and that it's not something the user makes up on the fly
- it's a script of some kind (or some GUI that creates the
same effect however mechanized).

It's not appropriate to send how you want your calls handled
from presentity to PS.  You send your actual state, and your
script/UI/whatever ruleset determines how that should affect
a call, as well as how your state is represented to a given
watcher.  We might need more expressiveness in what your state is,
but we don't need any expressiveness in how calls should
be handled as a result of that state.

If your state is "busy", and you when you are "busy" you
want all but high priority IMs to be refused, that's a
fine ruleset.  If we need to have lots of nuance on "busy",
or we need to have a way to select one ruleset from a collection
of them, fine, but let's not try to make the presentity-to-ps
interface the point at which you describe how you want your
incoming proxy to handle calls.

That's pretty close to Jonathan's #1. 

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Friday, February 07, 2003 9:33 AM
> To: Jonathan Rosenberg
> Cc: simple@ietf.org
> Subject: Re: [Simple] Invisible and RPIDS
>
>
> > I don't follow your analogy, but let me provide a specific
> case. Lets
> > say I want to set my presence status to something which
> tells an IM app
> > to block IMs to me except high priority ones. There are two
> approaches
> > to that:
> >
> >  1. set my basic presence status to OPEN, and set my
> activity to "busy"
> > or something like that. Then, set a transformation policy
> which sets
> > this to CLOSED for everyone but the IM app. The IM app is then
> > configured to know that busy/OPEN means block all but high
> priority IM.
> > Perhaps this is what you mean by the generic solution.
> >
> > 2. set my basic status to OPEN, set my activity to "busy",
> and also set
> > my IM-app status to "block-all-but-high-priority". The same
> > transformation policy sets this to CLOSED for everyone but
> the IM app.
> > However, the IM app looks at the IM-app status which gives it an
> > explicit directive. If we want these to be interoperable across
> > clients/IM applications, they would need to be standardized.
>
> Different solution: create a tuple that has the following properties:
> <tuple>
> basic status: open
> priority: urgent
> media: IM
> category: busy
> </tuple>
> <tuple>
> basic status: closed
> priority: -
> media: !IM
> category: busy
> </tuple>
>
> Then, my proxy uses this to create a policy that says
>
> "unless the IM is marked urgent, block; block all other SIP requests"
>
> This seems pretty predictable; clearly, any of this relies on my IM
> service being aware of my presence.
>
> >
> > Now, that said, there are cases where an application does
> something on
> > my behalf as a side-effect of a presence change. In those
> cases, I dont
> > want to mandate those application behaviors. However, the
> question is
> > whether people think there is a need to provide EXPLICIT
> directives to
> > applications through presence.
> >
> > -Jonathan R.
> >
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

------_=_NextPart_001_01C2CEBE.9799EAB0-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 7 10:36:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13617 for ; Fri, 7 Feb 2003 10:36:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17Fh5S11242 for simple-archive@odin.ietf.org; Fri, 7 Feb 2003 10:43:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Fh5p11239 for ; Fri, 7 Feb 2003 10:43:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13612 for ; Fri, 7 Feb 2003 10:35:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Fh1p11231; Fri, 7 Feb 2003 10:43:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Fgjp11213 for ; Fri, 7 Feb 2003 10:42:45 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13609 for ; Fri, 7 Feb 2003 10:35:14 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h17Fbk208646 for ; Fri, 7 Feb 2003 17:37:46 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Feb 2003 17:38:52 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Feb 2003 17:38:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7252@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RPIDS: Capabilities in tuples and Caller Prefs Thread-Index: AcLN+MAroSC79M6YTBGfupoohWA2YgAxeCtg To: , Cc: X-OriginalArrivalTime: 07 Feb 2003 15:38:52.0256 (UTC) FILETIME=[04181E00:01C2CEBF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h17Fgjp11214 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Feb 2003 17:38:51 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I have to agree with Brian. I thought we agreed that call routing and presence info are two separate, but complimentary things. Proving call-routing-info in the presence document is not such a good idea. Regards, Hisham > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, February 06, 2003 5:58 PM > To: 'Jonathan Rosenberg' > Cc: 'simple@ietf.org' > Subject: [Simple] RPIDS: Capabilities in tuples and Caller Prefs > > > The RPIDS work has had a couple of threads running amongst the authors > and contributors. Now that the latest draft is out, we've been > asked to put any further discussions on the list, which is most > appropriate. This message is a continuation of one such thread. > > Jonathan and I have been having a discussion of whether the > presence information includes a set of PS-manufactured contact > uris that correspond to the devices enumerated in the presence > document. Jonathan proposes that there be an arbitrary categorization > of information in the document, and each tuple have a contact > address that is specific to that category. The presence system > would then work with the outbound proxy for the IM/Voice/Video > devices to direct this contact uri to the appropriate device. > > I would prefer that there be a small number (one is good) of > "well known" addresses that is my contact address, and a caller > use Caller Prefs to cause the call (IM/whatever) to get to the > right device. > > So, with that, I pick up the thread. > > is from me, > is > from Jonathan > > > What the heck do we need separate contact addresses manufactured > > > by the presence agent for? If you send a call to my > > > sip uri with some SDP, my proxy can get it to the "right" device. > > > > How does it know which is the right device? On a separate > > thread on this > > topic, we concluded, I believe, that presence represented a sort of > > contract. When the PA advertised a tuple with certain sets of > > capabilities (is a cell phone, supports video), it was the > > responsibility of the PA to construct a URI such that the > > caller, doing > > nothing other than invoking a call to that URI, would get its call > > routed to one or more UA that are accuratedly described by those > > capabilities. Generally, this means that the PA will need to > > know which > > tuple the caller tried to reach, in order to do this. > I think this is all caller prefs. I don't understand why we would > ever define something in SIMPLE that was not representable in > caller prefs with respect to how a caller expressed which device > (or really, which capabilities) a future call was to be routed to. > I don't see any way this limits presence, or puts undue burden > on caller prefs. > > > > > Let me elaborate on your example. Lets say you've got a PC > > and a phone. > > You advertise one tuple for video (calls to which should get > > routed to > > the PC) and one for audio (calls to which get routed to both > > the PC and > > the phone). A watcher clicks on the "video" tuple. However, > > by default, > > their device does not ask for video streams - it uses an > > audio stream in > > the initial call setup, and adds video once the call > > completes. If the > > URI you use in both contacts is the same, how is the proxy to > > know that > > this call was for the PC alone? There is no video in the SDP. > The caller prefs requests video even if the SDP doesn't have it. > > > > > The problem is less contrived when the presence represents > > devices, such > > as PC and cell phone. Presumably, when the watcher chooses the cell > > phone, a call should go to the cell phone and NOT the PC. How > > would the > > proxy know to do that? The only reasonably way was to have > > the PA come > > up with a URI which had that effect, using whatever technique > > it likes. > Again I think caller prefs gives you the capability you need. > > > > > > If you want to influence what that is, caller prefs can do that > > > (but it's up to me to actually decide). > > > > We also talked about this. You dont want the watcher to have > > to come up > > with the appropriate set of caller prefs to route the call to the > > desired device. You can use caller prefs only in the sense > > that the PA > > can include a contact URI in the presence doc like this: > > > > sip:brian@marconi.com;Require-Contact=*;mobility="mobile" > If the caller wants to force a call to my cell, this looks like > a reasonable uri to me, whether the caller created it because > it understands the syntax of caller prefs or, if you prefer, > because that is the contact uri in the presence document. > It's a heck of a lot better than the prior uri you suggested. > > > All the caller needs to do is make a call to this URI. It > > doesn't need > > to know how to build the caller prefs headers. > I really think that a rich presence system will find > it easy to build a uri with caller prefs. > > I further think that it's not appropriate to invent a new way for a > watcher/caller to express preferences for how his call is > handled. Caller Prefs is how we do that. > > Brian > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 7 11:45:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15137 for ; Fri, 7 Feb 2003 11:45:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17GqEj15021 for simple-archive@odin.ietf.org; Fri, 7 Feb 2003 11:52:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17GqEp15018 for ; Fri, 7 Feb 2003 11:52:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15126 for ; Fri, 7 Feb 2003 11:44:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Gq7p15005; Fri, 7 Feb 2003 11:52:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Gpxp14986 for ; Fri, 7 Feb 2003 11:51:59 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15118 for ; Fri, 7 Feb 2003 11:44:27 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.78]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h17Gm9YH020148; Fri, 7 Feb 2003 11:48:09 -0500 (EST) Message-ID: <3E43E344.9000303@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: Brian.Rosen@marconi.com, simple@ietf.org Subject: Re: [Simple] RPIDS: Capabilities in tuples and Caller Prefs References: <2038BCC78B1AD641891A0D1AE133DBB7FE7252@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Feb 2003 11:48:04 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This will require every presence client to support caller prefs. It also means that the client has to correctly guess the right series of caller preferences to route the request to the desired contact. It also means that every proxy in the presentity domain has to support caller preferences. It also means that the only information one can put in presence is information that can also be reflected into caller preferences. So, if, for example, I have a new presence status like activity, and I have two PCs, both equal, but I am at one, and not the other, so that the ONLY difference is activity, this will mean we need to add a caller preferences "activity" feature parameter, and a client will need to keep it up to date. Because of this, we will not be able to extend presence statuses without also extending caller preferences. Having been working on tuning the caller preferences algorithm for DOZENS of hours over the last weeks, I can say with some confidence that I do not think caller prefs will ever satisfy the needs of disambiguating two devices with the richness of presence we have been talkign about. Now, caller prefs may work in some cases, but its the PRESENTITY's domain which is in the position to determine whether or not it will work, not the WATCHERS. So, really, I think we have a fundamental disconnect here. TO me, the presence document contains a list of tuples, each of which specifies a point of contact for the presentity. The semantic of the contact URI is that, if I send an INVITE to it, I get connected to the thing described by the tuple. Do we agree on this point, or not? Assuming we agree, in order to do this, the thing constructing the contacts has to do so in such a way that a call to that contact gets routed to the thing represented by the tuple. This is a natural consequence if you buy the above definition. This is not an argument about abstract design principles; if you accept that the role of teh contact is to connect me to the thing which is represented by that tuple, you have NO CHOICE but to have the presentity provide a different contact for each tuple. -Jonathan R. hisham.khartabil@nokia.com wrote: > I have to agree with Brian. I thought we agreed that call routing and > presence info are two separate, but complimentary things. Proving > call-routing-info in the presence document is not such a good idea. > > Regards, Hisham > > >> -----Original Message----- From: ext Rosen, Brian >> [mailto:Brian.Rosen@marconi.com] Sent: Thursday, February 06, 2003 >> 5:58 PM To: 'Jonathan Rosenberg' Cc: 'simple@ietf.org' Subject: >> [Simple] RPIDS: Capabilities in tuples and Caller Prefs >> >> >> The RPIDS work has had a couple of threads running amongst the >> authors and contributors. Now that the latest draft is out, we've >> been asked to put any further discussions on the list, which is >> most appropriate. This message is a continuation of one such >> thread. >> >> Jonathan and I have been having a discussion of whether the >> presence information includes a set of PS-manufactured contact uris >> that correspond to the devices enumerated in the presence document. >> Jonathan proposes that there be an arbitrary categorization of >> information in the document, and each tuple have a contact address >> that is specific to that category. The presence system would then >> work with the outbound proxy for the IM/Voice/Video devices to >> direct this contact uri to the appropriate device. >> >> I would prefer that there be a small number (one is good) of "well >> known" addresses that is my contact address, and a caller use >> Caller Prefs to cause the call (IM/whatever) to get to the right >> device. >> >> So, with that, I pick up the thread. > > is from me, > is from >> Jonathan >> >>>> What the heck do we need separate contact addresses >>>> manufactured by the presence agent for? If you send a call to >>>> my sip uri with some SDP, my proxy can get it to the "right" >>>> device. >>> >>> How does it know which is the right device? On a separate thread >>> on this topic, we concluded, I believe, that presence represented >>> a sort of contract. When the PA advertised a tuple with certain >>> sets of capabilities (is a cell phone, supports video), it was >>> the responsibility of the PA to construct a URI such that the >>> caller, doing nothing other than invoking a call to that URI, >>> would get its call routed to one or more UA that are accuratedly >>> described by those capabilities. Generally, this means that the >>> PA will need to know which tuple the caller tried to reach, in >>> order to do this. >> >> I think this is all caller prefs. I don't understand why we would >> ever define something in SIMPLE that was not representable in >> caller prefs with respect to how a caller expressed which device >> (or really, which capabilities) a future call was to be routed to. >> I don't see any way this limits presence, or puts undue burden on >> caller prefs. >> >> >>> Let me elaborate on your example. Lets say you've got a PC and a >>> phone. You advertise one tuple for video (calls to which should >>> get routed to the PC) and one for audio (calls to which get >>> routed to both the PC and the phone). A watcher clicks on the >>> "video" tuple. However, by default, their device does not ask for >>> video streams - it uses an audio stream in the initial call >>> setup, and adds video once the call completes. If the URI you use >>> in both contacts is the same, how is the proxy to know that this >>> call was for the PC alone? There is no video in the SDP. >> >> The caller prefs requests video even if the SDP doesn't have it. >> >> >>> The problem is less contrived when the presence represents >>> devices, such as PC and cell phone. Presumably, when the watcher >>> chooses the cell phone, a call should go to the cell phone and >>> NOT the PC. How would the proxy know to do that? The only >>> reasonably way was to have the PA come up with a URI which had >>> that effect, using whatever technique it likes. >> >> Again I think caller prefs gives you the capability you need. >> >> >>>> If you want to influence what that is, caller prefs can do that >>>> (but it's up to me to actually decide). >>> >>> We also talked about this. You dont want the watcher to have to >>> come up with the appropriate set of caller prefs to route the >>> call to the desired device. You can use caller prefs only in the >>> sense that the PA can include a contact URI in the presence doc >>> like this: >>> >>> sip:brian@marconi.com;Require-Contact=*;mobility="mobile" >> >> If the caller wants to force a call to my cell, this looks like a >> reasonable uri to me, whether the caller created it because it >> understands the syntax of caller prefs or, if you prefer, because >> that is the contact uri in the presence document. It's a heck of a >> lot better than the prior uri you suggested. >> >> >>> All the caller needs to do is make a call to this URI. It doesn't >>> need to know how to build the caller prefs headers. >> >> I really think that a rich presence system will find it easy to >> build a uri with caller prefs. >> >> I further think that it's not appropriate to invent a new way for a >> watcher/caller to express preferences for how his call is handled. >> Caller Prefs is how we do that. >> >> Brian _______________________________________________ Simple >> mailing list Simple@ietf.org >> https://www1.ietf.org/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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 7 13:52:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17976 for ; Fri, 7 Feb 2003 13:52:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17Ix7f22310 for simple-archive@odin.ietf.org; Fri, 7 Feb 2003 13:59:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Ix7p22307 for ; Fri, 7 Feb 2003 13:59:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17948 for ; Fri, 7 Feb 2003 13:51:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Ix3p22298; Fri, 7 Feb 2003 13:59:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Iwap22247 for ; Fri, 7 Feb 2003 13:58:36 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17932 for ; Fri, 7 Feb 2003 13:51:01 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18206; Fri, 7 Feb 2003 13:54:39 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09026; Fri, 7 Feb 2003 13:54:40 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Feb 2003 13:54:39 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5DFE@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" Cc: hisham.khartabil@nokia.com, simple@ietf.org Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Feb 2003 13:54:39 -0500 > This will require every presence client to support caller prefs. We'll, let's be carefull, a presence client per se doesn't make calls to devices. It's the calling UA that would need to support caller prefs if it wishes to direct the call to a specific device. The UA and the presence client are likely to be one and the same, but let's keep the roles separate please. Now, if I do get a complex presence document, and, for some reason I have yet to really understand, I want to insist that the call go to a specific device maintained by the principal, then, yes, the caller UA has to support caller prefs. You can contrast that with inventing a new language to describe various characteristics of a device, and having the UA have to interpret that, as well as caller prefs. > > It also means that the client has to correctly guess the > right series of > caller preferences to route the request to the desired contact. I think any mechanism we come up with to differentiate one device from another can be implemented in caller prefs, rather than somewhere else. > > It also means that every proxy in the presentity domain has > to support > caller preferences. No, I think it means that the incoming sip proxy for calls (IM, games,...) that forwards based on your presence has to understand caller prefs. It's pass-along to everyone else in the sip domain. It doesn't occur in the presence domain as above. > > It also means that the only information one can put in presence is > information that can also be reflected into caller > preferences. So, if, > for example, I have a new presence status like activity, and > I have two > PCs, both equal, but I am at one, and not the other, so that the ONLY > difference is activity, this will mean we need to add a caller > preferences "activity" feature parameter, and a client will > need to keep > it up to date. Agree. Of course, I would say that we would need caller prefs only so that the caller can manage to convince my incoming proxy to send the call to the PC I am not at, since I would expect that normally, a call to me would be forwarded to the PC I was at. > > Because of this, we will not be able to extend presence > statuses without > also extending caller preferences. Having been working on tuning the > caller preferences algorithm for DOZENS of hours over the > last weeks, I > can say with some confidence that I do not think caller prefs > will ever > satisfy the needs of disambiguating two devices with the richness of > presence we have been talkign about. Now, caller prefs may > work in some > cases, but its the PRESENTITY's domain which is in the position to > determine whether or not it will work, not the WATCHERS. It seems to me if you can define the difference in the presence document, you use the same "language" in caller prefs. Define it once, use it both places. Most of the richness in the presence stuff is information about the principal, not the devices he has. The differences between the devices are simple. Of course, I think it is the CALLED party that actually decides what device it takes calls on, but that's another thread. > > So, really, I think we have a fundamental disconnect here. > > TO me, the presence document contains a list of tuples, each of which > specifies a point of contact for the presentity. The semantic of the > contact URI is that, if I send an INVITE to it, I get > connected to the > thing described by the tuple. > > Do we agree on this point, or not? Agree > > Assuming we agree, in order to do this, the thing constructing the > contacts has to do so in such a way that a call to that contact gets > routed to the thing represented by the tuple. This is a natural > consequence if you buy the above definition. No, because you made an assumption I don't make: I think you assume a tuple describes the presence information of one device. While I can't stop you from constructing your presence client from doing that, I hope you won't stop me from constructing my presence client so that I describe one principal with one tuple. That tuple has one contact address, but it describes the presence of the principal, covering all of the devices he may have. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 7 14:18:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18770 for ; Fri, 7 Feb 2003 14:18:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17JP8D24133 for simple-archive@odin.ietf.org; Fri, 7 Feb 2003 14:25:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17JP8p24130 for ; Fri, 7 Feb 2003 14:25:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18735 for ; Fri, 7 Feb 2003 14:17:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17JP4p24121; Fri, 7 Feb 2003 14:25:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17JOfp24092 for ; Fri, 7 Feb 2003 14:24:41 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18719 for ; Fri, 7 Feb 2003 14:17:06 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h17JKhMO013438 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Feb 2003 14:20:44 -0500 (EST) Message-ID: <3E44070F.8090300@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Jonathan Rosenberg'" , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] RPIDS: Capabilities in tuples and Caller Prefs References: <313680C9A886D511A06000204840E1CF030B5DFE@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5DFE@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Feb 2003 14:20:47 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm not sure there is a one right way to do things, given that this largely depends on the coupling between presence information, policy and the end system capabilities (as well as issues of trust). There are at least three models: (1) single (sip/tel) contact URI, with different qualifications, using caller preferences As long as each device is uniquely identified by the caller preferences, this works even if presence information offers additional information. Thus, I don't think all caller preferences information needs to be reflected in presence (or only caller preferences), just enough that the outcome is the same. In many practical cases this is likely to work. The only major limitation I can think of is location-based routing where I want to reach the person at a specific location. Unless the person is really an aggregate, callee-based routing should deal with that. (2) custom-made contact URIs for each tuple. Avoids the uniqueness issues. Requires fairly tight coordination between presence and request routing since I need to make up new devices when I create a new communications presence. I may also need to worry about whether these identities convey authorization (whoever can see this URI can call me). (3) business card that enumerates all my capabilities, with long-term 'universal' addresses Requires least coordination, but has privacy and control problems. Is there another option? > Now, if I do get a complex presence document, and, for some reason > I have yet to really understand, I want to insist that the call go to > a specific device maintained by the principal, then, yes, the > caller UA has to support caller prefs. > > You can contrast that with inventing a new language to describe > various characteristics of a device, and having the UA have to > interpret that, as well as caller prefs. Or create the unique IDs which are essentially hashed versions of caller-prefs. >>It also means that the only information one can put in presence is >>information that can also be reflected into caller >>preferences. So, if, >>for example, I have a new presence status like activity, and >>I have two >>PCs, both equal, but I am at one, and not the other, so that the ONLY >>difference is activity, this will mean we need to add a caller >>preferences "activity" feature parameter, and a client will >>need to keep >>it up to date. Unless you can rely on the normal call routing to not route the call to the inactive one (or you don't care that your inactive one rings and nobody picks up). Why would you care that the call gets forked to an inactive device? >>Assuming we agree, in order to do this, the thing constructing the >>contacts has to do so in such a way that a call to that contact gets >>routed to the thing represented by the tuple. This is a natural >>consequence if you buy the above definition. > > No, because you made an assumption I don't make: > I think you assume a tuple describes the presence information of one > device. > > While I can't stop you from constructing your presence client from > doing that, I hope you won't stop me from constructing my presence > client so that I describe one principal with one tuple. > That tuple has one contact address, but it describes the presence > of the principal, covering all of the devices he may have. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Feb 8 13:12:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26812 for ; Sat, 8 Feb 2003 13:12:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h18IKPk02223 for simple-archive@odin.ietf.org; Sat, 8 Feb 2003 13:20:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18IKPp02220 for ; Sat, 8 Feb 2003 13:20:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26807 for ; Sat, 8 Feb 2003 13:12:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18IKIp02208; Sat, 8 Feb 2003 13:20:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18IJGp02141 for ; Sat, 8 Feb 2003 13:19:16 -0500 Received: from web41507.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26762 for ; Sat, 8 Feb 2003 13:11:13 -0500 (EST) Message-ID: <20030208181453.87715.qmail@web41507.mail.yahoo.com> Received: from [207.46.228.31] by web41507.mail.yahoo.com via HTTP; Sat, 08 Feb 2003 10:14:53 PST From: Sean Olson Subject: Re: [Simple] PUBLISH: a dialog? To: Paul Kyzivat Cc: "'Jonathan Rosenberg'" , krisztian.kiss@nokia.com, jon.peterson@neustar.biz, simple@ietf.org In-Reply-To: <3E428117.20601@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 8 Feb 2003 10:14:53 -0800 (PST) If you really want dialog state for a PUBLISH, I would suggest using INVITE to establish a "signaling" session. Not a new concept ... one we've needed for a very long time now. I believe it is as elegant as the INVITE mechanism itself. Personally, I don't see the utility or efficiency gained from having PUBLISH within a dialog. As numerous people have already pointed out, you have everything you need in the presence doc. itself ... more importantly, the presence doc. MUST be self-sufficient in providing the ordering and versioning information you would get from a dialog. --- Paul Kyzivat wrote: > I agree with Sean that we ought to think of PUBLISH > as a fixed-up > REGISTER. But I agree with Brian that using > Call-ID/CSeq as they are > used in REGISTER is probably a mistake, and fails > to learn from the > mistakes of REGISTER. > > It would be nice if use of dialogs for PUBLISH was > optional. If there > will be substantial traffic, then it may be useful > to set up a dialog. > If there isn't substantial traffic, or if the > endpoints don't want to > bear the cost (as in the case Jonathan described) it > might be better to > forego a dialog. > > Using the dialog mechanism of 3261, there is the > option of sending > PUBLISH messages through a dialog established for > some other purpose, > such as a subscription. If we even want to *permit* > that, then we can't > use Call-ID/CSeq in some conflicting way. > > What we don't get with 3261 is a way to have an > "optionally dialog > establishing" method. If PUBLISH isn't dialog > establishing, but we want > to use it in a dialog and don't have one already, > there is no perfectly > suited mechanism to get one. One possibility might > be to make a > medialess invite. But there are many problems with > that. It seems like > an ugly solution. > > An obvious technique might be for the publisher to > subscribe to its own > presence - something that is likely to be common. > Then it could send > PUBLISH within the resulting dialog. > > Or, we could consider a mechanism for "optionally > dialog creating" methods. > > Paul > > Sean Olson wrote: > > Dialog state for PUBLISH will be a mistake. The > more I think about it, > > the clearer it > > becomes to me that PUBLISH should be a fixed-up > REGISTER. The hardest > > problem is figuring > > out when and how to tear down dialog state for > PUBLISH particularly if > > it is the compositor > > that wants to tear down the dialog. I am > recommending that we use > > Call-ID/CSeq in PUBLISH in > > an analogous way to the way it is used in REGISTER > itself. > > > > -----Original Message----- > > From: simple-admin@ietf.org > [mailto:simple-admin@ietf.org] On Behalf Of > > Jonathan Rosenberg > > Sent: Wednesday, February 05, 2003 8:25 PM > > To: krisztian.kiss@nokia.com > > Cc: pkyzivat@cisco.com; jon.peterson@neustar.biz; > simple@ietf.org > > Subject: Re: [Simple] PUBLISH: a dialog? > > > > > > I am still on the fence on this issue. Some > responses and thoughts > > inline: > > > > krisztian.kiss@nokia.com wrote: > > > Hi All, > > > > > > I am supporting the dialog initiating PUBLISH > method, since that > > > seems to be a step forward to meet some of the > requirements posted to > > > SIMPLE list recently: > > > > http://mailman.dynamicsoft.com/pipermail/simple/2002-December/002103.htm > > l > > > First, I believe the dialog concept would be > preferable to provide > > > >>"feedback" to the PUA about the actual result of > the publishing > > > > > transaction, whether the published XML was > successfully composed to > > > the presence document or not. > > > > I agree with that, but I dont see why you need a > dialog. I had in mind > > that the response to PUBLISH is a 200 OK if the > published data was > > accepted, and the response contains the "raw" > presence data from other > > publishers. This raw data could be used by a PUA > to, for example, > > overwrite the presence data from another PUA. > > > > > Secondly, in a multi-PUA scenario, a > > > dialog would also be useful to provide feedback > about other PUAs' > > > activities, e.g. the publishing PUA could learn > the presence > > > information (including the tuple ids) published by > other PUAs. > > > > I am not as sure there is a need to know when the > published data > > changes, as to be able to fetch it. Considering > our one and only use > > case (going home and then setting the presence > from my PC at work to > > unavailable, since i left it running), the home > device doesn't need to > > know about changes in published information. It > just needs to query to > > find out the set of published data. > > > > Does anyone have some use cases to motivate a > notification feature on > > the publication side? > > > > Jon Peterson wrote: > > > >>However, it isn't clear today if it is necessary > to have a longer-term > > > > > >>identifier in the headers of the PUBLISH method, > considering that the > >>presence information itself may contain its own > identifiers (like the > >>tuple ID in PIDF) that could be reused as needed > (such as the case in > >>which one device overwrites presence published by > another). > > > > > > I think that, if the only thing you need > sequencing for is to determine > > the most recent tuple or status, the identifiers > in the tuples, along > > with the timestamps, will suffice. You also need > to know the source of > > the publisher, but you don't need a dialog for > that. > > > > I would argue that the need for some kind of > sequencing beyond the > > timestamps in the tuples arises if we support > differential (not partial) > > > > publication. In that case, I think you do need > some kind of sequencing > > outside of the tuple id. But, if we don't do that, > even partial > > publication doesn't need sequencing outside of the > pidf. > > > > The counter-arguments is that its probably a good > thing to provide > > sequencing of published presence data independent > of the document type. > > We may have other formats beyond pidf for specific > vertical sources of > > presence data. > > > > The real benefit of the dialog state is the > efficiency of avoiding going > > > > through proxies for updates and refreshes. You > WILL need to refresh, > > because published presence is soft-state. Managing > the soft-state may > > actually be hard if there is no sequencing > provided by the SIP > > mechanism. The Call-ID/CSeq are required in > REGISTER in order to do > > this. > > > > Here is an argument against dialogs. One can > imagine that a PUA might > > actually be this big server that is, for example, > collecting geolocation > > > > for a large number of users and publishing it into > the presence system. > > It would be nice to not require additional state > on === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Feb 8 13:14:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26871 for ; Sat, 8 Feb 2003 13:14:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h18IM5F02325 for simple-archive@odin.ietf.org; Sat, 8 Feb 2003 13:22:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18IM5p02322 for ; Sat, 8 Feb 2003 13:22:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26856 for ; Sat, 8 Feb 2003 13:14:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18IM2p02302; Sat, 8 Feb 2003 13:22:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18ILQp02269 for ; Sat, 8 Feb 2003 13:21:26 -0500 Received: from web41508.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26839 for ; Sat, 8 Feb 2003 13:13:23 -0500 (EST) Message-ID: <20030208181703.19978.qmail@web41508.mail.yahoo.com> Received: from [207.46.228.14] by web41508.mail.yahoo.com via HTTP; Sat, 08 Feb 2003 10:17:03 PST From: Sean Olson Subject: RE: [Simple] PUBLISH: a dialog? To: aki.niemi@nokia.com, pkyzivat@cisco.com Cc: jdrosen@dynamicsoft.com, krisztian.kiss@nokia.com, jon.peterson@neustar.biz, simple@ietf.org In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194514C@esebe013.ntc.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 8 Feb 2003 10:17:03 -0800 (PST) The Expires: is useful for soft-state; something we must have for PUBLISH. But it is horrible for indicating dialog state. It is especially horrible if the compositor wishes to terminate the dialog early. --- aki.niemi@nokia.com wrote: > Hi Paul, > > One way to get this optionality is to use the > SUBSCRIBE/NOTIFY methodology. I.e., have PUBLISH > always create a dialog, but also allow the > infinitely short dialog created by a PUBLISH using > Expires: 0. > > It would sort of be a "push" of presence, similar to > "fetch" in the subscription side. > > Cheers, > Aki > > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 06 February, 2003 17:37 > > To: seancolson@yahoo.com > > Cc: 'Jonathan Rosenberg'; Kiss Krisztian > (NRC/Tampere); > > jon.peterson@neustar.biz; simple@ietf.org > > Subject: Re: [Simple] PUBLISH: a dialog? > > > > > > I agree with Sean that we ought to think of > PUBLISH as a fixed-up > > REGISTER. But I agree with Brian that using > Call-ID/CSeq as they are > > used in REGISTER is probably a mistake, and fails > to learn from the > > mistakes of REGISTER. > > > > It would be nice if use of dialogs for PUBLISH was > optional. If there > > will be substantial traffic, then it may be useful > to set up > > a dialog. > > If there isn't substantial traffic, or if the > endpoints don't want to > > bear the cost (as in the case Jonathan described) > it might be > > better to > > forego a dialog. > > > > Using the dialog mechanism of 3261, there is the > option of sending > > PUBLISH messages through a dialog established for > some other purpose, > > such as a subscription. If we even want to > *permit* that, > > then we can't > > use Call-ID/CSeq in some conflicting way. > > > > What we don't get with 3261 is a way to have an > "optionally dialog > > establishing" method. If PUBLISH isn't dialog > establishing, > > but we want > > to use it in a dialog and don't have one already, > there is no > > perfectly > > suited mechanism to get one. One possibility might > be to make a > > medialess invite. But there are many problems with > that. It > > seems like > > an ugly solution. > > > > An obvious technique might be for the publisher to > subscribe > > to its own > > presence - something that is likely to be common. > Then it could send > > PUBLISH within the resulting dialog. > > > > Or, we could consider a mechanism for "optionally > dialog > > creating" methods. > > > > Paul > > > > Sean Olson wrote: > > > Dialog state for PUBLISH will be a mistake. The > more I > > think about it, > > > the clearer it > > > becomes to me that PUBLISH should be a fixed-up > REGISTER. > > The hardest > > > problem is figuring > > > out when and how to tear down dialog state for > PUBLISH > > particularly if > > > it is the compositor > > > that wants to tear down the dialog. I am > recommending that we use > > > Call-ID/CSeq in PUBLISH in > > > an analogous way to the way it is used in > REGISTER itself. > > > > > > -----Original Message----- > > > From: simple-admin@ietf.org > [mailto:simple-admin@ietf.org] > > On Behalf Of > > > Jonathan Rosenberg > > > Sent: Wednesday, February 05, 2003 8:25 PM > > > To: krisztian.kiss@nokia.com > > > Cc: pkyzivat@cisco.com; > jon.peterson@neustar.biz; simple@ietf.org > > > Subject: Re: [Simple] PUBLISH: a dialog? > > > > > > > > > I am still on the fence on this issue. Some > responses and thoughts > > > inline: > > > > > > krisztian.kiss@nokia.com wrote: > > > > Hi All, > > > > > > > > I am supporting the dialog initiating PUBLISH > method, > > since that > > > > seems to be a step forward to meet some of the > requirements > > posted to > > > > SIMPLE list recently: > > > > > > > http://mailman.dynamicsoft.com/pipermail/simple/2002-December/ > > 002103.htm > > > l > > > > First, I believe the dialog concept would be > preferable > > to provide > > > > > >>"feedback" to the PUA about the actual result of > the publishing > > > > > > > transaction, whether the published XML was > successfully > > composed to > > > > the presence document or not. > > > > > > I agree with that, but I dont see why you need a > dialog. I > > had in mind > > > that the response to PUBLISH is a 200 OK if the > published data was > > > accepted, and the response contains the "raw" > presence data > > from other > > > publishers. This raw data could be used by a PUA > to, for example, > > > overwrite the presence data from another PUA. > > > > > > > Secondly, in a multi-PUA scenario, a > > > > dialog would also be useful to provide > feedback about > > other PUAs' > > > > activities, e.g. the publishing PUA could learn > the presence > > > > information (including the tuple ids) published > by other PUAs. > > > > > > I am not as sure there is a need to know when > the published data > > > changes, as to be able to fetch it. Considering > our one and > > only use > > > case (going home and then setting the presence > from my PC > > at work to > > > unavailable, since i left it running), the home > device > > doesn't need to > > > know about changes in published information. It > just needs > > to query to > > > find out the set of published data. > > > > > > Does anyone have some use cases to motivate a > notification > > feature on > > > the publication side? > > > > > > Jon Peterson wrote: > > > > > >>However, it isn't clear today if it is necessary > to have a > > longer-term > > > > > > > > >>identifier in the headers of the PUBLISH method, > > > considering that the > > >>presence information itself may contain its own > identifiers > > (like the > > >>tuple ID in PIDF) that could be reused as needed > (such as > > the case in > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Feb 8 13:15:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26903 for ; Sat, 8 Feb 2003 13:15:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h18IN5102387 for simple-archive@odin.ietf.org; Sat, 8 Feb 2003 13:23:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18IN4p02384 for ; Sat, 8 Feb 2003 13:23:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26892 for ; Sat, 8 Feb 2003 13:15:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18IN1p02376; Sat, 8 Feb 2003 13:23:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18IMhp02348 for ; Sat, 8 Feb 2003 13:22:43 -0500 Received: from web41507.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26887 for ; Sat, 8 Feb 2003 13:14:40 -0500 (EST) Message-ID: <20030208181820.88180.qmail@web41507.mail.yahoo.com> Received: from [207.46.228.98] by web41507.mail.yahoo.com via HTTP; Sat, 08 Feb 2003 10:18:20 PST From: Sean Olson Subject: Re: [Simple] PUBLISH: a dialog? To: Anders Kristensen , aki.niemi@nokia.com Cc: pkyzivat@cisco.com, seancolson@yahoo.com, jdrosen@dynamicsoft.com, krisztian.kiss@nokia.com, jon.peterson@neustar.biz, simple@ietf.org In-Reply-To: <3E42B9E1.6030304@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 8 Feb 2003 10:18:20 -0800 (PST) I think this is the best option as well. I might go so far as to suggest that allowing methods other than INVITE to establish a dialog is asking for problems. --- Anders Kristensen wrote: > Another option might be to follow the MESSAGE > "methodology"; allow > PUBLISH to be sent in a dialog-less mode or within > an INVITE initiated > dialog. Then obviously BYE could be used by either > party to terminate > the dialog. > > Anders > > > aki.niemi@nokia.com wrote: > > Hi Paul, > > > > One way to get this optionality is to use the > SUBSCRIBE/NOTIFY methodology. I.e., have PUBLISH > always create a dialog, but also allow the > infinitely short dialog created by a PUBLISH using > Expires: 0. > > > > It would sort of be a "push" of presence, similar > to "fetch" in the subscription side. > > > > Cheers, > > Aki > > > > > >>-----Original Message----- > >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: 06 February, 2003 17:37 > >>To: seancolson@yahoo.com > >>Cc: 'Jonathan Rosenberg'; Kiss Krisztian > (NRC/Tampere); > >>jon.peterson@neustar.biz; simple@ietf.org > >>Subject: Re: [Simple] PUBLISH: a dialog? > >> > >> > >>I agree with Sean that we ought to think of > PUBLISH as a fixed-up > >>REGISTER. But I agree with Brian that using > Call-ID/CSeq as they are > >>used in REGISTER is probably a mistake, and fails > to learn from the > >>mistakes of REGISTER. > >> > >>It would be nice if use of dialogs for PUBLISH was > optional. If there > >>will be substantial traffic, then it may be useful > to set up > >>a dialog. > >>If there isn't substantial traffic, or if the > endpoints don't want to > >>bear the cost (as in the case Jonathan described) > it might be > >>better to > >>forego a dialog. > >> > >>Using the dialog mechanism of 3261, there is the > option of sending > >>PUBLISH messages through a dialog established for > some other purpose, > >>such as a subscription. If we even want to > *permit* that, > >>then we can't > >>use Call-ID/CSeq in some conflicting way. > >> > >>What we don't get with 3261 is a way to have an > "optionally dialog > >>establishing" method. If PUBLISH isn't dialog > establishing, > >>but we want > >>to use it in a dialog and don't have one already, > there is no > >>perfectly > >>suited mechanism to get one. One possibility might > be to make a > >>medialess invite. But there are many problems with > that. It > >>seems like > >>an ugly solution. > >> > >>An obvious technique might be for the publisher to > subscribe > >>to its own > >>presence - something that is likely to be common. > Then it could send > >>PUBLISH within the resulting dialog. > >> > >>Or, we could consider a mechanism for "optionally > dialog > >>creating" methods. > >> > >> Paul > >> > >>Sean Olson wrote: > >> > >>>Dialog state for PUBLISH will be a mistake. The > more I > >> > >>think about it, > >> > >>>the clearer it > >>>becomes to me that PUBLISH should be a fixed-up > REGISTER. > >> > >>The hardest > >> > >>>problem is figuring > >>>out when and how to tear down dialog state for > PUBLISH > >> > >>particularly if > >> > >>>it is the compositor > >>>that wants to tear down the dialog. I am > recommending that we use > >>>Call-ID/CSeq in PUBLISH in > >>>an analogous way to the way it is used in > REGISTER itself. > >>> > >>>-----Original Message----- > >>>From: simple-admin@ietf.org > [mailto:simple-admin@ietf.org] > >> > >>On Behalf Of > >> > >>>Jonathan Rosenberg > >>>Sent: Wednesday, February 05, 2003 8:25 PM > >>>To: krisztian.kiss@nokia.com > >>>Cc: pkyzivat@cisco.com; jon.peterson@neustar.biz; > simple@ietf.org > >>>Subject: Re: [Simple] PUBLISH: a dialog? > >>> > >>> > >>>I am still on the fence on this issue. Some > responses and thoughts > >>>inline: > >>> > >>>krisztian.kiss@nokia.com wrote: > >>> > Hi All, > >>> > > >>> > I am supporting the dialog initiating PUBLISH > method, > >> > >>since that > > >> > >>>seems to be a step forward to meet some of the > requirements > >> > >>posted to > > >> > >>>SIMPLE list recently: > > >>> > >>http://mailman.dynamicsoft.com/pipermail/simple/2002-December/ > >>002103.htm > >> > >>>l > >>> > First, I believe the dialog concept would be > preferable > >> > >>to provide > >> > >>>>"feedback" to the PUA about the actual result of > the publishing > > >>> > >>>transaction, whether the published XML was > successfully > >> > >>composed to > > >> > >>>the presence document or not. > >>> > >>>I agree with that, but I dont see why you need a > dialog. I > >> > >>had in mind > >> > >>>that the response to PUBLISH is a 200 OK if the > published data was > >>>accepted, and the response contains the "raw" > presence data > >> > >>from other > >> > >>>publishers. This raw data could be used by a PUA > to, for example, > >>>overwrite the presence data from another PUA. > >>> > >>> > Secondly, in a multi-PUA scenario, a > >>> > dialog would also be useful to provide > feedback about > >> > >>other PUAs' > > >> > >>>activities, e.g. the publishing PUA could learn > the presence > > >>>information (including the tuple ids) published > by other PUAs. > >>> > >>>I am not as sure there is a need to know when the > published data > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Feb 8 19:46:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04609 for ; Sat, 8 Feb 2003 19:46:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h190sLr20135 for simple-archive@odin.ietf.org; Sat, 8 Feb 2003 19:54:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h190sLp20132 for ; Sat, 8 Feb 2003 19:54:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04599 for ; Sat, 8 Feb 2003 19:46:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h190sGp20124; Sat, 8 Feb 2003 19:54:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h190rcp20102 for ; Sat, 8 Feb 2003 19:53:38 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04594 for ; Sat, 8 Feb 2003 19:45:26 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h190nmUt017520; Sat, 8 Feb 2003 19:49:48 -0500 (EST) Received: from cisco.com (rtp-vpn1-217.cisco.com [10.82.224.217]) by cannon.cisco.com (Mirapoint) with ESMTP id AAZ39255; Sat, 8 Feb 2003 19:53:55 -0500 (EST) Message-ID: <3E45A573.6090500@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson CC: Anders Kristensen , aki.niemi@nokia.com, jdrosen@dynamicsoft.com, krisztian.kiss@nokia.com, jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] PUBLISH: a dialog? References: <20030208181820.88180.qmail@web41507.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 08 Feb 2003 19:48:51 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree that this is a reasonable approach. It does however open up some new issues that would need to be sorted out - not a fundamental problem, just more work. Specifically, what should a UAS do when receiving a "medialess" invitation? This probably depends on the purpose of the invitation. In the case we are discussing the purpose is simply to establish a dialog to carry PUBLISH messages, but it could be preparatory to a reinvitation with media, or whatever. If the UAS happens to be capable, should it alert? Paul P.S. Describing this approach as "following the MESSAGE methodology" is a bit of a misnomer. Establishing a dialog for the purpose of creating a "message session" has been forbidden. Sean Olson wrote: > I think this is the best option as well. > I might go so far as to suggest that allowing > methods other than INVITE to establish a dialog > is asking for problems. > > --- Anders Kristensen > wrote: > >>Another option might be to follow the MESSAGE >>"methodology"; allow >>PUBLISH to be sent in a dialog-less mode or within >>an INVITE initiated >>dialog. Then obviously BYE could be used by either >>party to terminate >>the dialog. >> >>Anders >> >> >>aki.niemi@nokia.com wrote: >> >>>Hi Paul, >>> >>>One way to get this optionality is to use the >> >>SUBSCRIBE/NOTIFY methodology. I.e., have PUBLISH >>always create a dialog, but also allow the >>infinitely short dialog created by a PUBLISH using >>Expires: 0. >> >>>It would sort of be a "push" of presence, similar >> >>to "fetch" in the subscription side. >> >>>Cheers, >>>Aki >>> >>> >>> >>>>-----Original Message----- >>>>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>Sent: 06 February, 2003 17:37 >>>>To: seancolson@yahoo.com >>>>Cc: 'Jonathan Rosenberg'; Kiss Krisztian >>> >>(NRC/Tampere); >> >>>>jon.peterson@neustar.biz; simple@ietf.org >>>>Subject: Re: [Simple] PUBLISH: a dialog? >>>> >>>> >>>>I agree with Sean that we ought to think of >>> >>PUBLISH as a fixed-up >> >>>>REGISTER. But I agree with Brian that using >>> >>Call-ID/CSeq as they are >> >>>>used in REGISTER is probably a mistake, and fails >>> >>to learn from the >> >>>>mistakes of REGISTER. >>>> >>>>It would be nice if use of dialogs for PUBLISH was >>> >>optional. If there >> >>>>will be substantial traffic, then it may be useful >>> >>to set up >> >>>>a dialog. >>>>If there isn't substantial traffic, or if the >>> >>endpoints don't want to >> >>>>bear the cost (as in the case Jonathan described) >>> >>it might be >> >>>>better to >>>>forego a dialog. >>>> >>>>Using the dialog mechanism of 3261, there is the >>> >>option of sending >> >>>>PUBLISH messages through a dialog established for >>> >>some other purpose, >> >>>>such as a subscription. If we even want to >>> >>*permit* that, >> >>>>then we can't >>>>use Call-ID/CSeq in some conflicting way. >>>> >>>>What we don't get with 3261 is a way to have an >>> >>"optionally dialog >> >>>>establishing" method. If PUBLISH isn't dialog >>> >>establishing, >> >>>>but we want >>>>to use it in a dialog and don't have one already, >>> >>there is no >> >>>>perfectly >>>>suited mechanism to get one. One possibility might >>> >>be to make a >> >>>>medialess invite. But there are many problems with >>> >>that. It >> >>>>seems like >>>>an ugly solution. >>>> >>>>An obvious technique might be for the publisher to >>> >>subscribe >> >>>>to its own >>>>presence - something that is likely to be common. >>> >>Then it could send >> >>>>PUBLISH within the resulting dialog. >>>> >>>>Or, we could consider a mechanism for "optionally >>> >>dialog >> >>>>creating" methods. >>>> >>>> Paul >>>> >>>>Sean Olson wrote: >>>> >>>> >>>>>Dialog state for PUBLISH will be a mistake. The >>>> >>more I >> >>>>think about it, >>>> >>>> >>>>>the clearer it >>>>>becomes to me that PUBLISH should be a fixed-up >>>> >>REGISTER. >> >>>>The hardest >>>> >>>> >>>>>problem is figuring >>>>>out when and how to tear down dialog state for >>>> >>PUBLISH >> >>>>particularly if >>>> >>>> >>>>>it is the compositor >>>>>that wants to tear down the dialog. I am >>>> >>recommending that we use >> >>>>>Call-ID/CSeq in PUBLISH in >>>>>an analogous way to the way it is used in >>>> >>REGISTER itself. >> >>>>>-----Original Message----- >>>>>From: simple-admin@ietf.org >>>> >>[mailto:simple-admin@ietf.org] >> >>>>On Behalf Of >>>> >>>> >>>>>Jonathan Rosenberg >>>>>Sent: Wednesday, February 05, 2003 8:25 PM >>>>>To: krisztian.kiss@nokia.com >>>>>Cc: pkyzivat@cisco.com; jon.peterson@neustar.biz; >>>> >>simple@ietf.org >> >>>>>Subject: Re: [Simple] PUBLISH: a dialog? >>>>> >>>>> >>>>>I am still on the fence on this issue. Some >>>> >>responses and thoughts >> >>>>>inline: >>>>> >>>>>krisztian.kiss@nokia.com wrote: >>>>> >>>>>>Hi All, >>>>>> >>>>>>I am supporting the dialog initiating PUBLISH >>>>> >>method, >> >>>>since that > >>>> >>>>>seems to be a step forward to meet some of the >>>> >>requirements >> >>>>posted to > >>>> >>>>>SIMPLE list recently: > >>>>> >>>http://mailman.dynamicsoft.com/pipermail/simple/2002-December/ >>> >>>>002103.htm >>>> >>>> >>>>>l >>>>> >>>>>> First, I believe the dialog concept would be >>>>> >>preferable >> >>>>to provide >>>> >>>> >>>>>>"feedback" to the PUA about the actual result of >>>>> >>the publishing > >> >>>>>transaction, whether the published XML was >>>> >>successfully >> >>>>composed to > >>>> >>>>>the presence document or not. >>>>> >>>>>I agree with that, but I dont see why you need a >>>> >>dialog. I >> >>>>had in mind >>>> >>>> >>>>>that the response to PUBLISH is a 200 OK if the >>>> >>published data was >> >>>>>accepted, and the response contains the "raw" >>>> >>presence data >> >>>>from other >>> >>>>>publishers. This raw data could be used by a PUA >>>> >>to, for example, >> >>>>>overwrite the presence data from another PUA. >>>>> >>>>> >>>>>>Secondly, in a multi-PUA scenario, a >>>>>>dialog would also be useful to provide >>>>> >>feedback about >> >>>>other PUAs' > >>>> >>>>>activities, e.g. the publishing PUA could learn >>>> >>the presence > >> >>>>>information (including the tuple ids) published >>>> >>by other PUAs. >> >>>>>I am not as sure there is a need to know when the >>>> >>published data >> > > === message truncated === > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Feb 9 02:13:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21872 for ; Sun, 9 Feb 2003 02:13:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h197LY314831 for simple-archive@odin.ietf.org; Sun, 9 Feb 2003 02:21:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h197LYp14828 for ; Sun, 9 Feb 2003 02:21:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21859 for ; Sun, 9 Feb 2003 02:13:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h197LOp14820; Sun, 9 Feb 2003 02:21:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h197Ktp14802 for ; Sun, 9 Feb 2003 02:20:55 -0500 Received: from il-tlv-smtpout2.icomverse.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21851 for ; Sun, 9 Feb 2003 02:12:34 -0500 (EST) Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h197Fnk21824; Sun, 9 Feb 2003 09:15:49 +0200 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id ; Sun, 9 Feb 2003 09:15:53 +0200 Message-ID: <385D702A9C11D511A9E90008C7160AD505454041@ismail1.comverse.com> From: Cnaan Oded To: "'Jonathan Rosenberg'" Cc: simple@ietf.org Subject: RE: [Simple] Invisible and RPIDS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D009.02FDF0F8" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 9 Feb 2003 09:15:45 +0200 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_01C2D009.02FDF0F8 Content-Type: text/plain; charset="iso-8859-1" Jonathan, the question is where do we put the line between the IM and the Presence applications. In the scenario you've described below, the Presence application also takes care of message routing logics where it seems to me that this should be left to the messaging application. IMO, PSs should not accommodate for all the special features and logics required by enabling applications as we'll never be able to satisfy all applications. A PS needs to manage and maintain only pure Presence data and leave applications to handle their internal logics. For example, let's say that we have also a PTT app. What does 'Invisible' mean now regarding messaging? Should urgent PTTs be allowed as well? As long as PSs do not allow setting different Presence state to each watcher, it seems that the INVISIBLE state is not very useful as the user will be seen as CLOSED to all his watchers so they will not (instant) communicate him. To implement this mode, an IM app may have a transformation policy that an OPEN/BUSY state should be sent to the PS as CLOSED. In any case, the message should be directed to the IM app that can push it to the user instead of storing it for later use. Oded Cnaan > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, February 07, 2003 7:31 AM > To: Henning Schulzrinne > Cc: simple@ietf.org > Subject: Re: [Simple] Invisible and RPIDS > > > > > Henning Schulzrinne wrote: > >>> I believe this can be done already in RPIDS. I could > label certain > >>> states with keywords that are recognized by my policy > script, which > >>> then transforms them into the appropriate tuples before > delivery to > >>> watchers. > >> > >> > >> > >> I am less worried about the transformations, as I am about > the notion > >> of certain presence states being designed specifically for > >> interpretation by an application (IM in this case). > > > > > > Why create an application-specific solution when a generic > solution works? > > What is the generic solution? > > > > >> > >>> (Or, the transformation could depend on the presence data itself, > >>> e.g., on time of day or other clues. For example, I could > >>> automatically declare myself selectively invisible when > my > >>> says 'meeting'.) > >> > >> > >> > >> Right. As I said, the transformation part is just part of > the policy, > >> letting certain watchers see certain things, and others > see different > >> things. The issue really is that I have one watcher in > particular, the > >> IM app, for which I want it to do something very specific when my > >> presence state has a particular value. This would seem to > require some > >> kind of standardization of states. > > > > > > Why? Why can't my IM app be part of the same policy transformation > > machinery that generates handling instructions for, say, > SIP INVITEs? > > I don't follow your analogy, but let me provide a specific case. Lets > say I want to set my presence status to something which tells > an IM app > to block IMs to me except high priority ones. There are two > approaches > to that: > > 1. set my basic presence status to OPEN, and set my > activity to "busy" > or something like that. Then, set a transformation policy which sets > this to CLOSED for everyone but the IM app. The IM app is then > configured to know that busy/OPEN means block all but high > priority IM. > Perhaps this is what you mean by the generic solution. > > 2. set my basic status to OPEN, set my activity to "busy", > and also set > my IM-app status to "block-all-but-high-priority". The same > transformation policy sets this to CLOSED for everyone but > the IM app. > However, the IM app looks at the IM-app status which gives it an > explicit directive. If we want these to be interoperable across > clients/IM applications, they would need to be standardized. > > > The main issue with case 1 is that my client, on my providers IM app, > may do the right thing, but if my client connects to a different > provider with a different IM app, the IM app behavior might > be different. > > Now, that said, there are cases where an application does > something on > my behalf as a side-effect of a presence change. In those > cases, I dont > want to mandate those application behaviors. However, the question is > whether people think there is a need to provide EXPLICIT > directives to > applications through presence. > > -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@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > ------_=_NextPart_001_01C2D009.02FDF0F8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Invisible and RPIDS

Jonathan, the question is where do we put the line = between the IM and the Presence applications. In the scenario you've = described below, the Presence application also takes care of message = routing logics where it seems to me that this should be left to the = messaging application.

IMO, PSs should not accommodate for all the special = features and logics required by enabling applications as we'll never be = able to satisfy all applications. A PS needs to manage and maintain = only pure Presence data and leave applications to handle their internal = logics. For example, let's say that we have also a PTT app. What does = 'Invisible' mean now regarding messaging? Should urgent PTTs be allowed = as well?

As long as PSs do not allow setting different = Presence state to each watcher, it seems that the INVISIBLE state is = not very useful as the user will be seen as CLOSED to all his watchers = so they will not (instant) communicate him. To implement this mode, an = IM app may have a transformation policy that an OPEN/BUSY state should = be sent to the PS as CLOSED. In any case, the message should be = directed to the IM app that can push it to the user instead of storing = it for later use.

 
Oded Cnaan


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, February 07, 2003 7:31 AM
> To: Henning Schulzrinne
> Cc: simple@ietf.org
> Subject: Re: [Simple] Invisible and = RPIDS
>
>
>
>
> Henning Schulzrinne wrote:
> >>> I believe this can be done already = in RPIDS. I could
> label certain
> >>> states with keywords that are = recognized by my policy
> script, which
> >>> then transforms them into the = appropriate tuples before
> delivery to
> >>> watchers.
> >>
> >>
> >>
> >> I am less worried about the = transformations, as I am about
> the notion
> >> of certain presence states being = designed specifically for
> >> interpretation by an application (IM = in this case).
> >
> >
> > Why create an application-specific = solution when a generic
> solution works?
>
> What is the generic solution?
>
> >
> >>
> >>> (Or, the transformation could = depend on the presence data itself,
> >>> e.g., on time of day or other = clues. For example, I could
> >>> automatically declare myself = selectively invisible when
> my <category>
> >>> says 'meeting'.)
> >>
> >>
> >>
> >> Right. As I said, the transformation = part is just part of
> the policy,
> >> letting certain watchers see certain = things, and others
> see different
> >> things. The issue really is that I = have one watcher in
> particular, the
> >> IM app, for which I want it to do = something very specific when my
> >> presence state has a particular value. = This would seem to
> require some
> >> kind of standardization of = states.
> >
> >
> > Why? Why can't my IM app be part of the = same policy transformation
> > machinery that generates handling = instructions for, say,
> SIP INVITEs?
>
> I don't follow your analogy, but let me provide = a specific case. Lets
> say I want to set my presence status to = something which tells
> an IM app
> to block IMs to me except high priority ones. = There are two
> approaches
> to that:
>
>   1. set my basic presence status to = OPEN, and set my
> activity to "busy"
> or something like that. Then, set a = transformation policy which sets
> this to CLOSED for everyone but the IM app. The = IM app is then
> configured to know that busy/OPEN means block = all but high
> priority IM.
> Perhaps this is what you mean by the generic = solution.
>
> 2. set my basic status to OPEN, set my activity = to "busy",
> and also set
> my IM-app status to = "block-all-but-high-priority". The same
> transformation policy sets this to CLOSED for = everyone but
> the IM app.
> However, the IM app looks at the IM-app status = which gives it an
> explicit directive. If we want these to be = interoperable across
> clients/IM applications, they would need to be = standardized.
>
>
> The main issue with case 1 is that my client, = on my providers IM app,
> may do the right thing, but if my client = connects to a different
> provider with a different IM app, the IM app = behavior might
> be different.
>
> Now, that said, there are cases where an = application does
> something on
> my behalf as a side-effect of a presence = change. In those
> cases, I dont
> want to mandate those application behaviors. = However, the question is
> whether people think there is a need to provide = EXPLICIT
> directives to
> applications through presence.
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
> Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> = _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>

------_=_NextPart_001_01C2D009.02FDF0F8-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Feb 9 12:38:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02728 for ; Sun, 9 Feb 2003 12:38:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h19HkIf12873 for simple-archive@odin.ietf.org; Sun, 9 Feb 2003 12:46:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h19HkIp12870 for ; Sun, 9 Feb 2003 12:46:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02721 for ; Sun, 9 Feb 2003 12:37:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h19HkCp12861; Sun, 9 Feb 2003 12:46:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h19Hjrp12841 for ; Sun, 9 Feb 2003 12:45:53 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02714 for ; Sun, 9 Feb 2003 12:37:20 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h19HdJWm001761; Sun, 9 Feb 2003 12:39:19 -0500 (EST) Received: from dynamicsoft.com (63.113.46.53 [63.113.46.53]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 11J5VYZM; Sun, 9 Feb 2003 12:40:57 -0500 Message-ID: <3E46929E.3020205@dynamicsoft.com> From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Sean Olson , aki.niemi@nokia.com, jdrosen@dynamicsoft.com, krisztian.kiss@nokia.com, jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] PUBLISH: a dialog? References: <20030208181820.88180.qmail@web41507.mail.yahoo.com> <3E45A573.6090500@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 09 Feb 2003 12:40:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I agree that this is a reasonable approach. > > It does however open up some new issues that would need to be sorted out > - not a fundamental problem, just more work. Specifically, what should a > UAS do when receiving a "medialess" invitation? This probably depends on > the purpose of the invitation. In the case we are discussing the purpose > is simply to establish a dialog to carry PUBLISH messages, but it could > be preparatory to a reinvitation with media, or whatever. If the UAS > happens to be capable, should it alert? The intent to send PUBLISH'es over a dialog could be "negotiated" through an m= line of the sdp in the INVITE similar to what we're doing for session-mode MESSAGEs. > > Paul > > P.S. Describing this approach as "following the MESSAGE methodology" is > a bit of a misnomer. Establishing a dialog for the purpose of creating a > "message session" has been forbidden. OK, I wasn't aware of that. Where does it say that, actually? Seems a bit odd to me at first blush. Anders > > Sean Olson wrote: > >> I think this is the best option as well. >> I might go so far as to suggest that allowing methods other than >> INVITE to establish a dialog >> is asking for problems. >> >> --- Anders Kristensen >> wrote: >> >>> Another option might be to follow the MESSAGE >>> "methodology"; allow PUBLISH to be sent in a dialog-less mode or within >>> an INVITE initiated dialog. Then obviously BYE could be used by either >>> party to terminate the dialog. >>> >>> Anders >>> >>> >>> aki.niemi@nokia.com wrote: >>> >>>> Hi Paul, >>>> >>>> One way to get this optionality is to use the >>> >>> >>> SUBSCRIBE/NOTIFY methodology. I.e., have PUBLISH >>> always create a dialog, but also allow the >>> infinitely short dialog created by a PUBLISH using >>> Expires: 0. >>> >>>> It would sort of be a "push" of presence, similar >>> >>> >>> to "fetch" in the subscription side. >>> >>>> Cheers, >>>> Aki >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: 06 February, 2003 17:37 >>>>> To: seancolson@yahoo.com >>>>> Cc: 'Jonathan Rosenberg'; Kiss Krisztian >>>> >>>> >>> (NRC/Tampere); >>> >>>>> jon.peterson@neustar.biz; simple@ietf.org >>>>> Subject: Re: [Simple] PUBLISH: a dialog? >>>>> >>>>> >>>>> I agree with Sean that we ought to think of >>>> >>>> >>> PUBLISH as a fixed-up >>> >>>>> REGISTER. But I agree with Brian that using >>>> >>>> >>> Call-ID/CSeq as they are >>> >>>>> used in REGISTER is probably a mistake, and fails >>>> >>>> >>> to learn from the >>> >>>>> mistakes of REGISTER. >>>>> >>>>> It would be nice if use of dialogs for PUBLISH was >>>> >>>> >>> optional. If there >>> >>>>> will be substantial traffic, then it may be useful >>>> >>>> >>> to set up >>> >>>>> a dialog. If there isn't substantial traffic, or if the >>>> >>>> >>> endpoints don't want to >>> >>>>> bear the cost (as in the case Jonathan described) >>>> >>>> >>> it might be >>> >>>>> better to forego a dialog. >>>>> >>>>> Using the dialog mechanism of 3261, there is the >>>> >>>> >>> option of sending >>> >>>>> PUBLISH messages through a dialog established for >>>> >>>> >>> some other purpose, >>> >>>>> such as a subscription. If we even want to >>>> >>>> >>> *permit* that, >>> >>>>> then we can't use Call-ID/CSeq in some conflicting way. >>>>> >>>>> What we don't get with 3261 is a way to have an >>>> >>>> >>> "optionally dialog >>> >>>>> establishing" method. If PUBLISH isn't dialog >>>> >>>> >>> establishing, >>> >>>>> but we want to use it in a dialog and don't have one already, >>>> >>>> >>> there is no >>> >>>>> perfectly suited mechanism to get one. One possibility might >>>> >>>> >>> be to make a >>> >>>>> medialess invite. But there are many problems with >>>> >>>> >>> that. It >>> >>>>> seems like an ugly solution. >>>>> >>>>> An obvious technique might be for the publisher to >>>> >>>> >>> subscribe >>> >>>>> to its own presence - something that is likely to be common. >>>> >>>> >>> Then it could send >>> >>>>> PUBLISH within the resulting dialog. >>>>> >>>>> Or, we could consider a mechanism for "optionally >>>> >>>> >>> dialog >>> >>>>> creating" methods. >>>>> >>>>> Paul >>>>> >>>>> Sean Olson wrote: >>>>> >>>>> >>>>>> Dialog state for PUBLISH will be a mistake. The >>>>> >>>>> >>> more I >>> >>>>> think about it, >>>>> >>>>> >>>>>> the clearer it >>>>>> becomes to me that PUBLISH should be a fixed-up >>>>> >>>>> >>> REGISTER. >>> >>>>> The hardest >>>>> >>>>> >>>>>> problem is figuring >>>>>> out when and how to tear down dialog state for >>>>> >>>>> >>> PUBLISH >>> >>>>> particularly if >>>>> >>>>> >>>>>> it is the compositor >>>>>> that wants to tear down the dialog. I am >>>>> >>>>> >>> recommending that we use >>> >>>>>> Call-ID/CSeq in PUBLISH in >>>>>> an analogous way to the way it is used in >>>>> >>>>> >>> REGISTER itself. >>> >>>>>> -----Original Message----- >>>>>> From: simple-admin@ietf.org >>>>> >>>>> >>> [mailto:simple-admin@ietf.org] >>> >>>>> On Behalf Of >>>>> >>>>> >>>>>> Jonathan Rosenberg >>>>>> Sent: Wednesday, February 05, 2003 8:25 PM >>>>>> To: krisztian.kiss@nokia.com >>>>>> Cc: pkyzivat@cisco.com; jon.peterson@neustar.biz; >>>>> >>>>> >>> simple@ietf.org >>> >>>>>> Subject: Re: [Simple] PUBLISH: a dialog? >>>>>> >>>>>> >>>>>> I am still on the fence on this issue. Some >>>>> >>>>> >>> responses and thoughts >>> >>>>>> inline: >>>>>> >>>>>> krisztian.kiss@nokia.com wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I am supporting the dialog initiating PUBLISH >>>>>> >>>>>> >>> method, >>> >>>>> since that > >>>>> >>>>>> seems to be a step forward to meet some of the >>>>> >>>>> >>> requirements >>> >>>>> posted to > >>>>> >>>>>> SIMPLE list recently: > >>>>>> >>>> http://mailman.dynamicsoft.com/pipermail/simple/2002-December/ >>>> >>>>> 002103.htm >>>>> >>>>> >>>>>> l >>>>>> >>>>>>> First, I believe the dialog concept would be >>>>>> >>>>>> >>> preferable >>> >>>>> to provide >>>>> >>>>> >>>>>>> "feedback" to the PUA about the actual result of >>>>>> >>>>>> >>> the publishing > >>> >>>>>> transaction, whether the published XML was >>>>> >>>>> >>> successfully >>> >>>>> composed to > >>>>> >>>>>> the presence document or not. >>>>>> >>>>>> I agree with that, but I dont see why you need a >>>>> >>>>> >>> dialog. I >>> >>>>> had in mind >>>>> >>>>>> that the response to PUBLISH is a 200 OK if the >>>>> >>>>> >>> published data was >>> >>>>>> accepted, and the response contains the "raw" >>>>> >>>>> >>> presence data >>> >>>>> from other >>>> >>>> >>>>>> publishers. This raw data could be used by a PUA >>>>> >>>>> >>> to, for example, >>> >>>>>> overwrite the presence data from another PUA. >>>>>> >>>>>> >>>>>>> Secondly, in a multi-PUA scenario, a >>>>>>> dialog would also be useful to provide >>>>>> >>>>>> >>> feedback about >>> >>>>> other PUAs' > >>>>> >>>>>> activities, e.g. the publishing PUA could learn >>>>> >>>>> >>> the presence > >>> >>>>>> information (including the tuple ids) published >>>>> >>>>> >>> by other PUAs. >>> >>>>>> I am not as sure there is a need to know when the >>>>> >>>>> >>> published data >> >> >> === message truncated === >> >> >> __________________________________________________ >> Do you Yahoo!? >> Yahoo! Mail Plus - Powerful. Affordable. Sign up now. >> http://mailplus.yahoo.com >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Feb 9 22:48:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14159 for ; Sun, 9 Feb 2003 22:48:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1A3uNM06725 for simple-archive@odin.ietf.org; Sun, 9 Feb 2003 22:56:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A3uNp06722 for ; Sun, 9 Feb 2003 22:56:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14148 for ; Sun, 9 Feb 2003 22:47:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A3uHp06713; Sun, 9 Feb 2003 22:56:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A3tOp06693 for ; Sun, 9 Feb 2003 22:55:24 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14138 for ; Sun, 9 Feb 2003 22:46:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1A3oNYH020921; Sun, 9 Feb 2003 22:50:23 -0500 (EST) Message-ID: <3E47217B.2020207@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Kristensen CC: Paul Kyzivat , Sean Olson , aki.niemi@nokia.com, krisztian.kiss@nokia.com, jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] PUBLISH: a dialog? References: <20030208181820.88180.qmail@web41507.mail.yahoo.com> <3E45A573.6090500@cisco.com> <3E46929E.3020205@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 09 Feb 2003 22:50:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > > Paul Kyzivat wrote: > >> I agree that this is a reasonable approach. >> >> It does however open up some new issues that would need to be sorted >> out - not a fundamental problem, just more work. Specifically, what >> should a UAS do when receiving a "medialess" invitation? This probably >> depends on the purpose of the invitation. In the case we are >> discussing the purpose is simply to establish a dialog to carry >> PUBLISH messages, but it could be preparatory to a reinvitation with >> media, or whatever. If the UAS happens to be capable, should it alert? > > > The intent to send PUBLISH'es over a dialog could be "negotiated" > through an m= line of the sdp in the INVITE similar to what we're doing > for session-mode MESSAGEs. I would prefer to decouple this from our deliverable. That is, I would prefer to specify PUBLISH as not having anything to do with dialogs, and separately, if we deem it necessary, work out what it means to use INVITE to set up a publication session. > >> >> Paul >> >> P.S. Describing this approach as "following the MESSAGE methodology" >> is a bit of a misnomer. Establishing a dialog for the purpose of >> creating a "message session" has been forbidden. > > > OK, I wasn't aware of that. Where does it say that, actually? Seems a > bit odd to me at first blush. It says it in rfc3428, section 2: > There may be a temptation to simulate a session of IMs by initiating > a dialog, then sending MESSAGE requests in the context of that > dialog. This is not an adequate solution for IM sessions, in that > this approach forces the MESSAGE requests to follow the same network > path as any other SIP requests, even though the MESSAGE requests > arguably carry media rather than signaling. IM applications are > typically high volume, and we expect the IM volume in sessions to be > even higher. This will likely cause congestion problems if sent over > a transport without congestion control, and there is no clear > mechanism in SIP to prevent some hop from forwarding a MESSAGE > request over UDP. -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 10 04:03:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00994 for ; Mon, 10 Feb 2003 04:03:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1A9CAu01297 for simple-archive@odin.ietf.org; Mon, 10 Feb 2003 04:12:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A9CAp01294 for ; Mon, 10 Feb 2003 04:12:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00988 for ; Mon, 10 Feb 2003 04:03:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A9C6p01285; Mon, 10 Feb 2003 04:12:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A9B3p01261 for ; Mon, 10 Feb 2003 04:11:03 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00956 for ; Mon, 10 Feb 2003 04:02:09 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1A94f211476 for ; Mon, 10 Feb 2003 11:04:41 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Feb 2003 11:05:49 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Feb 2003 11:05:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] PUBLISH: a dialog? Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945150@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: a dialog? Thread-Index: AcLQYm4NtJz9KcVDRRi2Q6ffDoA9aQAgGIuw To: , Cc: , , , , X-OriginalArrivalTime: 10 Feb 2003 09:05:49.0490 (UTC) FILETIME=[9AE8D920:01C2D0E3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1A9B7p01262 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Feb 2003 11:05:49 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Inline. > -----Original Message----- > From: ext Anders Kristensen [mailto:akristensen@dynamicsoft.com] > > Paul Kyzivat wrote: > > I agree that this is a reasonable approach. > > > > It does however open up some new issues that would need to > be sorted out > > - not a fundamental problem, just more work. Specifically, > what should a > > UAS do when receiving a "medialess" invitation? This > probably depends on > > the purpose of the invitation. In the case we are > discussing the purpose > > is simply to establish a dialog to carry PUBLISH messages, > but it could > > be preparatory to a reinvitation with media, or whatever. > If the UAS > > happens to be capable, should it alert? > > The intent to send PUBLISH'es over a dialog could be "negotiated" > through an m= line of the sdp in the INVITE similar to what > we're doing > for session-mode MESSAGEs. We can also go down this path and forget PUBLISH altogether, and use a PDIF-over-TCP media - just like we've done away with MESSAGE in the message session work. It seems to me we're going around in circles here. Where are the requirements driving this discussion? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 10 04:35:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01776 for ; Mon, 10 Feb 2003 04:35:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1A9i5q02916 for simple-archive@odin.ietf.org; Mon, 10 Feb 2003 04:44:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A9i5p02913 for ; Mon, 10 Feb 2003 04:44:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01771 for ; Mon, 10 Feb 2003 04:35:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A9i2p02899; Mon, 10 Feb 2003 04:44:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A9hnp02853 for ; Mon, 10 Feb 2003 04:43:49 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01766 for ; Mon, 10 Feb 2003 04:34:57 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1A9fOm26699 for ; Mon, 10 Feb 2003 11:41:24 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Feb 2003 11:38:38 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Feb 2003 11:38:37 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Feb 2003 11:38:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7253@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RPIDS: Capabilities in tuples and Caller Prefs Thread-Index: AcLO2mIW5PiYwb2cTkesjH2EWxMv7wCC84mg To: , Cc: X-OriginalArrivalTime: 10 Feb 2003 09:38:37.0572 (UTC) FILETIME=[2FFA5440:01C2D0E8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1A9hnp02854 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Feb 2003 11:38:36 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, February 07, 2003 8:55 PM > To: 'Jonathan Rosenberg' > Cc: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs > > > > This will require every presence client to support caller prefs. > We'll, let's be carefull, a presence client per se doesn't > make calls to devices. It's the calling UA that would need to > support caller prefs if it wishes to direct the call to a specific > device. The UA and the presence client are likely to be > one and the same, but let's keep the roles separate please. It is a likely case that they are physically separate. I was a presence client on my PC, but make my calls from my mobile phone. Its much easier to make caller prefences than having to copy a uri that looks like: sip:brosen-998sadjkkl9asd8sda66s6dd89800@eng.marconi.com. I don't mind mandating caller preferences to be implemented, if a user wants to own a UA that has the luxury feature of presence based call routing. > > Now, if I do get a complex presence document, and, for some reason > I have yet to really understand, I want to insist that the call go to > a specific device maintained by the principal, then, yes, the > caller UA has to support caller prefs. > > You can contrast that with inventing a new language to describe > various characteristics of a device, and having the UA have to > interpret that, as well as caller prefs. > > > > > It also means that the client has to correctly guess the > > right series of > > caller preferences to route the request to the desired contact. > I think any mechanism we come up with to differentiate one device > from another can be implemented in caller prefs, rather than somewhere > else. > > > > > It also means that every proxy in the presentity domain has > > to support > > caller preferences. > No, I think it means that the incoming sip proxy for calls > (IM, games,...) > that forwards based on your presence has to understand caller prefs. > It's pass-along to everyone else in the sip domain. It doesn't occur > in the presence domain as above. > > > > > It also means that the only information one can put in presence is > > information that can also be reflected into caller > > preferences. So, if, > > for example, I have a new presence status like activity, and > > I have two > > PCs, both equal, but I am at one, and not the other, so > that the ONLY > > difference is activity, this will mean we need to add a caller > > preferences "activity" feature parameter, and a client will > > need to keep > > it up to date. > Agree. Of course, I would say that we would need caller prefs only > so that the caller can manage to convince my incoming proxy to send > the call to the PC I am not at, since I would expect that normally, > a call to me would be forwarded to the PC I was at. Yes, the call is forwarded using the script as created by the proxy when it examined the presence info. The caller doesn't need to decide the PC, its the routing logic that needs to route the call to the right destination. The routing logic is in the network. Looking at Jonathan's earlier example: > Let me elaborate on your example. Lets say you've got a PC > and a phone. > You advertise one tuple for video (calls to which should get > routed to > the PC) and one for audio (calls to which get routed to both > the PC and > the phone). A watcher clicks on the "video" tuple. However, > by default, > their device does not ask for video streams - it uses an > audio stream in > the initial call setup, and adds video once the call > completes. If the > URI you use in both contacts is the same, how is the proxy to > know that > this call was for the PC alone? There is no video in the SDP. You, as a caller (and watcher), have a preference to use video. If your device asks for audio when you explicitly asked for a video call, then you need a new device, or you need your device to implement caller preferences. We have a mechanism to solve such a problem, caller preferences. Why invent a new one? Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 10 06:13:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04362 for ; Mon, 10 Feb 2003 06:13:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ABMEa08038 for simple-archive@odin.ietf.org; Mon, 10 Feb 2003 06:22:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ABMEp08035 for ; Mon, 10 Feb 2003 06:22:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04351 for ; Mon, 10 Feb 2003 06:13:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ABMAp08019; Mon, 10 Feb 2003 06:22:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ABLFp07998 for ; Mon, 10 Feb 2003 06:21:15 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04331 for ; Mon, 10 Feb 2003 06:12:21 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1ABEs212542 for ; Mon, 10 Feb 2003 13:14:54 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Feb 2003 13:16:02 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Feb 2003 13:16:02 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Feb 2003 13:16:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] PUBLISH: a dialog? Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7256@esebe019.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: a dialog? Thread-Index: AcLQYm4NtJz9KcVDRRi2Q6ffDoA9aQAgGIuwAASK/iA= To: , , Cc: , , , , X-OriginalArrivalTime: 10 Feb 2003 11:16:02.0320 (UTC) FILETIME=[CBB81900:01C2D0F5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1ABLFp07999 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Feb 2003 13:16:01 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I agree with what Aki's proposes. We purposefully rejected the use of MESSAGE within a dialog for various reasons including that; once you have established a dialog, a SIP message carries way too much information that it needs as a media protocol. The reasons apply here also. I personally don't have any strong opinions regarding a PUBLISH having to do with dialogs. But if it does, then I prefer for the PUBLISH to establish the dialog rather than using SIP yet again as another form of media protocol. If it will be INVITE to establish the publishing dialog, then, as Aki suggests, PIDF is the way to go, IMHO. Regards, Hisham > -----Original Message----- > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Monday, February 10, 2003 11:06 AM > To: akristensen@dynamicsoft.com; pkyzivat@cisco.com > Cc: seancolson@yahoo.com; jdrosen@dynamicsoft.com; Kiss Krisztian > (NRC/Tampere); jon.peterson@neustar.biz; simple@ietf.org > Subject: RE: [Simple] PUBLISH: a dialog? > > > Hi, > > Inline. > > > -----Original Message----- > > From: ext Anders Kristensen [mailto:akristensen@dynamicsoft.com] > > > > Paul Kyzivat wrote: > > > I agree that this is a reasonable approach. > > > > > > It does however open up some new issues that would need to > > be sorted out > > > - not a fundamental problem, just more work. Specifically, > > what should a > > > UAS do when receiving a "medialess" invitation? This > > probably depends on > > > the purpose of the invitation. In the case we are > > discussing the purpose > > > is simply to establish a dialog to carry PUBLISH messages, > > but it could > > > be preparatory to a reinvitation with media, or whatever. > > If the UAS > > > happens to be capable, should it alert? > > > > The intent to send PUBLISH'es over a dialog could be "negotiated" > > through an m= line of the sdp in the INVITE similar to what > > we're doing > > for session-mode MESSAGEs. > > We can also go down this path and forget PUBLISH altogether, > and use a PDIF-over-TCP media - just like we've done away > with MESSAGE in the message session work. > > It seems to me we're going around in circles here. Where are > the requirements driving this discussion? > > Cheers, > Aki > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 10 11:30:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14601 for ; Mon, 10 Feb 2003 11:30:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AGdDP26682 for simple-archive@odin.ietf.org; Mon, 10 Feb 2003 11:39:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AGdDp26679 for ; Mon, 10 Feb 2003 11:39:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14575 for ; Mon, 10 Feb 2003 11:30:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AGd9p26671; Mon, 10 Feb 2003 11:39:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AGcIp26612 for ; Mon, 10 Feb 2003 11:38:18 -0500 Received: from web41503.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14536 for ; Mon, 10 Feb 2003 11:29:18 -0500 (EST) Message-ID: <20030210163259.49214.qmail@web41503.mail.yahoo.com> Received: from [207.46.228.31] by web41503.mail.yahoo.com via HTTP; Mon, 10 Feb 2003 08:32:59 PST From: Sean Olson Subject: RE: [Simple] PUBLISH: a dialog? To: hisham.khartabil@nokia.com, aki.niemi@nokia.com, akristensen@dynamicsoft.com, pkyzivat@cisco.com Cc: seancolson@yahoo.com, jdrosen@dynamicsoft.com, krisztian.kiss@nokia.com, jon.peterson@neustar.biz, simple@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE7256@esebe019.ntc.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Feb 2003 08:32:59 -0800 (PST) There is a disconnect here. You can rightfully argue that MESSAGE is media in the context of a IM "session" (INVITE dialog). However, what I was proposing is something much different. I was proposing a signaling session established by an INVITE. In this case, what is being exchanged is literally SIP messages -- there is no simpler canonical form that can be transferred here such as CPIM/TCP. And unlike the CPIM case, what I am suggesting is that the PUBLISH request have all the same characteristics as the dialog within which it is established, including Call-ID, route set, etc. This is definitely not media. --- hisham.khartabil@nokia.com wrote: > I agree with what Aki's proposes. We purposefully > rejected the use of MESSAGE within a dialog for > various reasons including that; once you have > established a dialog, a SIP message carries way too > much information that it needs as a media protocol. > The reasons apply here also. > > I personally don't have any strong opinions > regarding a PUBLISH having to do with dialogs. But > if it does, then I prefer for the PUBLISH to > establish the dialog rather than using SIP yet again > as another form of media protocol. > > If it will be INVITE to establish the publishing > dialog, then, as Aki suggests, PIDF is the way to > go, IMHO. > > Regards, > Hisham > > > -----Original Message----- > > From: ext aki.niemi@nokia.com > [mailto:aki.niemi@nokia.com] > > Sent: Monday, February 10, 2003 11:06 AM > > To: akristensen@dynamicsoft.com; > pkyzivat@cisco.com > > Cc: seancolson@yahoo.com; jdrosen@dynamicsoft.com; > Kiss Krisztian > > (NRC/Tampere); jon.peterson@neustar.biz; > simple@ietf.org > > Subject: RE: [Simple] PUBLISH: a dialog? > > > > > > Hi, > > > > Inline. > > > > > -----Original Message----- > > > From: ext Anders Kristensen > [mailto:akristensen@dynamicsoft.com] > > > > > > Paul Kyzivat wrote: > > > > I agree that this is a reasonable approach. > > > > > > > > It does however open up some new issues that > would need to > > > be sorted out > > > > - not a fundamental problem, just more work. > Specifically, > > > what should a > > > > UAS do when receiving a "medialess" > invitation? This > > > probably depends on > > > > the purpose of the invitation. In the case we > are > > > discussing the purpose > > > > is simply to establish a dialog to carry > PUBLISH messages, > > > but it could > > > > be preparatory to a reinvitation with media, > or whatever. > > > If the UAS > > > > happens to be capable, should it alert? > > > > > > The intent to send PUBLISH'es over a dialog > could be "negotiated" > > > through an m= line of the sdp in the INVITE > similar to what > > > we're doing > > > for session-mode MESSAGEs. > > > > We can also go down this path and forget PUBLISH > altogether, > > and use a PDIF-over-TCP media - just like we've > done away > > with MESSAGE in the message session work. > > > > It seems to me we're going around in circles here. > Where are > > the requirements driving this discussion? > > > > Cheers, > > Aki > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 10 20:39:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04162 for ; Mon, 10 Feb 2003 20:39:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B1mI630243 for simple-archive@odin.ietf.org; Mon, 10 Feb 2003 20:48:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B1mIp30240 for ; Mon, 10 Feb 2003 20:48:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04152 for ; Mon, 10 Feb 2003 20:39:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B1mDp30228; Mon, 10 Feb 2003 20:48:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B1lIp30177 for ; Mon, 10 Feb 2003 20:47:18 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04134 for ; Mon, 10 Feb 2003 20:38:09 -0500 (EST) Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.243.26]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1B1feJR016393; Mon, 10 Feb 2003 20:41:41 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAZ48387; Mon, 10 Feb 2003 20:46:44 -0500 (EST) Message-ID: <3E4854D3.8090104@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: Brian.Rosen@marconi.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] RPIDS: Capabilities in tuples and Caller Prefs References: <2038BCC78B1AD641891A0D1AE133DBB7FE7253@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Feb 2003 20:41:39 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>Let me elaborate on your example. Lets say you've got a PC >>and a phone. >>You advertise one tuple for video (calls to which should get >>routed to >>the PC) and one for audio (calls to which get routed to both >>the PC and >>the phone). A watcher clicks on the "video" tuple. However, >>by default, >>their device does not ask for video streams - it uses an >>audio stream in >>the initial call setup, and adds video once the call >>completes. If the >>URI you use in both contacts is the same, how is the proxy to >>know that >>this call was for the PC alone? There is no video in the SDP. > > > You, as a caller (and watcher), have a preference to use video. If your device asks for audio when you explicitly asked for a video call, then you need a new device, or you need your device to implement caller preferences. > > We have a mechanism to solve such a problem, caller preferences. Why invent a new one? You as a caller and watcher know, in your head, that you want to communicate with a device that supports the characteristics described for the tuple you are viewing via your presence client. Your UAC is going to construct the invitation from the information in the tuple you have selected. (I doubt that you want to redundantly specify all the information presented there.) It will also perhaps use some information from your "command" to initiate this - perhaps something like "make voice call". Presumably the UAC will construct the To: address using the from the you selected. It *could* also construct callerprefs from the other contents of the tuple. It should be straightforward to do so from the rendition of the capabilities of the contact, if present. In general there is no good way to map any other capability that might be specified. This isn't guaranteed to get to any device corresponding to the tuple you selected, unless we make some rules so that it does. What Jonathan proposed was that the entry in the simplify this by providing some kind of guarantee that if I select a tuple, I will get to a device supporting the capabilities claimed in the description of that tuple. Seems reasonable to me. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 10 23:59:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08669 for ; Mon, 10 Feb 2003 23:59:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B58RR07655 for simple-archive@odin.ietf.org; Tue, 11 Feb 2003 00:08:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B58Rp07652 for ; Tue, 11 Feb 2003 00:08:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08662 for ; Mon, 10 Feb 2003 23:59:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B58Kp07644; Tue, 11 Feb 2003 00:08:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B57Zp07619 for ; Tue, 11 Feb 2003 00:07:35 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08651 for ; Mon, 10 Feb 2003 23:58:20 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1B525YH022322; Tue, 11 Feb 2003 00:02:06 -0500 (EST) Message-ID: <3E4883C8.90504@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, akristensen@dynamicsoft.com, pkyzivat@cisco.com, krisztian.kiss@nokia.com, jon.peterson@neustar.biz, simple@ietf.org Subject: Re: [Simple] PUBLISH: a dialog? References: <20030210163259.49214.qmail@web41503.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Feb 2003 00:02:01 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I still would propose to first define PUBLISH as a standalone method, like OPTIONS, which does its job. We can separately investigate setting up a signaling session if people are interested. But, that is a bigger more conentious topic that should not hold up the more pressing, simpler work. -Jonathan R> Sean Olson wrote: > There is a disconnect here. You can rightfully > argue that MESSAGE is media in the context of > a IM "session" (INVITE dialog). However, what I > was proposing is something much different. I was > proposing a signaling session established by an > INVITE. In this case, what is being exchanged is > literally SIP messages -- there is no simpler > canonical form that can be transferred here such > as CPIM/TCP. And unlike the CPIM case, what I > am suggesting is that the PUBLISH request have > all the same characteristics as the dialog within > which it is established, including Call-ID, route > set, etc. This is definitely not media. > > --- hisham.khartabil@nokia.com wrote: > >>I agree with what Aki's proposes. We purposefully >>rejected the use of MESSAGE within a dialog for >>various reasons including that; once you have >>established a dialog, a SIP message carries way too >>much information that it needs as a media protocol. >>The reasons apply here also. >> >>I personally don't have any strong opinions >>regarding a PUBLISH having to do with dialogs. But >>if it does, then I prefer for the PUBLISH to >>establish the dialog rather than using SIP yet again >>as another form of media protocol. >> >>If it will be INVITE to establish the publishing >>dialog, then, as Aki suggests, PIDF is the way to >>go, IMHO. >> >>Regards, >>Hisham >> >> >>>-----Original Message----- >>>From: ext aki.niemi@nokia.com >> >>[mailto:aki.niemi@nokia.com] >> >>>Sent: Monday, February 10, 2003 11:06 AM >>>To: akristensen@dynamicsoft.com; >> >>pkyzivat@cisco.com >> >>>Cc: seancolson@yahoo.com; jdrosen@dynamicsoft.com; >> >>Kiss Krisztian >> >>>(NRC/Tampere); jon.peterson@neustar.biz; >> >>simple@ietf.org >> >>>Subject: RE: [Simple] PUBLISH: a dialog? >>> >>> >>>Hi, >>> >>>Inline. >>> >>> >>>>-----Original Message----- >>>>From: ext Anders Kristensen >>> >>[mailto:akristensen@dynamicsoft.com] >> >>>>Paul Kyzivat wrote: >>>> >>>>>I agree that this is a reasonable approach. >>>>> >>>>>It does however open up some new issues that >>>> >>would need to >> >>>>be sorted out >>>> >>>>>- not a fundamental problem, just more work. >>>> >>Specifically, >> >>>>what should a >>>> >>>>>UAS do when receiving a "medialess" >>>> >>invitation? This >> >>>>probably depends on >>>> >>>>>the purpose of the invitation. In the case we >>>> >>are >> >>>>discussing the purpose >>>> >>>>>is simply to establish a dialog to carry >>>> >>PUBLISH messages, >> >>>>but it could >>>> >>>>>be preparatory to a reinvitation with media, >>>> >>or whatever. >> >>>>If the UAS >>>> >>>>>happens to be capable, should it alert? >>>> >>>>The intent to send PUBLISH'es over a dialog >>> >>could be "negotiated" >> >>>>through an m= line of the sdp in the INVITE >>> >>similar to what >> >>>>we're doing >>>>for session-mode MESSAGEs. >>> >>>We can also go down this path and forget PUBLISH >> >>altogether, >> >>>and use a PDIF-over-TCP media - just like we've >> >>done away >> >>>with MESSAGE in the message session work. >>> >>>It seems to me we're going around in circles here. >> >>Where are >> >>>the requirements driving this discussion? >>> >>>Cheers, >>>Aki >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Feb 11 01:58:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11568 for ; Tue, 11 Feb 2003 01:58:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B77Ei17424 for simple-archive@odin.ietf.org; Tue, 11 Feb 2003 02:07:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B77Ep17413 for ; Tue, 11 Feb 2003 02:07:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11545 for ; Tue, 11 Feb 2003 01:57:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B779p17265; Tue, 11 Feb 2003 02:07:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B76Xp16905 for ; Tue, 11 Feb 2003 02:06:33 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11524 for ; Tue, 11 Feb 2003 01:57:15 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1B70MC14435; Tue, 11 Feb 2003 07:00:22 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Feb 2003 02:00:44 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214DAF@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Sean Olson'" , hisham.khartabil@nokia.com, aki.niemi@nokia.com, akristensen@dynamicsoft.com, pkyzivat@cisco.com Cc: jdrosen@dynamicsoft.com, krisztian.kiss@nokia.com, simple@ietf.org Subject: RE: [Simple] PUBLISH: a dialog? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Feb 2003 02:00:38 -0500 A couple of comments here. Firstly, I agree with Sean that publish is not 'media'. Personally, I recognize an informal distinction between 'signaling' and 'media' (one that is perhaps grounded too much in traditional PSTN thinking), where things like SDP would count as signaling, whereas bearer (be it voice or instant messages) would count as media. However, I think we should not use SDP to set up sessions for exchanging signaling, and I think publication/notification definitely falls into the 'signaling' category. Second, I have a hard time justifying a 'medialess' dialog for PUBLISH. For some other methods, it may make sense to use a pre-existing dialog that was established for other purposes to send this sort of signaling information, but there really isn't any reason why such a pre-existing dialog should be established between a PUA and a compositor (subscribing to your own presence for this reason doesn't seem right to me - strictly, that's subscribing to the PA, not the compositor, and the two may not be composed). I am happy with Jonathan's suggestion that we pass over dialogs in silence for now. The question would then be, do we need the Stream header? Or would the tuple IDs in PIDF (and presumably a similar attribute in any other presence format) be sufficient to identify an atom of presence? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Monday, February 10, 2003 8:33 AM > To: hisham.khartabil@nokia.com; aki.niemi@nokia.com; > akristensen@dynamicsoft.com; pkyzivat@cisco.com > Cc: seancolson@yahoo.com; jdrosen@dynamicsoft.com; > krisztian.kiss@nokia.com; jon.peterson@neustar.biz; simple@ietf.org > Subject: RE: [Simple] PUBLISH: a dialog? > > > There is a disconnect here. You can rightfully > argue that MESSAGE is media in the context of > a IM "session" (INVITE dialog). However, what I > was proposing is something much different. I was > proposing a signaling session established by an > INVITE. In this case, what is being exchanged is > literally SIP messages -- there is no simpler > canonical form that can be transferred here such > as CPIM/TCP. And unlike the CPIM case, what I > am suggesting is that the PUBLISH request have > all the same characteristics as the dialog within > which it is established, including Call-ID, route > set, etc. This is definitely not media. > > --- hisham.khartabil@nokia.com wrote: > > I agree with what Aki's proposes. We purposefully > > rejected the use of MESSAGE within a dialog for > > various reasons including that; once you have > > established a dialog, a SIP message carries way too > > much information that it needs as a media protocol. > > The reasons apply here also. > > > > I personally don't have any strong opinions > > regarding a PUBLISH having to do with dialogs. But > > if it does, then I prefer for the PUBLISH to > > establish the dialog rather than using SIP yet again > > as another form of media protocol. > > > > If it will be INVITE to establish the publishing > > dialog, then, as Aki suggests, PIDF is the way to > > go, IMHO. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext aki.niemi@nokia.com > > [mailto:aki.niemi@nokia.com] > > > Sent: Monday, February 10, 2003 11:06 AM > > > To: akristensen@dynamicsoft.com; > > pkyzivat@cisco.com > > > Cc: seancolson@yahoo.com; jdrosen@dynamicsoft.com; > > Kiss Krisztian > > > (NRC/Tampere); jon.peterson@neustar.biz; > > simple@ietf.org > > > Subject: RE: [Simple] PUBLISH: a dialog? > > > > > > > > > Hi, > > > > > > Inline. > > > > > > > -----Original Message----- > > > > From: ext Anders Kristensen > > [mailto:akristensen@dynamicsoft.com] > > > > > > > > Paul Kyzivat wrote: > > > > > I agree that this is a reasonable approach. > > > > > > > > > > It does however open up some new issues that > > would need to > > > > be sorted out > > > > > - not a fundamental problem, just more work. > > Specifically, > > > > what should a > > > > > UAS do when receiving a "medialess" > > invitation? This > > > > probably depends on > > > > > the purpose of the invitation. In the case we > > are > > > > discussing the purpose > > > > > is simply to establish a dialog to carry > > PUBLISH messages, > > > > but it could > > > > > be preparatory to a reinvitation with media, > > or whatever. > > > > If the UAS > > > > > happens to be capable, should it alert? > > > > > > > > The intent to send PUBLISH'es over a dialog > > could be "negotiated" > > > > through an m= line of the sdp in the INVITE > > similar to what > > > > we're doing > > > > for session-mode MESSAGEs. > > > > > > We can also go down this path and forget PUBLISH > > altogether, > > > and use a PDIF-over-TCP media - just like we've > > done away > > > with MESSAGE in the message session work. > > > > > > It seems to me we're going around in circles here. > > Where are > > > the requirements driving this discussion? > > > > > > Cheers, > > > Aki > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Feb 11 04:04:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24199 for ; Tue, 11 Feb 2003 04:04:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B9DPU31418 for simple-archive@odin.ietf.org; Tue, 11 Feb 2003 04:13:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B9DPp31415 for ; Tue, 11 Feb 2003 04:13:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24186 for ; Tue, 11 Feb 2003 04:04:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B9DLp31406; Tue, 11 Feb 2003 04:13:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B9CZp31362 for ; Tue, 11 Feb 2003 04:12:35 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24138 for ; Tue, 11 Feb 2003 04:03:06 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1B99Ym15011 for ; Tue, 11 Feb 2003 11:09:34 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Feb 2003 11:06:47 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Feb 2003 11:06:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE725F@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RPIDS: Capabilities in tuples and Caller Prefs Thread-Index: AcLRbsOX5/8UOVmyTva1Ip3bMl2ARgAPVXlg To: Cc: , , X-OriginalArrivalTime: 11 Feb 2003 09:06:46.0989 (UTC) FILETIME=[E7983FD0:01C2D1AC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1B9CZp31363 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Feb 2003 11:06:46 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Its not up to the caller to dictate where the call should be routed, its up to the callee. The caller only presents a wish list called "caller preferences". If the callee has another device that matches those preferences, but its not the device that the tuple described, and the call is routed there, is there any wrong in that? We have to be careful with privacy issues here. I can publish all the caller prefs in , but I still reserve the right to have my AoR as the contact. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, February 11, 2003 3:42 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: Brian.Rosen@marconi.com; jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] RPIDS: Capabilities in tuples and Caller Prefs > > > > > hisham.khartabil@nokia.com wrote: > > > >>Let me elaborate on your example. Lets say you've got a PC > >>and a phone. > >>You advertise one tuple for video (calls to which should get > >>routed to > >>the PC) and one for audio (calls to which get routed to both > >>the PC and > >>the phone). A watcher clicks on the "video" tuple. However, > >>by default, > >>their device does not ask for video streams - it uses an > >>audio stream in > >>the initial call setup, and adds video once the call > >>completes. If the > >>URI you use in both contacts is the same, how is the proxy to > >>know that > >>this call was for the PC alone? There is no video in the SDP. > > > > > > You, as a caller (and watcher), have a preference to use > video. If your device asks for audio when you explicitly > asked for a video call, then you need a new device, or you > need your device to implement caller preferences. > > > > We have a mechanism to solve such a problem, caller > preferences. Why invent a new one? > > You as a caller and watcher know, in your head, that you want to > communicate with a device that supports the characteristics described > for the tuple you are viewing via your presence client. > > Your UAC is going to construct the invitation from the information in > the tuple you have selected. (I doubt that you want to redundantly > specify all the information presented there.) It will also > perhaps use > some information from your "command" to initiate this - perhaps > something like "make voice call". > > Presumably the UAC will construct the To: address using the > from the you selected. It *could* also construct callerprefs > from the other contents of the tuple. It should be > straightforward to do > so from the rendition of the capabilities of the > contact, if > present. In general there is no good way to map any other capability > that might be specified. > > This isn't guaranteed to get to any device corresponding to the tuple > you selected, unless we make some rules so that it does. > > What Jonathan proposed was that the entry in the > simplify this > by providing some kind of guarantee that if I select a tuple, > I will get > to a device supporting the capabilities claimed in the description of > that tuple. Seems reasonable to me. > > Paul > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Feb 11 04:16:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24387 for ; Tue, 11 Feb 2003 04:16:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B9P9831830 for simple-archive@odin.ietf.org; Tue, 11 Feb 2003 04:25:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B9P9p31827 for ; Tue, 11 Feb 2003 04:25:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24381 for ; Tue, 11 Feb 2003 04:15:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B9P5p31819; Tue, 11 Feb 2003 04:25:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B9Ofp31790 for ; Tue, 11 Feb 2003 04:24:41 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24361 for ; Tue, 11 Feb 2003 04:15:20 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1B9Lmm25531 for ; Tue, 11 Feb 2003 11:21:48 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Feb 2003 11:19:00 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Feb 2003 11:19:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] PUBLISH: a dialog? Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7260@esebe019.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: a dialog? Thread-Index: AcLRm0IF0VLaf58hRsmdUnrsVZ47AgAEjTgw To: , , , , Cc: , , X-OriginalArrivalTime: 11 Feb 2003 09:19:00.0066 (UTC) FILETIME=[9C8AEC20:01C2D1AE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1B9Ofp31791 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Feb 2003 11:18:59 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I am happy with Jonathan's suggestion as well. Regarding the Stream header vs. tuple-id; we need a mechanism that can handle crash recovery (just like the REGISTER*). If that logic can be performed on tuple-id, then lets use that, but if it can't, then we need a stream-header. *Extract from RFC3261 that I refer to: "If the binding does not exist, it is tentatively added. If the binding does exist, the registrar checks the Call-ID value. If the Call-ID value in the existing binding differs from the Call-ID value in the request, the binding MUST be removed if the expiration time is zero and updated otherwise. If they are the same, the registrar compares the CSeq value. If the value is higher than that of the existing binding, it MUST update or remove the binding as above. If not, the update MUST be aborted and the request fails." Regards, Hisham > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Tuesday, February 11, 2003 9:01 AM > To: 'Sean Olson'; Khartabil Hisham (NMP/Helsinki); Niemi Aki > (NMP/Helsinki); akristensen@dynamicsoft.com; pkyzivat@cisco.com > Cc: jdrosen@dynamicsoft.com; Kiss Krisztian (NRC/Tampere); > simple@ietf.org > Subject: RE: [Simple] PUBLISH: a dialog? > > > > A couple of comments here. > > Firstly, I agree with Sean that publish is not 'media'. Personally, I > recognize an informal distinction between 'signaling' and > 'media' (one that > is perhaps grounded too much in traditional PSTN thinking), > where things > like SDP would count as signaling, whereas bearer (be it > voice or instant > messages) would count as media. However, I think we should > not use SDP to > set up sessions for exchanging signaling, and I think > publication/notification definitely falls into the > 'signaling' category. > > Second, I have a hard time justifying a 'medialess' dialog > for PUBLISH. For > some other methods, it may make sense to use a pre-existing > dialog that was > established for other purposes to send this sort of signaling > information, > but there really isn't any reason why such a pre-existing > dialog should be > established between a PUA and a compositor (subscribing to > your own presence > for this reason doesn't seem right to me - strictly, that's > subscribing to > the PA, not the compositor, and the two may not be composed). > > I am happy with Jonathan's suggestion that we pass over > dialogs in silence > for now. The question would then be, do we need the Stream > header? Or would > the tuple IDs in PIDF (and presumably a similar attribute in any other > presence format) be sufficient to identify an atom of presence? > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Sean Olson [mailto:seancolson@yahoo.com] > > Sent: Monday, February 10, 2003 8:33 AM > > To: hisham.khartabil@nokia.com; aki.niemi@nokia.com; > > akristensen@dynamicsoft.com; pkyzivat@cisco.com > > Cc: seancolson@yahoo.com; jdrosen@dynamicsoft.com; > > krisztian.kiss@nokia.com; jon.peterson@neustar.biz; simple@ietf.org > > Subject: RE: [Simple] PUBLISH: a dialog? > > > > > > There is a disconnect here. You can rightfully > > argue that MESSAGE is media in the context of > > a IM "session" (INVITE dialog). However, what I > > was proposing is something much different. I was > > proposing a signaling session established by an > > INVITE. In this case, what is being exchanged is > > literally SIP messages -- there is no simpler > > canonical form that can be transferred here such > > as CPIM/TCP. And unlike the CPIM case, what I > > am suggesting is that the PUBLISH request have > > all the same characteristics as the dialog within > > which it is established, including Call-ID, route > > set, etc. This is definitely not media. > > > > --- hisham.khartabil@nokia.com wrote: > > > I agree with what Aki's proposes. We purposefully > > > rejected the use of MESSAGE within a dialog for > > > various reasons including that; once you have > > > established a dialog, a SIP message carries way too > > > much information that it needs as a media protocol. > > > The reasons apply here also. > > > > > > I personally don't have any strong opinions > > > regarding a PUBLISH having to do with dialogs. But > > > if it does, then I prefer for the PUBLISH to > > > establish the dialog rather than using SIP yet again > > > as another form of media protocol. > > > > > > If it will be INVITE to establish the publishing > > > dialog, then, as Aki suggests, PIDF is the way to > > > go, IMHO. > > > > > > Regards, > > > Hisham > > > > > > > -----Original Message----- > > > > From: ext aki.niemi@nokia.com > > > [mailto:aki.niemi@nokia.com] > > > > Sent: Monday, February 10, 2003 11:06 AM > > > > To: akristensen@dynamicsoft.com; > > > pkyzivat@cisco.com > > > > Cc: seancolson@yahoo.com; jdrosen@dynamicsoft.com; > > > Kiss Krisztian > > > > (NRC/Tampere); jon.peterson@neustar.biz; > > > simple@ietf.org > > > > Subject: RE: [Simple] PUBLISH: a dialog? > > > > > > > > > > > > Hi, > > > > > > > > Inline. > > > > > > > > > -----Original Message----- > > > > > From: ext Anders Kristensen > > > [mailto:akristensen@dynamicsoft.com] > > > > > > > > > > Paul Kyzivat wrote: > > > > > > I agree that this is a reasonable approach. > > > > > > > > > > > > It does however open up some new issues that > > > would need to > > > > > be sorted out > > > > > > - not a fundamental problem, just more work. > > > Specifically, > > > > > what should a > > > > > > UAS do when receiving a "medialess" > > > invitation? This > > > > > probably depends on > > > > > > the purpose of the invitation. In the case we > > > are > > > > > discussing the purpose > > > > > > is simply to establish a dialog to carry > > > PUBLISH messages, > > > > > but it could > > > > > > be preparatory to a reinvitation with media, > > > or whatever. > > > > > If the UAS > > > > > > happens to be capable, should it alert? > > > > > > > > > > The intent to send PUBLISH'es over a dialog > > > could be "negotiated" > > > > > through an m= line of the sdp in the INVITE > > > similar to what > > > > > we're doing > > > > > for session-mode MESSAGEs. > > > > > > > > We can also go down this path and forget PUBLISH > > > altogether, > > > > and use a PDIF-over-TCP media - just like we've > > > done away > > > > with MESSAGE in the message session work. > > > > > > > > It seems to me we're going around in circles here. > > > Where are > > > > the requirements driving this discussion? > > > > > > > > Cheers, > > > > Aki > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > > http://mailplus.yahoo.com > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Feb 11 11:31:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10406 for ; Tue, 11 Feb 2003 11:31:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BGeEp26907 for simple-archive@odin.ietf.org; Tue, 11 Feb 2003 11:40:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGeDp26904 for ; Tue, 11 Feb 2003 11:40:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10389 for ; Tue, 11 Feb 2003 11:30:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGe9p26896; Tue, 11 Feb 2003 11:40:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGdmp26838 for ; Tue, 11 Feb 2003 11:39:48 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10374 for ; Tue, 11 Feb 2003 11:30:18 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1BGanm22909 for ; Tue, 11 Feb 2003 18:36:49 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Feb 2003 18:34:00 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Feb 2003 18:34:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] PUBLISH: a dialog? Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD24C@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH: a dialog? Thread-Index: AcLRm0RALfpebeniTkC4kKtcx95IjAAEH1NQ To: , , , , Cc: , , X-OriginalArrivalTime: 11 Feb 2003 16:34:00.0821 (UTC) FILETIME=[61CE1250:01C2D1EB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1BGdmp26839 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Feb 2003 18:33:59 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi All, I do remember one or two occasions where terms "user-plane" and "control-plane" have come up - for obvious reasons. ;) Personally I think the distinction is not so easy or even useful to make, especially here. A presence document might sometimes resemble a web page more than a media description (particularly an SDP delivered offer-answer-style). I'm assuming there are other reasons why a "publish session" similar to CPIM/TCP is not a good idea? But I agree that Jonathan's proposal sounds reasonable. On whether to go with Stream or tuple id, I'd say tuple id. Crash recovery and sequencing aside, I think having a unique identifier for each published tuple has more value than having a unique identifier for each source of published tuples. Cheers, Aki > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > > A couple of comments here. > > Firstly, I agree with Sean that publish is not 'media'. Personally, I > recognize an informal distinction between 'signaling' and > 'media' (one that > is perhaps grounded too much in traditional PSTN thinking), > where things > like SDP would count as signaling, whereas bearer (be it > voice or instant > messages) would count as media. However, I think we should > not use SDP to > set up sessions for exchanging signaling, and I think > publication/notification definitely falls into the > 'signaling' category. > > Second, I have a hard time justifying a 'medialess' dialog > for PUBLISH. For > some other methods, it may make sense to use a pre-existing > dialog that was > established for other purposes to send this sort of signaling > information, > but there really isn't any reason why such a pre-existing > dialog should be > established between a PUA and a compositor (subscribing to > your own presence > for this reason doesn't seem right to me - strictly, that's > subscribing to > the PA, not the compositor, and the two may not be composed). > > I am happy with Jonathan's suggestion that we pass over > dialogs in silence > for now. The question would then be, do we need the Stream > header? Or would > the tuple IDs in PIDF (and presumably a similar attribute in any other > presence format) be sufficient to identify an atom of presence? > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Sean Olson [mailto:seancolson@yahoo.com] > > Sent: Monday, February 10, 2003 8:33 AM > > To: hisham.khartabil@nokia.com; aki.niemi@nokia.com; > > akristensen@dynamicsoft.com; pkyzivat@cisco.com > > Cc: seancolson@yahoo.com; jdrosen@dynamicsoft.com; > > krisztian.kiss@nokia.com; jon.peterson@neustar.biz; simple@ietf.org > > Subject: RE: [Simple] PUBLISH: a dialog? > > > > > > There is a disconnect here. You can rightfully > > argue that MESSAGE is media in the context of > > a IM "session" (INVITE dialog). However, what I > > was proposing is something much different. I was > > proposing a signaling session established by an > > INVITE. In this case, what is being exchanged is > > literally SIP messages -- there is no simpler > > canonical form that can be transferred here such > > as CPIM/TCP. And unlike the CPIM case, what I > > am suggesting is that the PUBLISH request have > > all the same characteristics as the dialog within > > which it is established, including Call-ID, route > > set, etc. This is definitely not media. > > > > --- hisham.khartabil@nokia.com wrote: > > > I agree with what Aki's proposes. We purposefully > > > rejected the use of MESSAGE within a dialog for > > > various reasons including that; once you have > > > established a dialog, a SIP message carries way too > > > much information that it needs as a media protocol. > > > The reasons apply here also. > > > > > > I personally don't have any strong opinions > > > regarding a PUBLISH having to do with dialogs. But > > > if it does, then I prefer for the PUBLISH to > > > establish the dialog rather than using SIP yet again > > > as another form of media protocol. > > > > > > If it will be INVITE to establish the publishing > > > dialog, then, as Aki suggests, PIDF is the way to > > > go, IMHO. > > > > > > Regards, > > > Hisham > > > > > > > -----Original Message----- > > > > From: ext aki.niemi@nokia.com > > > [mailto:aki.niemi@nokia.com] > > > > Sent: Monday, February 10, 2003 11:06 AM > > > > To: akristensen@dynamicsoft.com; > > > pkyzivat@cisco.com > > > > Cc: seancolson@yahoo.com; jdrosen@dynamicsoft.com; > > > Kiss Krisztian > > > > (NRC/Tampere); jon.peterson@neustar.biz; > > > simple@ietf.org > > > > Subject: RE: [Simple] PUBLISH: a dialog? > > > > > > > > > > > > Hi, > > > > > > > > Inline. > > > > > > > > > -----Original Message----- > > > > > From: ext Anders Kristensen > > > [mailto:akristensen@dynamicsoft.com] > > > > > > > > > > Paul Kyzivat wrote: > > > > > > I agree that this is a reasonable approach. > > > > > > > > > > > > It does however open up some new issues that > > > would need to > > > > > be sorted out > > > > > > - not a fundamental problem, just more work. > > > Specifically, > > > > > what should a > > > > > > UAS do when receiving a "medialess" > > > invitation? This > > > > > probably depends on > > > > > > the purpose of the invitation. In the case we > > > are > > > > > discussing the purpose > > > > > > is simply to establish a dialog to carry > > > PUBLISH messages, > > > > > but it could > > > > > > be preparatory to a reinvitation with media, > > > or whatever. > > > > > If the UAS > > > > > > happens to be capable, should it alert? > > > > > > > > > > The intent to send PUBLISH'es over a dialog > > > could be "negotiated" > > > > > through an m= line of the sdp in the INVITE > > > similar to what > > > > > we're doing > > > > > for session-mode MESSAGEs. > > > > > > > > We can also go down this path and forget PUBLISH > > > altogether, > > > > and use a PDIF-over-TCP media - just like we've > > > done away > > > > with MESSAGE in the message session work. > > > > > > > > It seems to me we're going around in circles here. > > > Where are > > > > the requirements driving this discussion? > > > > > > > > Cheers, > > > > Aki > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > > http://mailplus.yahoo.com > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Feb 11 15:28:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17727 for ; Tue, 11 Feb 2003 15:28:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BKbC910114 for simple-archive@odin.ietf.org; Tue, 11 Feb 2003 15:37:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BKbBp10103 for ; Tue, 11 Feb 2003 15:37:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17696 for ; Tue, 11 Feb 2003 15:27:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BKb7p09951; Tue, 11 Feb 2003 15:37:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BKaIp09704 for ; Tue, 11 Feb 2003 15:36:18 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17679 for ; Tue, 11 Feb 2003 15:26:45 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1BKUSC27438 for ; Tue, 11 Feb 2003 20:30:28 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Feb 2003 15:30:51 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214DBD@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "Simpletons (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] draft-ietf-simple-publish-reqs-00 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Feb 2003 15:30:45 -0500 Aki is quite right that having these conversations about PUBLISH in the absence of requirements is wrong-headed. The authors of the PUBLISH proposal have fielded out some of the sections relevant to framework, and added some requirements language, to the following separate draft. The requirements in this draft were also informed by recent email list discussion. Until it appears in the repository: http://www.unreason.com/jfp/ietf/draft-ietf-simple-publish-reqs-00.html Comments welcome. Jon Peterson Neustar, Inc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Feb 11 16:00:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18352 for ; Tue, 11 Feb 2003 16:00:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BL9DH12418 for simple-archive@odin.ietf.org; Tue, 11 Feb 2003 16:09:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BL9Dp12415 for ; Tue, 11 Feb 2003 16:09:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18311 for ; Tue, 11 Feb 2003 15:59:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BL98p12400; Tue, 11 Feb 2003 16:09:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BL8Wp12360 for ; Tue, 11 Feb 2003 16:08:32 -0500 Received: from nycsmtp3out.rdc-nyc.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18304 for ; Tue, 11 Feb 2003 15:58:53 -0500 (EST) Received: from BOBDEV (66-108-193-77.nyc.rr.com [66.108.193.77]) by nycsmtp3out.rdc-nyc.rr.com (8.12.1/Road Runner SMTP Server 1.0) with ESMTP id h1BL5cGn026364 for ; Tue, 11 Feb 2003 16:05:38 -0500 (EST) Reply-To: From: "Bob Wyman" To: Message-ID: <001901c2d210$ebb78da0$6401a8c0@BOBDEV> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1BL8Wp12361 Subject: [Simple] Microsoft patents: "Sally is typing a message now..." Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Feb 2003 16:02:43 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Today, Microsoft received a patent on "Activity Monitoring" for Instant Messaging systems. They claim messages such as: "Sally is typing a message now..." This patent will, inevitably, cause some difficulty for implementors of SIMPLE systems... See: (only the abstract is below. Read the claims, etc. at:) http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=6519639 United States Patent 6,519,639 Microsoft, February 11, 2003 ------------------------------------------------------------------------ -------- System and method for activity monitoring and reporting in a computer network Abstract A system for monitoring user activity in an instant messaging session on a computer network periodically sends an activity message to other participants in the instant messaging session if the user has actively entered data during a first predetermined time interval. The system periodically sends a new activity message at intervals corresponding to the first predetermined time interval so long as the user is actively entering data during each time interval. If the user has not entered data during the first predetermined time interval, the system will not send an activity message. Other participants in the instant messaging session receive the activity message and generate an activity indicator on their respective displays. The computer receiving the activity message displays an activity indicator on the computer display in response to receipt of an activity message and starts a timer to measure a second predetermined time interval. If another activity message is not received within the second predetermined time interval, the activity indicator is deleted from the display. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Feb 11 18:22:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21509 for ; Tue, 11 Feb 2003 18:22:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BNV8j20656 for simple-archive@odin.ietf.org; Tue, 11 Feb 2003 18:31:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BNV8p20653 for ; Tue, 11 Feb 2003 18:31:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21488 for ; Tue, 11 Feb 2003 18:21:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BNV4p20633; Tue, 11 Feb 2003 18:31:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BNU5p20564 for ; Tue, 11 Feb 2003 18:30:05 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21470 for ; Tue, 11 Feb 2003 18:20:28 -0500 (EST) Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.243.26]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1BNO3JR013204; Tue, 11 Feb 2003 18:24:03 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAZ56031; Tue, 11 Feb 2003 18:29:07 -0500 (EST) Message-ID: <3E498612.9080501@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: Brian.Rosen@marconi.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] RPIDS: Capabilities in tuples and Caller Prefs References: <2038BCC78B1AD641891A0D1AE133DBB7FE725F@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Feb 2003 18:24:02 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Its not up to the caller to dictate where the call should be routed, its up to the callee. The caller only presents a wish list called "caller preferences". If the callee has another device that matches those preferences, but its not the device that the tuple described, and the call is routed there, is there any wrong in that? That's not my point. My point is truth in advertising. If I pick a tuple based on what it advertises, and send a request to the corresponding contact, I expect to get to a device with characteristics consistent with what the tuple advertised. Based on discussion, there are open questions about this. Assume for the moment that all published contacts are sip addresses: 1) if I simply send an INVITE to the contact address from the tuple, without annotating my request in any way with my desired features, can I expect it to arrive at a device that has (or at least recently had) the features described in the tuple? 2) if (1) is false, can I achieve the intent by annotating the request in some well known way with information derived from the tuple? > We have to be careful with privacy issues here. I can publish all the caller prefs in , but I still reserve the right to have my AoR as the contact. I'm not arguing with that. (1) above can be achieved by the publisher appending sufficient callerprefs onto the AOR in the contact to select a suitable device. (2) can be achieved as long as all capabilities are represented as prescaps. Things that are represented by status other than prescaps presents a problem. If the presentity is showing two tuples, one with status and another with status , how can I ensure my call is directed to the one? If (1) is true then I can, because it is the publisher's problem to figure out how to tag the contact to achieve that end. Paul >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Tuesday, February 11, 2003 3:42 AM >>To: Khartabil Hisham (NMP/Helsinki) >>Cc: Brian.Rosen@marconi.com; jdrosen@dynamicsoft.com; simple@ietf.org >>Subject: Re: [Simple] RPIDS: Capabilities in tuples and Caller Prefs >> >> >> >> >>hisham.khartabil@nokia.com wrote: >> >>>>Let me elaborate on your example. Lets say you've got a PC >>>>and a phone. >>>>You advertise one tuple for video (calls to which should get >>>>routed to >>>>the PC) and one for audio (calls to which get routed to both >>>>the PC and >>>>the phone). A watcher clicks on the "video" tuple. However, >>>>by default, >>>>their device does not ask for video streams - it uses an >>>>audio stream in >>>>the initial call setup, and adds video once the call >>>>completes. If the >>>>URI you use in both contacts is the same, how is the proxy to >>>>know that >>>>this call was for the PC alone? There is no video in the SDP. >>> >>> >>>You, as a caller (and watcher), have a preference to use >> >>video. If your device asks for audio when you explicitly >>asked for a video call, then you need a new device, or you >>need your device to implement caller preferences. >> >>>We have a mechanism to solve such a problem, caller >> >>preferences. Why invent a new one? >> >>You as a caller and watcher know, in your head, that you want to >>communicate with a device that supports the characteristics described >>for the tuple you are viewing via your presence client. >> >>Your UAC is going to construct the invitation from the information in >>the tuple you have selected. (I doubt that you want to redundantly >>specify all the information presented there.) It will also >>perhaps use >>some information from your "command" to initiate this - perhaps >>something like "make voice call". >> >>Presumably the UAC will construct the To: address using the >>from the you selected. It *could* also construct callerprefs >>from the other contents of the tuple. It should be >>straightforward to do >>so from the rendition of the capabilities of the >>contact, if >>present. In general there is no good way to map any other capability >>that might be specified. >> >>This isn't guaranteed to get to any device corresponding to the tuple >>you selected, unless we make some rules so that it does. >> >>What Jonathan proposed was that the entry in the >>simplify this >>by providing some kind of guarantee that if I select a tuple, >>I will get >>to a device supporting the capabilities claimed in the description of >>that tuple. Seems reasonable to me. >> >> Paul >> >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Feb 11 23:25:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27984 for ; Tue, 11 Feb 2003 23:25:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C4YFu04941 for simple-archive@odin.ietf.org; Tue, 11 Feb 2003 23:34:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C4YFp04938 for ; Tue, 11 Feb 2003 23:34:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27980 for ; Tue, 11 Feb 2003 23:24:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C4YAp04927; Tue, 11 Feb 2003 23:34:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C4Xgp04913 for ; Tue, 11 Feb 2003 23:33:42 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27963 for ; Tue, 11 Feb 2003 23:23:58 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.152]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1C4RhYH023472; Tue, 11 Feb 2003 23:27:44 -0500 (EST) Message-ID: <3E49CD39.2080506@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: jon.peterson@neustar.biz, seancolson@yahoo.com, hisham.khartabil@nokia.com, akristensen@dynamicsoft.com, pkyzivat@cisco.com, krisztian.kiss@nokia.com, simple@ietf.org Subject: Re: [Simple] PUBLISH: a dialog? References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD24C@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Feb 2003 23:27:37 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One point on identifiers. We seem to be implicitly assuming that a tuple is the finest granularity of publication, and therefore a tuple ID will suffice. I can think of cases where I might want to publish an updated status for an existing tuple, without replacing the other statuses published elsewhere for that same tuple. If we use tuple id, we explicitly rule this out. Using tuple ID also means that PUBLISH is bound to PIDF, or at least, any such format used would need to have the notion of a tuple with a unique ID. I am not arguing against it, I just want to have all the facts on the table. -Jonathan R. aki.niemi@nokia.com wrote: > Hi All, > > I do remember one or two occasions where terms "user-plane" and "control-plane" have come up - for obvious reasons. ;) > > Personally I think the distinction is not so easy or even useful to make, especially here. A presence document might sometimes resemble a web page more than a media description (particularly an SDP delivered offer-answer-style). I'm assuming there are other reasons why a "publish session" similar to CPIM/TCP is not a good idea? > > But I agree that Jonathan's proposal sounds reasonable. On whether to go with Stream or tuple id, I'd say tuple id. Crash recovery and sequencing aside, I think having a unique identifier for each published tuple has more value than having a unique identifier for each source of published tuples. > > Cheers, > Aki > > >>-----Original Message----- >>From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] >> >>A couple of comments here. >> >>Firstly, I agree with Sean that publish is not 'media'. Personally, I >>recognize an informal distinction between 'signaling' and >>'media' (one that >>is perhaps grounded too much in traditional PSTN thinking), >>where things >>like SDP would count as signaling, whereas bearer (be it >>voice or instant >>messages) would count as media. However, I think we should >>not use SDP to >>set up sessions for exchanging signaling, and I think >>publication/notification definitely falls into the >>'signaling' category. >> >>Second, I have a hard time justifying a 'medialess' dialog >>for PUBLISH. For >>some other methods, it may make sense to use a pre-existing >>dialog that was >>established for other purposes to send this sort of signaling >>information, >>but there really isn't any reason why such a pre-existing >>dialog should be >>established between a PUA and a compositor (subscribing to >>your own presence >>for this reason doesn't seem right to me - strictly, that's >>subscribing to >>the PA, not the compositor, and the two may not be composed). >> >>I am happy with Jonathan's suggestion that we pass over >>dialogs in silence >>for now. The question would then be, do we need the Stream >>header? Or would >>the tuple IDs in PIDF (and presumably a similar attribute in any other >>presence format) be sufficient to identify an atom of presence? >> >>Jon Peterson >>NeuStar, Inc. >> >> >>>-----Original Message----- >>>From: Sean Olson [mailto:seancolson@yahoo.com] >>>Sent: Monday, February 10, 2003 8:33 AM >>>To: hisham.khartabil@nokia.com; aki.niemi@nokia.com; >>>akristensen@dynamicsoft.com; pkyzivat@cisco.com >>>Cc: seancolson@yahoo.com; jdrosen@dynamicsoft.com; >>>krisztian.kiss@nokia.com; jon.peterson@neustar.biz; simple@ietf.org >>>Subject: RE: [Simple] PUBLISH: a dialog? >>> >>> >>>There is a disconnect here. You can rightfully >>>argue that MESSAGE is media in the context of >>>a IM "session" (INVITE dialog). However, what I >>>was proposing is something much different. I was >>>proposing a signaling session established by an >>>INVITE. In this case, what is being exchanged is >>>literally SIP messages -- there is no simpler >>>canonical form that can be transferred here such >>>as CPIM/TCP. And unlike the CPIM case, what I >>>am suggesting is that the PUBLISH request have >>>all the same characteristics as the dialog within >>>which it is established, including Call-ID, route >>>set, etc. This is definitely not media. >>> >>>--- hisham.khartabil@nokia.com wrote: >>> >>>>I agree with what Aki's proposes. We purposefully >>>>rejected the use of MESSAGE within a dialog for >>>>various reasons including that; once you have >>>>established a dialog, a SIP message carries way too >>>>much information that it needs as a media protocol. >>>>The reasons apply here also. >>>> >>>>I personally don't have any strong opinions >>>>regarding a PUBLISH having to do with dialogs. But >>>>if it does, then I prefer for the PUBLISH to >>>>establish the dialog rather than using SIP yet again >>>>as another form of media protocol. >>>> >>>>If it will be INVITE to establish the publishing >>>>dialog, then, as Aki suggests, PIDF is the way to >>>>go, IMHO. >>>> >>>>Regards, >>>>Hisham >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext aki.niemi@nokia.com >>>> >>>>[mailto:aki.niemi@nokia.com] >>>> >>>>>Sent: Monday, February 10, 2003 11:06 AM >>>>>To: akristensen@dynamicsoft.com; >>>> >>>>pkyzivat@cisco.com >>>> >>>>>Cc: seancolson@yahoo.com; jdrosen@dynamicsoft.com; >>>> >>>>Kiss Krisztian >>>> >>>>>(NRC/Tampere); jon.peterson@neustar.biz; >>>> >>>>simple@ietf.org >>>> >>>>>Subject: RE: [Simple] PUBLISH: a dialog? >>>>> >>>>> >>>>>Hi, >>>>> >>>>>Inline. >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: ext Anders Kristensen >>>>> >>>>[mailto:akristensen@dynamicsoft.com] >>>> >>>>>>Paul Kyzivat wrote: >>>>>> >>>>>>>I agree that this is a reasonable approach. >>>>>>> >>>>>>>It does however open up some new issues that >>>>>> >>>>would need to >>>> >>>>>>be sorted out >>>>>> >>>>>>>- not a fundamental problem, just more work. >>>>>> >>>>Specifically, >>>> >>>>>>what should a >>>>>> >>>>>>>UAS do when receiving a "medialess" >>>>>> >>>>invitation? This >>>> >>>>>>probably depends on >>>>>> >>>>>>>the purpose of the invitation. In the case we >>>>>> >>>>are >>>> >>>>>>discussing the purpose >>>>>> >>>>>>>is simply to establish a dialog to carry >>>>>> >>>>PUBLISH messages, >>>> >>>>>>but it could >>>>>> >>>>>>>be preparatory to a reinvitation with media, >>>>>> >>>>or whatever. >>>> >>>>>>If the UAS >>>>>> >>>>>>>happens to be capable, should it alert? >>>>>> >>>>>>The intent to send PUBLISH'es over a dialog >>>>> >>>>could be "negotiated" >>>> >>>>>>through an m= line of the sdp in the INVITE >>>>> >>>>similar to what >>>> >>>>>>we're doing >>>>>>for session-mode MESSAGEs. >>>>> >>>>>We can also go down this path and forget PUBLISH >>>> >>>>altogether, >>>> >>>>>and use a PDIF-over-TCP media - just like we've >>>> >>>>done away >>>> >>>>>with MESSAGE in the message session work. >>>>> >>>>>It seems to me we're going around in circles here. >>>> >>>>Where are >>>> >>>>>the requirements driving this discussion? >>>>> >>>>>Cheers, >>>>>Aki >>>>> >>>>>_______________________________________________ >>>>>Simple mailing list >>>>>Simple@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>>__________________________________________________ >>>Do you Yahoo!? >>>Yahoo! Mail Plus - Powerful. Affordable. Sign up now. >>>http://mailplus.yahoo.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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 12 07:58:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01498 for ; Wed, 12 Feb 2003 07:58:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CD7PK13837 for simple-archive@odin.ietf.org; Wed, 12 Feb 2003 08:07:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CD7Op13834 for ; Wed, 12 Feb 2003 08:07:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01475 for ; Wed, 12 Feb 2003 07:57:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CD7Jp13733; Wed, 12 Feb 2003 08:07:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CD6wp13105 for ; Wed, 12 Feb 2003 08:06:58 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01434 for ; Wed, 12 Feb 2003 07:57:03 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA24378; Wed, 12 Feb 2003 08:00:46 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA17195; Wed, 12 Feb 2003 08:00:46 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Feb 2003 08:00:46 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5E28@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" , hisham.khartabil@nokia.com Cc: jdrosen@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Feb 2003 08:00:45 -0500 I think we are getting ourselves wrapped around the axle because we have two opposing views of how devices interact with presence. The viewpoint you and Jonathan seem to have is that there are multiple tuples in a presence document each describing one device. Since there is a contact address in the tuple, you want that contact address to get you to that device. I want a single object that represents one presentity. It gives you all the information the principal is willing to give that particular watcher about him. There is ONE contact address. In this object, I represent several possible devices. As I have said in the past, I really don't want to make devices explicit, but I am willing to compromise on that. What I care about is that normally, I don't give you a device address, I give you a single AoR that represents the Principal. If you want to influence how the call is routed to the Principal, who may indeed have multiple devices near him at any one time, use Caller Preferences to do that. The problem I have with one device per tuple is that I don't see how I get my preferred representation to work. The problem you have with one object (and one address) per Principal is you don't see how to address a device. We have to figure out what the middle ground is. I'm not objecting to having a way to provide a device address if the principal wishes to. I'm trying to figure out a way so that if the principal does NOT wish to provide device addresses, or even enumerate the devices he has, all watcher/UA implementations will work pretty well. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, February 11, 2003 6:24 PM > To: hisham.khartabil@nokia.com > Cc: Brian.Rosen@marconi.com; jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] RPIDS: Capabilities in tuples and Caller Prefs > > > > > hisham.khartabil@nokia.com wrote: > > Its not up to the caller to dictate where the call should > be routed, its up to the callee. The caller only presents a > wish list called "caller preferences". If the callee has > another device that matches those preferences, but its not > the device that the tuple described, and the call is routed > there, is there any wrong in that? > > That's not my point. My point is truth in advertising. If I > pick a tuple > based on what it advertises, and send a request to the corresponding > contact, I expect to get to a device with characteristics consistent > with what the tuple advertised. > > Based on discussion, there are open questions about this. > Assume for the > moment that all published contacts are sip addresses: > > 1) if I simply send an INVITE to the contact address from the tuple, > without annotating my request in any way with my desired > features, can I > expect it to arrive at a device that has (or at least > recently had) the > features described in the tuple? > > 2) if (1) is false, can I achieve the intent by annotating > the request > in some well known way with information derived from the tuple? > > > We have to be careful with privacy issues here. I can > publish all the caller prefs in , but I still > reserve the right to have my AoR as the contact. > > I'm not arguing with that. (1) above can be achieved by the publisher > appending sufficient callerprefs onto the AOR in the contact > to select a > suitable device. (2) can be achieved as long as all capabilities are > represented as prescaps. > > Things that are represented by status other than prescaps presents a > problem. If the presentity is showing two tuples, one with status > and another with status , how can I ensure my call is > directed to the one? If (1) is true then I can, because it is > the publisher's problem to figure out how to tag the contact > to achieve > that end. > > Paul > > >>-----Original Message----- > >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: Tuesday, February 11, 2003 3:42 AM > >>To: Khartabil Hisham (NMP/Helsinki) > >>Cc: Brian.Rosen@marconi.com; jdrosen@dynamicsoft.com; > simple@ietf.org > >>Subject: Re: [Simple] RPIDS: Capabilities in tuples and Caller Prefs > >> > >> > >> > >> > >>hisham.khartabil@nokia.com wrote: > >> > >>>>Let me elaborate on your example. Lets say you've got a PC > >>>>and a phone. > >>>>You advertise one tuple for video (calls to which should get > >>>>routed to > >>>>the PC) and one for audio (calls to which get routed to both > >>>>the PC and > >>>>the phone). A watcher clicks on the "video" tuple. However, > >>>>by default, > >>>>their device does not ask for video streams - it uses an > >>>>audio stream in > >>>>the initial call setup, and adds video once the call > >>>>completes. If the > >>>>URI you use in both contacts is the same, how is the proxy to > >>>>know that > >>>>this call was for the PC alone? There is no video in the SDP. > >>> > >>> > >>>You, as a caller (and watcher), have a preference to use > >> > >>video. If your device asks for audio when you explicitly > >>asked for a video call, then you need a new device, or you > >>need your device to implement caller preferences. > >> > >>>We have a mechanism to solve such a problem, caller > >> > >>preferences. Why invent a new one? > >> > >>You as a caller and watcher know, in your head, that you want to > >>communicate with a device that supports the characteristics > described > >>for the tuple you are viewing via your presence client. > >> > >>Your UAC is going to construct the invitation from the > information in > >>the tuple you have selected. (I doubt that you want to redundantly > >>specify all the information presented there.) It will also > >>perhaps use > >>some information from your "command" to initiate this - perhaps > >>something like "make voice call". > >> > >>Presumably the UAC will construct the To: address using the > > >>from the you selected. It *could* also construct > callerprefs > >>from the other contents of the tuple. It should be > >>straightforward to do > >>so from the rendition of the capabilities of the > >>contact, if > >>present. In general there is no good way to map any other > capability > >>that might be specified. > >> > >>This isn't guaranteed to get to any device corresponding to > the tuple > >>you selected, unless we make some rules so that it does. > >> > >>What Jonathan proposed was that the entry in the > >>simplify this > >>by providing some kind of guarantee that if I select a tuple, > >>I will get > >>to a device supporting the capabilities claimed in the > description of > >>that tuple. Seems reasonable to me. > >> > >> Paul > >> > >> > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 13 11:16:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16679 for ; Thu, 13 Feb 2003 11:16:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DGQma31810 for simple-archive@odin.ietf.org; Thu, 13 Feb 2003 11:26:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DGQmp31807 for ; Thu, 13 Feb 2003 11:26:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16663 for ; Thu, 13 Feb 2003 11:16:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DGQgp31797; Thu, 13 Feb 2003 11:26:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DGPsp31690 for ; Thu, 13 Feb 2003 11:25:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16634; Thu, 13 Feb 2003 11:15:26 -0500 (EST) Message-Id: <200302131615.LAA16634@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-publish-reqs-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Feb 2003 11:15:26 -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 : SIMPLE Presence Publication Requirements Author(s) : B. Campbell et al. Filename : draft-ietf-simple-publish-reqs-00.txt Pages : 11 Date : 2003-2-12 This document describes requirements for an extension to the Session Initiation Protocol (SIP) [1]. The purpose of this extension would be to create a means for publishing event state used within the framework for SIP Event Notification (RFC3265 [2]). The first application of this extension is targeted at the publication of presence information as defined by the SIMPLE [5] working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-publish-reqs-00.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-publish-reqs-00.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-publish-reqs-00.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: <2003-2-12075107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-publish-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-publish-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-12075107.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 13 16:20:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02103 for ; Thu, 13 Feb 2003 16:20:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DLO9b21318 for simple-archive@odin.ietf.org; Thu, 13 Feb 2003 16:24:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DLO9p21315 for ; Thu, 13 Feb 2003 16:24:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02000 for ; Thu, 13 Feb 2003 16:20:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DLO5p21303; Thu, 13 Feb 2003 16:24:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DLNMp21265 for ; Thu, 13 Feb 2003 16:23:22 -0500 Received: from verite.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01816 for ; Thu, 13 Feb 2003 16:19:31 -0500 (EST) Received: from localhost (verite.localdomain [127.0.0.1]) by verite.localdomain (8.12.5/8.12.5) with ESMTP id h1DKjLai002753; Thu, 13 Feb 2003 14:46:01 -0600 Subject: Re: [Simple] PUBLISH: a dialog? From: Ben Campbell To: Jonathan Rosenberg Cc: Anders Kristensen , Paul Kyzivat , Sean Olson , aki.niemi@nokia.com, krisztian.kiss@nokia.com, Jon Peterson , simple@ietf.org In-Reply-To: <3E47217B.2020207@dynamicsoft.com> References: <20030208181820.88180.qmail@web41507.mail.yahoo.com> <3E45A573.6090500@cisco.com> <3E46929E.3020205@dynamicsoft.com> <3E47217B.2020207@dynamicsoft.com> Content-Type: text/plain Message-Id: <1045169121.1196.104.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 13 Feb 2003 14:45:21 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sun, 2003-02-09 at 21:50, Jonathan Rosenberg wrote: > Anders Kristensen wrote: > I would prefer to decouple this from our deliverable. That is, I would > prefer to specify PUBLISH as not having anything to do with dialogs, and > separately, if we deem it necessary, work out what it means to use > INVITE to set up a publication session. > I agree enthusiastically. > > > > >> > >> Paul > >> > >> P.S. Describing this approach as "following the MESSAGE methodology" > >> is a bit of a misnomer. Establishing a dialog for the purpose of > >> creating a "message session" has been forbidden. > > > > > > OK, I wasn't aware of that. Where does it say that, actually? Seems a > > bit odd to me at first blush. > > It says it in rfc3428, section 2: Actually it says SHOULD NOT. So forbidden may be a bit strong of a term. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 13 19:02:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22068 for ; Thu, 13 Feb 2003 19:02:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1E06Gj31273 for simple-archive@odin.ietf.org; Thu, 13 Feb 2003 19:06:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E06Gp31270 for ; Thu, 13 Feb 2003 19:06:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21987 for ; Thu, 13 Feb 2003 19:02:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E069p31261; Thu, 13 Feb 2003 19:06:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E05kp31226 for ; Thu, 13 Feb 2003 19:05:46 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21906 for ; Thu, 13 Feb 2003 19:01:52 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1E04QC12074; Fri, 14 Feb 2003 00:04:26 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Feb 2003 19:04:52 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214DD1@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" , aki.niemi@nokia.com Cc: seancolson@yahoo.com, hisham.khartabil@nokia.com, akristensen@dynamicsoft.com, pkyzivat@cisco.com, krisztian.kiss@nokia.com, simple@ietf.org Subject: RE: [Simple] PUBLISH: a dialog? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Feb 2003 19:04:49 -0500 I think that any presence format that can be worked by a compositor needs to have a concept of an atomic segment of presence. For PIDF, the tuple seems like the easiest and most intuitive thing on which a compositor would act. Perhaps if finer granularity and controls are needed for different elements in a tuple, that status could instead be split across multiple tuples by the publisher. This also doesn't mean that non-standard implementations of compositors might not peer inside tuples and mutate their contents. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, February 11, 2003 8:28 PM > To: aki.niemi@nokia.com > Cc: jon.peterson@neustar.biz; seancolson@yahoo.com; > hisham.khartabil@nokia.com; akristensen@dynamicsoft.com; > pkyzivat@cisco.com; krisztian.kiss@nokia.com; simple@ietf.org > Subject: Re: [Simple] PUBLISH: a dialog? > > > One point on identifiers. > > We seem to be implicitly assuming that a tuple is the finest > granularity > of publication, and therefore a tuple ID will suffice. I can think of > cases where I might want to publish an updated status for an existing > tuple, without replacing the other statuses published > elsewhere for that > same tuple. If we use tuple id, we explicitly rule this out. > > Using tuple ID also means that PUBLISH is bound to PIDF, or at least, > any such format used would need to have the notion of a tuple with a > unique ID. > > I am not arguing against it, I just want to have all the > facts on the table. > > -Jonathan R. > > > aki.niemi@nokia.com wrote: > > Hi All, > > > > I do remember one or two occasions where terms "user-plane" > and "control-plane" have come up - for obvious reasons. ;) > > > > Personally I think the distinction is not so easy or even > useful to make, especially here. A presence document might > sometimes resemble a web page more than a media description > (particularly an SDP delivered offer-answer-style). I'm > assuming there are other reasons why a "publish session" > similar to CPIM/TCP is not a good idea? > > > > But I agree that Jonathan's proposal sounds reasonable. On > whether to go with Stream or tuple id, I'd say tuple id. > Crash recovery and sequencing aside, I think having a unique > identifier for each published tuple has more value than > having a unique identifier for each source of published tuples. > > > > Cheers, > > Aki > > > > > >>-----Original Message----- > >>From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > >> > >>A couple of comments here. > >> > >>Firstly, I agree with Sean that publish is not 'media'. > Personally, I > >>recognize an informal distinction between 'signaling' and > >>'media' (one that > >>is perhaps grounded too much in traditional PSTN thinking), > >>where things > >>like SDP would count as signaling, whereas bearer (be it > >>voice or instant > >>messages) would count as media. However, I think we should > >>not use SDP to > >>set up sessions for exchanging signaling, and I think > >>publication/notification definitely falls into the > >>'signaling' category. > >> > >>Second, I have a hard time justifying a 'medialess' dialog > >>for PUBLISH. For > >>some other methods, it may make sense to use a pre-existing > >>dialog that was > >>established for other purposes to send this sort of signaling > >>information, > >>but there really isn't any reason why such a pre-existing > >>dialog should be > >>established between a PUA and a compositor (subscribing to > >>your own presence > >>for this reason doesn't seem right to me - strictly, that's > >>subscribing to > >>the PA, not the compositor, and the two may not be composed). > >> > >>I am happy with Jonathan's suggestion that we pass over > >>dialogs in silence > >>for now. The question would then be, do we need the Stream > >>header? Or would > >>the tuple IDs in PIDF (and presumably a similar attribute > in any other > >>presence format) be sufficient to identify an atom of presence? > >> > >>Jon Peterson > >>NeuStar, Inc. > >> > >> > >>>-----Original Message----- > >>>From: Sean Olson [mailto:seancolson@yahoo.com] > >>>Sent: Monday, February 10, 2003 8:33 AM > >>>To: hisham.khartabil@nokia.com; aki.niemi@nokia.com; > >>>akristensen@dynamicsoft.com; pkyzivat@cisco.com > >>>Cc: seancolson@yahoo.com; jdrosen@dynamicsoft.com; > >>>krisztian.kiss@nokia.com; jon.peterson@neustar.biz; simple@ietf.org > >>>Subject: RE: [Simple] PUBLISH: a dialog? > >>> > >>> > >>>There is a disconnect here. You can rightfully > >>>argue that MESSAGE is media in the context of > >>>a IM "session" (INVITE dialog). However, what I > >>>was proposing is something much different. I was > >>>proposing a signaling session established by an > >>>INVITE. In this case, what is being exchanged is > >>>literally SIP messages -- there is no simpler > >>>canonical form that can be transferred here such > >>>as CPIM/TCP. And unlike the CPIM case, what I > >>>am suggesting is that the PUBLISH request have > >>>all the same characteristics as the dialog within > >>>which it is established, including Call-ID, route > >>>set, etc. This is definitely not media. > >>> > >>>--- hisham.khartabil@nokia.com wrote: > >>> > >>>>I agree with what Aki's proposes. We purposefully > >>>>rejected the use of MESSAGE within a dialog for > >>>>various reasons including that; once you have > >>>>established a dialog, a SIP message carries way too > >>>>much information that it needs as a media protocol. > >>>>The reasons apply here also. > >>>> > >>>>I personally don't have any strong opinions > >>>>regarding a PUBLISH having to do with dialogs. But > >>>>if it does, then I prefer for the PUBLISH to > >>>>establish the dialog rather than using SIP yet again > >>>>as another form of media protocol. > >>>> > >>>>If it will be INVITE to establish the publishing > >>>>dialog, then, as Aki suggests, PIDF is the way to > >>>>go, IMHO. > >>>> > >>>>Regards, > >>>>Hisham > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: ext aki.niemi@nokia.com > >>>> > >>>>[mailto:aki.niemi@nokia.com] > >>>> > >>>>>Sent: Monday, February 10, 2003 11:06 AM > >>>>>To: akristensen@dynamicsoft.com; > >>>> > >>>>pkyzivat@cisco.com > >>>> > >>>>>Cc: seancolson@yahoo.com; jdrosen@dynamicsoft.com; > >>>> > >>>>Kiss Krisztian > >>>> > >>>>>(NRC/Tampere); jon.peterson@neustar.biz; > >>>> > >>>>simple@ietf.org > >>>> > >>>>>Subject: RE: [Simple] PUBLISH: a dialog? > >>>>> > >>>>> > >>>>>Hi, > >>>>> > >>>>>Inline. > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: ext Anders Kristensen > >>>>> > >>>>[mailto:akristensen@dynamicsoft.com] > >>>> > >>>>>>Paul Kyzivat wrote: > >>>>>> > >>>>>>>I agree that this is a reasonable approach. > >>>>>>> > >>>>>>>It does however open up some new issues that > >>>>>> > >>>>would need to > >>>> > >>>>>>be sorted out > >>>>>> > >>>>>>>- not a fundamental problem, just more work. > >>>>>> > >>>>Specifically, > >>>> > >>>>>>what should a > >>>>>> > >>>>>>>UAS do when receiving a "medialess" > >>>>>> > >>>>invitation? This > >>>> > >>>>>>probably depends on > >>>>>> > >>>>>>>the purpose of the invitation. In the case we > >>>>>> > >>>>are > >>>> > >>>>>>discussing the purpose > >>>>>> > >>>>>>>is simply to establish a dialog to carry > >>>>>> > >>>>PUBLISH messages, > >>>> > >>>>>>but it could > >>>>>> > >>>>>>>be preparatory to a reinvitation with media, > >>>>>> > >>>>or whatever. > >>>> > >>>>>>If the UAS > >>>>>> > >>>>>>>happens to be capable, should it alert? > >>>>>> > >>>>>>The intent to send PUBLISH'es over a dialog > >>>>> > >>>>could be "negotiated" > >>>> > >>>>>>through an m= line of the sdp in the INVITE > >>>>> > >>>>similar to what > >>>> > >>>>>>we're doing > >>>>>>for session-mode MESSAGEs. > >>>>> > >>>>>We can also go down this path and forget PUBLISH > >>>> > >>>>altogether, > >>>> > >>>>>and use a PDIF-over-TCP media - just like we've > >>>> > >>>>done away > >>>> > >>>>>with MESSAGE in the message session work. > >>>>> > >>>>>It seems to me we're going around in circles here. > >>>> > >>>>Where are > >>>> > >>>>>the requirements driving this discussion? > >>>>> > >>>>>Cheers, > >>>>>Aki > >>>>> > >>>>>_______________________________________________ > >>>>>Simple mailing list > >>>>>Simple@ietf.org > >>>>>https://www1.ietf.org/mailman/listinfo/simple > >>>>> > >>>> > >>>>_______________________________________________ > >>>>Simple mailing list > >>>>Simple@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >>>__________________________________________________ > >>>Do you Yahoo!? > >>>Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > >>>http://mailplus.yahoo.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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 13 19:17:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23875 for ; Thu, 13 Feb 2003 19:17:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1E0LAP32595 for simple-archive@odin.ietf.org; Thu, 13 Feb 2003 19:21:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E0LAp32592 for ; Thu, 13 Feb 2003 19:21:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23867 for ; Thu, 13 Feb 2003 19:17:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E0L6p32571; Thu, 13 Feb 2003 19:21:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E0KEp32532 for ; Thu, 13 Feb 2003 19:20:14 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23845 for ; Thu, 13 Feb 2003 19:16:21 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1E0K5C12271 for ; Fri, 14 Feb 2003 00:20:05 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Feb 2003 19:20:31 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214DD2@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "Simpletons (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] PUBLISH: Facet header needed? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Feb 2003 19:20:30 -0500 It has been argued that the Facet header of the PUBLISH method is superfluous. Facet describes "the intended destination or grouping of event state from the publishers point of view" in order to allow the compositor to apply per-destination policies to published presence information. However, the Data Manipulation Requirements draft also (draft-ietf-simple-data-req) outlines a mechanism for establishing user policies about what information various subscribers should receive. So Facet provides a similar service, and it has been argued that the only real difference is that Facet specifies these policies at publication time. Anyone feel strongly that we need Facet? Jon Peterson NeuStar, Inc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 14 00:49:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01062 for ; Fri, 14 Feb 2003 00:49:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1E5qT018415 for simple-archive@odin.ietf.org; Fri, 14 Feb 2003 00:52:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E5qTp18412 for ; Fri, 14 Feb 2003 00:52:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01006 for ; Fri, 14 Feb 2003 00:48:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E5qNp18404; Fri, 14 Feb 2003 00:52:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E5pkp18370 for ; Fri, 14 Feb 2003 00:51:46 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00996 for ; Fri, 14 Feb 2003 00:47:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.139]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1E5pYYH025276; Fri, 14 Feb 2003 00:51:34 -0500 (EST) Message-ID: <3E4C83DF.3020101@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "Simpletons (E-mail)" Subject: Re: [Simple] PUBLISH: Facet header needed? References: <15A2739B7DAA624D8091C65981D7DA8101214DD2@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Feb 2003 00:51:27 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think it should go. -Jonathan R. Peterson, Jon wrote: > It has been argued that the Facet header of the PUBLISH method is > superfluous. Facet describes "the intended destination or grouping of event > state from the publishers point of view" in order to allow the compositor to > apply per-destination policies to published presence information. However, > the Data Manipulation Requirements draft also (draft-ietf-simple-data-req) > outlines a mechanism for establishing user policies about what information > various subscribers should receive. So Facet provides a similar service, and > it has been argued that the only real difference is that Facet specifies > these policies at publication time. > > Anyone feel strongly that we need Facet? > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 14 05:33:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15648 for ; Fri, 14 Feb 2003 05:33:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EAbGb14424 for simple-archive@odin.ietf.org; Fri, 14 Feb 2003 05:37:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EAbGp14421 for ; Fri, 14 Feb 2003 05:37:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15645 for ; Fri, 14 Feb 2003 05:33:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EAbCp14301; Fri, 14 Feb 2003 05:37:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EAZDp13897 for ; Fri, 14 Feb 2003 05:35:13 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15622 for ; Fri, 14 Feb 2003 05:31:06 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1EAbhm07798 for ; Fri, 14 Feb 2003 12:37:43 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Feb 2003 12:34:51 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Feb 2003 12:34:50 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 14 Feb 2003 12:34:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] PUBLISH: Facet header needed? Message-ID: Thread-Topic: [Simple] PUBLISH: Facet header needed? Thread-Index: AcLTvwrCLR4bWbUHTkOJZKoQIdmjlwAVKr/A To: , X-OriginalArrivalTime: 14 Feb 2003 10:34:49.0687 (UTC) FILETIME=[B3913E70:01C2D414] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1EAZDp13898 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Feb 2003 12:34:49 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I think the policies should be preferably managed using the Data Manipulation mechanisms. The need for Facet type of header can only be known after the DM solution has been clarified, but at least I don't see specific need for it at the moment. However, the requirement expressed in the draft 18. The presence publication architecture must support a means for principals to authorize the disclosure of segments of presence information to particular watchers. is still valid, at least as long as the DM solution is not finalized. Markus > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 14 February, 2003 02:21 > To: Simpletons (E-mail) > Subject: [Simple] PUBLISH: Facet header needed? > > > > It has been argued that the Facet header of the PUBLISH method is > superfluous. Facet describes "the intended destination or > grouping of event > state from the publishers point of view" in order to allow > the compositor to > apply per-destination policies to published presence > information. However, > the Data Manipulation Requirements draft also > (draft-ietf-simple-data-req) > outlines a mechanism for establishing user policies about > what information > various subscribers should receive. So Facet provides a > similar service, and > it has been argued that the only real difference is that > Facet specifies > these policies at publication time. > > Anyone feel strongly that we need Facet? > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Feb 16 23:44:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04568 for ; Sun, 16 Feb 2003 23:44:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1H4nOb18182 for simple-archive@odin.ietf.org; Sun, 16 Feb 2003 23:49:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H4nOp18179 for ; Sun, 16 Feb 2003 23:49:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04533 for ; Sun, 16 Feb 2003 23:43:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H4nJp18167; Sun, 16 Feb 2003 23:49:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H4gSp18009 for ; Sun, 16 Feb 2003 23:42:28 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04452 for ; Sun, 16 Feb 2003 23:37:01 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1H4eoYH026491; Sun, 16 Feb 2003 23:40:50 -0500 (EST) Message-ID: <3E5067CD.9040307@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: aki.niemi@nokia.com, seancolson@yahoo.com, hisham.khartabil@nokia.com, akristensen@dynamicsoft.com, pkyzivat@cisco.com, krisztian.kiss@nokia.com, simple@ietf.org Subject: Re: [Simple] PUBLISH: a dialog? References: <15A2739B7DAA624D8091C65981D7DA8101214DD1@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 16 Feb 2003 23:40:45 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Peterson, Jon wrote: > I think that any presence format that can be worked by a compositor needs to > have a concept of an atomic segment of presence. For PIDF, the tuple seems > like the easiest and most intuitive thing on which a compositor would act. > Perhaps if finer granularity and controls are needed for different > elements in a tuple, that status could instead be split across multiple > tuples by the publisher. That depends on the semantic of what a tuple represents, I suppose, which we are also sorting out. -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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 17 17:27:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02850 for ; Mon, 17 Feb 2003 17:27:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HMWL428562 for simple-archive@odin.ietf.org; Mon, 17 Feb 2003 17:32:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HMWLp28559 for ; Mon, 17 Feb 2003 17:32:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02840 for ; Mon, 17 Feb 2003 17:26:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HMWGp28551; Mon, 17 Feb 2003 17:32:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HMVjp28528 for ; Mon, 17 Feb 2003 17:31:45 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02835 for ; Mon, 17 Feb 2003 17:25:57 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h1HMRwJX002937 for ; Mon, 17 Feb 2003 17:27:58 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <1WPB3AWV>; Mon, 17 Feb 2003 16:29:44 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A644DF@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] New event lists draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Feb 2003 16:29:40 -0600 I just submitted a new version of the event lists draft. Based on the discussions we had in Atlanta, this draft has been heavily modified. Of primary interest are the facts that it no longer defines a template event package, and that it now allows arbitrary nesting of lists. Until it becomes available in the i-d repository, you can retrieve a copy from: An HTML version is available at: /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Feb 18 12:00:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01912 for ; Tue, 18 Feb 2003 12:00:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1IH5lv08981 for simple-archive@odin.ietf.org; Tue, 18 Feb 2003 12:05:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IH5kp08978 for ; Tue, 18 Feb 2003 12:05:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01860 for ; Tue, 18 Feb 2003 11:59:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IH5fp08969; Tue, 18 Feb 2003 12:05:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IGpTp07980 for ; Tue, 18 Feb 2003 11:51:29 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01686 for ; Tue, 18 Feb 2003 11:45:18 -0500 (EST) From: Tim.Moran@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1IGnBO22893 for ; Tue, 18 Feb 2003 10:49:11 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 18 Feb 2003 10:49:04 -0600 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Feb 2003 10:48:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <278B6B0D76698D45BBA872CD23DD496A674692@daebe004.americas.nokia.com> Thread-Topic: Notification Rate limiting - how many solutions and where? Thread-Index: AcLXbYE6s+/zzfBVQBODEwxqc//M+g== To: X-OriginalArrivalTime: 18 Feb 2003 16:48:05.0131 (UTC) FILETIME=[81F1CDB0:01C2D76D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1IGpTp07981 Subject: [Simple] Notification Rate limiting - how many solutions and where? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Feb 2003 10:48:03 -0600 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Greetings, Regarding notification filtering and the requirement to limit the frequency of notifications, a couple of solutions are available. Below are a few such proposals with some pros/cons. Your feedback is appreciated. A case for rate limiting in the SIP header This idea is to create a new parameter which specifies the rate limit in a SIP SUBSCRIBE request header or possibly a new header. * can be used for any sip request method other than Subscribe * is package independent so no need to put into content part of request * simple text implementation * others? A case for rate limiting in the Content (body of Subscribe) This idea is to create a rule specifying the rate limit in a SIP SUBSCRIBE request body. * permits explicit definition of rules involving rate limiting and other trigger criteria such as value reached -> easier debugging & understandability * may be used for any package if no package specific rules are used * other generic criteria besides time (time since last notification), such as location, can be done using same constructs * permits easier inter-working with other Presence & Instant Messaging systems that do not use SIP * others? A case for both rate limiting solutions. * ??? Tim Moran _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 19 12:11:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01746 for ; Wed, 19 Feb 2003 12:11:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JHHIT27509 for simple-archive@odin.ietf.org; Wed, 19 Feb 2003 12:17:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JHHIp27506 for ; Wed, 19 Feb 2003 12:17:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01735 for ; Wed, 19 Feb 2003 12:10:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JHGqp27465; Wed, 19 Feb 2003 12:16:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGwhp25629 for ; Wed, 19 Feb 2003 11:58:43 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01284 for ; Wed, 19 Feb 2003 11:52:01 -0500 (EST) From: Tim.Moran@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1JGtqO10969 for ; Wed, 19 Feb 2003 10:55:52 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Feb 2003 10:55:40 -0600 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 10:55:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <278B6B0D76698D45BBA872CD23DD496A67469F@daebe004.americas.nokia.com> Thread-Index: AcLYN7f5TWZY0ltVTyin+ZnKcySTnQ== To: Cc: X-OriginalArrivalTime: 19 Feb 2003 16:55:35.0549 (UTC) FILETIME=[B8D3E2D0:01C2D837] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JGwhp25630 Subject: [Simple] (no subject) Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Feb 2003 10:55:34 -0600 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jonathan, I wanted to respond to this email of yours from the Jan 14th SIMPLE WG email archive. Not doubt this has reached the moratorium on responding to questions, but I think it is still relevant. In the context below, you mention that there is little in common btw packages regarding filtering. I tend to disagree from the architecture perspective. As even you mention, there are common constructs such as 'or' and 'and' and such for doing logical tests. This is in fact common across packages and content such as XML. What is unique are the objects (Package elements). They are not that unique however in that for the case of XML content they are strings and hierarchical (structured). Here is where I think existing tools such as XPATH can help provide a common filtering architecture - but it is not the total solution alone. As for the objects, these are defined by the package. I agree however, that there may be some objects not defined in the package. Should they be? Some are generic such as time and location (standard definitions exist for describing location). Others are known only to the server such as statistical information. In the case of winfo this may be # of active watchers, for example. How to deal with these must be addressed commonly - or uniquely. Regarding separation of triggering and filtering, perhaps they can be combined and do not require separate constructs. Point is both are required. Focusing on the triggering, you provide examples where it would appear a notification is sent wherein multiple watchers having reached a certain state or have experienced some event are sent. This requires what I would call a batching mechanism whether it be time based or spatial. You describe that implementations are doing proprietary solutions but we need a standard mechanism (IMHO) wherein the client may specify and know precisely what the bathcing mechanism is. Otherwise, whenever a state change occurs (say for watcher x) only watcher x info will be sent. If the package rule is changed to say all watchers with feature y, then the entire list is sent whenever any one of them changes and this is not good. Some examples - only send periodically, only send when a threshold (e.g. quorum #, majority, 2 or more, etc) is reached. For another application/package, it might be to only send when location has significantly changed. In short, I personally don't care so much as to how we do triggering as long as we enable the capability. Applications should be able to take the architetcure and apply the relevant pieces (i.e. instantiate it). This follows the same ideas ( I think) that Adam had with Subscribe/Notify, Packages and sub-packages. Regards, Tim Moran To: krisztian.kiss@nokia.com Subject: Re: [Simple] Content filtering for winfo From: Jonathan Rosenberg > Date: Tue, 14 Jan 2003 15:03:21 -0500 Cc: simple@ietf.org krisztian.kiss@nokia.com wrote: > All, > > During IETF55's SIPPING session it was discussed how to proceed with > the content filtering work. It was concluded that SIMPLE WG will > produce event specific content filtering for the presence package > (requirements & solution). I am wondering whether this work also > covers content filtering for the winfo template-package. If yes, it > is also a question whether this issue should be addressed separately > from the presence package (in different documents) or together with > it. I believe its a separate problem. The conclusion was, as I recall, that there is very little that is common across packages in terms of filters. Thus, we will develop, in sipping, a specific solution just for rate limiting, and then each particular package would get its own filter type. So, I believe there is a filter needed for winfo. Most implementations I am aware of, in fact, are already filtering on winfo - they just want the list of pending subscribers. So, here are the set of things I would like to be able to specify in the filter language: * include only watchers in a specific state [i.e., give me only pending watchers] * include only watchers that transitioned from a specific state to another state [i.e., only watchers that just transitioned from active to terminated] * include only watchers from a particular domain [who are the watchers from my enterprise?] * include only watchers who have been in a specified state for less than some duration [useful to only ask for the watcher whose state JUST went to pending because they just subscribed] * include only the Nth through Mth watcher, assuming some ordering can be applied to them at the server [useful for fetching a long list of your watchers - you can ask for ten at a time] Doing this in XML is easy, I think. You could specify a set of filters, eahc of which is an XML tag. There are filters for states, filters for domains, filters for duration, and so on. Filters nest, creating an AND rule. Sequences of filters create OR rules. So, if you want the set of watchers from either dynamicsoft.com or from microsoft.com: and to specify watchers that just transitioned to pending, who are from dynamicsoft.com: The processing rule at the server is easy. Start with all watchers at the root of the XML tree. Each node (element) specifies a reduction operation to be applied. Apply it, and take the remaining elements as input to the next tags. The union of the watchers that remain at the leaves of the XML tree represent the set which is to be sent in the notify. Note that, in the terminology proposed by Moran, the filter above does not separate content and trigger criteria. The model is that at each event transition, there is a set of watchers that would be present in the notify. THe filter is applied. If any watchers remain, a notification is sent. If none remain, none is sent. Certainly there are things you cannot do as a result (send me all the watchers whenever one watcher transitions from active to terminated). Not sure we are missing any important cases. Comments? -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 PHONE: (973) 952-5000 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 19 19:46:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14197 for ; Wed, 19 Feb 2003 19:46:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K0rGj22917 for simple-archive@odin.ietf.org; Wed, 19 Feb 2003 19:53:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K0rGp22914 for ; Wed, 19 Feb 2003 19:53:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14194 for ; Wed, 19 Feb 2003 19:46:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K0rCp22903; Wed, 19 Feb 2003 19:53:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K0qVp22883 for ; Wed, 19 Feb 2003 19:52:31 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14188 for ; Wed, 19 Feb 2003 19:45:41 -0500 (EST) Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.243.26]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1K0nMJR014101; Wed, 19 Feb 2003 19:49:23 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id ABA00141; Wed, 19 Feb 2003 19:54:28 -0500 (EST) Message-ID: <3E542612.9090708@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] RPIDS: Capabilities in tuples and Caller Prefs References: <313680C9A886D511A06000204840E1CF030B5E28@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Feb 2003 19:49:22 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, sorry to be so long in responding. I have been preoccupied with other things. Comments inline. Paul Rosen, Brian wrote: > I think we are getting ourselves wrapped around the axle > because we have two opposing views of how devices interact > with presence. I agree that this is the problem. I think the problem goes away if we permit both usages to coexist. > The viewpoint you and Jonathan seem to have is that there > are multiple tuples in a presence document each describing > one device. Since there is a contact address in the tuple, > you want that contact address to get you to that device. > > I want a single object that represents one presentity. > It gives you all the information the principal is willing > to give that particular watcher about him. There is ONE > contact address. In this object, I represent several > possible devices. As I have said in the past, I really > don't want to make devices explicit, but I am willing > to compromise on that. What I care about is that normally, > I don't give you a device address, I give you a single > AoR that represents the Principal. If you want to influence > how the call is routed to the Principal, who may indeed > have multiple devices near him at any one time, use > Caller Preferences to do that. > > The problem I have with one device per tuple is that I > don't see how I get my preferred representation to work. For your preferred representation, you don't use one device per tuple. Instead you simply use one tuple, with the AOR as the contact address. This is a usage that you, as a presentity, negotiate with your presence server to publish. > The problem you have with one object (and one address) > per Principal is you don't see how to address a device. We just choose to use multiple tuples, with multiple addresses. > We have to figure out what the middle ground is. I think the actual problem, if any, is with the client. It is the server that gets to decide which of these models it wishes to use. The client must accomodate. For us it is not a problem - you only publish one tuple, so to us it is just a single virtual device. I don't know if this is a problem to you or not. Clients need to be prepared to present information about multiple tuples to their users, and preferably provide the user with suitable courses of action on a per-tuple basis. This is more work than if there is but a single tuple. But I can think of some concise and convenient GUI interfaces for this. > I'm not objecting to having a way to provide a device > address if the principal wishes to. I'm trying to > figure out a way so that if the principal does NOT > wish to provide device addresses, or even enumerate > the devices he has, all watcher/UA implementations will > work pretty well. Where is the problem? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 20 07:45:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09923 for ; Thu, 20 Feb 2003 07:45:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KCqFa09353 for simple-archive@odin.ietf.org; Thu, 20 Feb 2003 07:52:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KCqFp09350 for ; Thu, 20 Feb 2003 07:52:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09881 for ; Thu, 20 Feb 2003 07:45:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KCqAp09308; Thu, 20 Feb 2003 07:52:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KCjIp08970 for ; Thu, 20 Feb 2003 07:45:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09481; Thu, 20 Feb 2003 07:38:14 -0500 (EST) Message-Id: <200302201238.HAA09481@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-event-list-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Feb 2003 07:38:14 -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 : A Session Initiation Protocol (SIP) Event Notification Extension for Collections Author(s) : A. Roach, J. Rosenberg, B. Campbell Filename : draft-ietf-simple-event-list-00.txt Pages : 38 Date : 2003-2-19 This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogenous collection of event packages. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire collection, and then receive notifications when the state of any of the resources in the collection changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-00.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-event-list-00.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-event-list-00.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: <2003-2-19142323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-event-list-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-event-list-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19142323.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 20 07:58:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11082 for ; Thu, 20 Feb 2003 07:58:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KD5B410222 for simple-archive@odin.ietf.org; Thu, 20 Feb 2003 08:05:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KD5Bp10219 for ; Thu, 20 Feb 2003 08:05:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11037 for ; Thu, 20 Feb 2003 07:58:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KD55p10206; Thu, 20 Feb 2003 08:05:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KD49p10181 for ; Thu, 20 Feb 2003 08:04:09 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10922 for ; Thu, 20 Feb 2003 07:57:03 -0500 (EST) From: krisztian.kiss@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1KD3bm00422 for ; Thu, 20 Feb 2003 15:03:37 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Feb 2003 15:00:36 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 15:00:35 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 15:00:35 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 15:00:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLSDKmlBETglUm8T1qFajlCU2CqBwGMD7DQ To: , X-OriginalArrivalTime: 20 Feb 2003 13:00:35.0278 (UTC) FILETIME=[0ED306E0:01C2D8E0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1KD49p10182 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Feb 2003 15:00:34 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jon et al, I certainly welcome this document, especially section 3. Please find some comments first concerning the actual requirements: - REQ12 and REQ14 define the need for unique identifiers of segments. I would prefer to see further clarifications related to these requirements concerning the issue which entity (PUA or compositor) assigns the identifiers and based on what. Even if it seems to be obvious that in case of carrying PIDF in the PUBLISH request, the invention of tuple ids is the PUA's responsibility. Having unique segment/tuple ids inside the presentity is the key to detect collisions from multiple PUAs. Related to the collision situation, I have a further comment: - Assuming publishing partial or incremental presence information (as written in REQ10), there is also a need for the PUA to indicate whether it wants to overwrite existing segment or only add additional attributes to it. Based on this indication from the PUA, the compositor could decide to extend or replace the old segment with the newly published one, or reject the publication. - REQ14 states that a PUA must be able to query the identifiers of all of the segments. Assuming the above described segment extension functionality, there would be also a need to query the actual content of the segments, so that the PUA could decide which operation (segment extension or segment overwrite) to perform. - Concerning partial publication (REQ10), there is also a need for the PUA to explicitly indicate if it intends to remove a certain segment from the presence information. - REQ6 defines the need to order publishing sequences. Isn't there also a need for unique identification of PUAs? Concerning section 1, some synchronization would be needed with section 3, as e.g. section 1 states that: "each publication carries full state, and does not depend on previous states for the particular PUA. A PUA does not need to know whether or not other PUAs are also publishing presence information to the compositor" while section 3 states: "there should also be a way for PUAs to send partial or incremental presence information" (REQ10); "The publication mechanism must support a means for a presence compositor to compose presence information received from multiple PUAs at different times into a single presence document." (REQ8) Regards, Krisztian > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Tuesday, February 11, 2003 10:31 PM > To: Simpletons (E-mail) > Subject: [Simple] draft-ietf-simple-publish-reqs-00 > > > > Aki is quite right that having these conversations about > PUBLISH in the > absence of requirements is wrong-headed. > > The authors of the PUBLISH proposal have fielded out some of > the sections > relevant to framework, and added some requirements language, to the > following separate draft. The requirements in this draft were > also informed > by recent email list discussion. Until it appears in the repository: > > http://www.unreason.com/jfp/ietf/draft-ietf-simple-publish-req s-00.html Comments welcome. Jon Peterson Neustar, Inc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 20 11:42:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20678 for ; Thu, 20 Feb 2003 11:42:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KGmlr27492 for simple-archive@odin.ietf.org; Thu, 20 Feb 2003 11:48:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGmlp27489 for ; Thu, 20 Feb 2003 11:48:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20611 for ; Thu, 20 Feb 2003 11:41:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGmgp27479; Thu, 20 Feb 2003 11:48:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGlip27374 for ; Thu, 20 Feb 2003 11:47:44 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20542 for ; Thu, 20 Feb 2003 11:40:33 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10791; Thu, 20 Feb 2003 11:44:22 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA20451; Thu, 20 Feb 2003 11:44:23 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Feb 2003 11:44:23 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5E86@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Feb 2003 11:44:17 -0500 I'm glad we got back to this, as I really want to get closure. .... snip.... > I think the actual problem, if any, is with the client. It is > the server > that gets to decide which of these models it wishes to use. > The client > must accomodate. > > For us it is not a problem - you only publish one tuple, so > to us it is > just a single virtual device. Well, your client has to use caller preferences to influence what happens to the call, if he wants to do that. If we don't make that work well, and clients won't implement it, we won't have good interoperability. > > I don't know if this is a problem to you or not. Clients need to be > prepared to present information about multiple tuples to their users, > and preferably provide the user with suitable courses of action on a > per-tuple basis. This is more work than if there is but a > single tuple. > But I can think of some concise and convenient GUI interfaces > for this It would be interesting to do some useability studies on this. > > > I'm not objecting to having a way to provide a device > > address if the principal wishes to. I'm trying to > > figure out a way so that if the principal does NOT > > wish to provide device addresses, or even enumerate > > the devices he has, all watcher/UA implementations will > > work pretty well. > > Where is the problem? Making the syntax of the (RPIDS) presence document and the syntax of caller preferences match enough to make influencing outcome obvious. Making the representation of data in one tuple rich enough to express the state of a presentity instead of the state of a device. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 20 12:59:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23108 for ; Thu, 20 Feb 2003 12:59:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KI5t601431 for simple-archive@odin.ietf.org; Thu, 20 Feb 2003 13:05:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KI5tp01428 for ; Thu, 20 Feb 2003 13:05:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23078 for ; Thu, 20 Feb 2003 12:58:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KI5pp01420; Thu, 20 Feb 2003 13:05:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KI4Lp01356 for ; Thu, 20 Feb 2003 13:04:21 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23067 for ; Thu, 20 Feb 2003 12:57:09 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1KI0vi24704; Thu, 20 Feb 2003 13:00:57 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA07451; Thu, 20 Feb 2003 12:00:52 -0600 (CST) Message-ID: <3E55179B.6090601@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Paul Kyzivat'" , hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] RPIDS: Capabilities in tuples and Caller Prefs References: <313680C9A886D511A06000204840E1CF030B5E86@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Feb 2003 11:59:55 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: [...] >>I don't know if this is a problem to you or not. Clients need to be >>prepared to present information about multiple tuples to their users, >>and preferably provide the user with suitable courses of action on a >>per-tuple basis. This is more work than if there is but a >>single tuple. >>But I can think of some concise and convenient GUI interfaces >>for this > > It would be interesting to do some useability studies on this. We did something along these lines in early 2001. There was an internal Bell Labs project called TeamPortal [1] that did use-ability studies and deployment on such a presence-based system. The model in TeamPortal was presentity-based with each presentity being represented by a myriad of devices that a watcher could use to initiate communication. In the TeamPortal GUI, a set of icons to the right of a presentity's icon represented each such device at the presentity's disposal. Each such device included information such as the last used time and current status. The presence status of the presentities was also tied into calendaring systems and such. The intent was to keep a globally disperesed team in a cohesive collaboratory by providing presence and communication means to other watchers in the collaboration. [1] "Advanced Services: Changing how we communicate", R. Colbert, D. Compton, R. Hackbarth, J. Herbsleb, L. Hoadley, and G. Willis, Bell Labs Technical Journal, Volume 6, No 1, January-June 2001, pp 211-228. (Email me if you cannot find the article online some- where. The authors of TeamPortal also generated some usage statistics which are relevant for a collaboration-type of setup.) Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 20 18:07:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02888 for ; Thu, 20 Feb 2003 18:07:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KNEB524792 for simple-archive@odin.ietf.org; Thu, 20 Feb 2003 18:14:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KNEBp24789 for ; Thu, 20 Feb 2003 18:14:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02885 for ; Thu, 20 Feb 2003 18:06:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KNE6p24780; Thu, 20 Feb 2003 18:14:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KNDSp24747 for ; Thu, 20 Feb 2003 18:13:28 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02876 for ; Thu, 20 Feb 2003 18:06:09 -0500 (EST) Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.243.26]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1KN9qNh015507; Thu, 20 Feb 2003 18:09:53 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id ABA07652; Thu, 20 Feb 2003 18:14:58 -0500 (EST) Message-ID: <3E556040.8090903@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] RPIDS: Capabilities in tuples and Caller Prefs References: <313680C9A886D511A06000204840E1CF030B5E86@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Feb 2003 18:09:52 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > >>I think the actual problem, if any, is with the client. It is >>the server >>that gets to decide which of these models it wishes to use. >>The client >>must accomodate. >> >>For us it is not a problem - you only publish one tuple, so >>to us it is >>just a single virtual device. > > Well, your client has to use caller preferences to influence > what happens to the call, if he wants to do that. If we don't > make that work well, and clients won't implement it, > we won't have good interoperability. The use of callerprefs is more optional in this case, because there is only one visible contact. If that happens to be an AOR for multiple devices, then presumably a call will be forked, and something will happen that is consistent with the expectations promised by the presence document. Problems occur when there are multiple tuples in the document that repeat the same contact but describe different features. This is when callerprefs (or something else) are required to ensure that a call directed to the contact with expectation of the features promised in that tuple. In your case there are some ambiguities that could be resolved via callerprefs. For instance suppose you have one phone for business calls and another for personal calls, both registered to your AOR. Using your approach, the compositor would have to decide how to represent the combined status of the AOR. Publishing this as a single tuple is a bit deceiving, because you presumably report the equivalent of class="business,personal". A client might read this and think it can call without specifying any preferences and reach something suitable for either or both. But in fact that isn't what calling without specifying a preference means in this case. You have broken the appearance that this is one device. I suppose we could try to add some guidelines indicating that a caller should explicitly request all the offered preferences that are actually desired. But you *know* it won't happen, because it is too hard. Instead, people are simply going to click on an icon corresponding to the contact, and a call will be made. There won't be any easy way to cause the preferences to be added in this case. >>Where is the problem? > > Making the syntax of the (RPIDS) presence document and > the syntax of caller preferences match enough to make > influencing outcome obvious. > > Making the representation of data in one tuple rich enough > to express the state of a presentity instead of the state > of a device. I think by the time you have achieved that, you will have simply ened up exposing the existence of the individual devices in a more obscure way. It is a caller feature to be able to pick among the tuples and get a device with the corresponding features, without having to explicitly request each feature. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 20 19:25:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04679 for ; Thu, 20 Feb 2003 19:25:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1L0WA429307 for simple-archive@odin.ietf.org; Thu, 20 Feb 2003 19:32:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L0WAp29304 for ; Thu, 20 Feb 2003 19:32:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04675 for ; Thu, 20 Feb 2003 19:24:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L0W6p29294; Thu, 20 Feb 2003 19:32:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L0Vkp29276 for ; Thu, 20 Feb 2003 19:31:46 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04671 for ; Thu, 20 Feb 2003 19:24:21 -0500 (EST) Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.243.26]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1L0S5JR028423; Thu, 20 Feb 2003 19:28:06 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id ABA08050; Thu, 20 Feb 2003 19:33:11 -0500 (EST) Message-ID: <3E557294.8060500@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'simple@ietf.org'" Subject: Re: [Simple] New event lists draft References: <9BF66EBF6BEFD942915B4D4D45C051F3A644DF@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Feb 2003 19:28:04 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In section 3.2 (Event Header Parameters) the wording implies that the id= parameter will be passed thru to subscriptions for elements in a list. But this is probably a bad thing. The purpose of the id is to disambiguate different subscriptions in the same dialog. There will be a dialog between the original subscriber and the event list server, and there will probably be several dialogs between the event list server and the servers for the list elements. But I don't think there is any implication that there is specific relationship between these dialogs. Without that, an event id in one may be inappropriate in another. Shouldn't the event list server have the option to decide when or if to associate event ids with the subscriptions it generates? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 21 09:51:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01805 for ; Fri, 21 Feb 2003 09:51:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LEw6627890 for simple-archive@odin.ietf.org; Fri, 21 Feb 2003 09:58:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEw6p27887 for ; Fri, 21 Feb 2003 09:58:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01777 for ; Fri, 21 Feb 2003 09:50:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEw1p27879; Fri, 21 Feb 2003 09:58:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEsZp27763 for ; Fri, 21 Feb 2003 09:54:35 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01705 for ; Fri, 21 Feb 2003 09:46:58 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1LErnm29349 for ; Fri, 21 Feb 2003 16:53:49 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Feb 2003 16:50:47 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Feb 2003 16:50:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLSDKmlBETglUm8T1qFajlCU2CqBwGMD7DQAF0EuDA= To: , , X-OriginalArrivalTime: 21 Feb 2003 14:50:47.0793 (UTC) FILETIME=[9E9A7E10:01C2D9B8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1LEsZp27764 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Feb 2003 16:50:47 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I have some further comments on the publish requirements: My concern is the hard vs. soft state nature of the published information. The initial SIP PUBLISH based solution seemed to borrow its model (Expires header) from REGISTER. For REGISTER it seems clear that soft state is beneficial, since if the UA crashes, the registrar would like to get rid of the state, since that state is no longer valid. However, presence information contains both hard state and soft state components. You would like to maintain some (relatively) persistent version of parts of your presence data, even if you have no PUAs connected to the network, and which you would very seldom update. This kind of information contains for instance your e-mail contact or web page URL. This seems to call for a hard state model, or a soft state with very long expiration (i.e., infinity). Definitely there are some soft state looking information as well, such as tuples which are valid only as long as the PUA is running, e.g. for IM or voice status. For this kind of information there is some benefit in getting automatically rid of it, if the PUA crashes. The minimum that seems to be needed is an expiration time associated separately for each segment of the published data. With this approach there is still one issue with one PUA overwriting the information set by the other: If the overwritten data has shorter expiry time than the original data, what should happen if the overwritten data expires? In other words, would the overwrite be a replace or a "stack push" operation. In the latter case if the published information expires, it will just "pop out of the stack" and reveal the previous value. Another point of view that people have expressed is that everything should be hard state. Watcher can evaluate the correctness of the state based on how long about it was published. Any refresh mechanism would only update this "timestamp", but a failure to refresh would not cause the data to disappear. (My opinion is that the requirements for PUBLISH clearly point that what actually would be needed is an RPC mechanism (such as SOAP) on top of SIP. Both routing provided by SIP and manipulation operations provided by an RPC protocol are needed. But I know that this is banned in SIP for some reasons (which leaves us with no such protocol in the Internet...), so I'm happy to try with the current way.) Regards, Markus > -----Original Message----- > From: ext krisztian.kiss@nokia.com [mailto:krisztian.kiss@nokia.com] > Sent: 20 February, 2003 15:01 > To: jon.peterson@neustar.biz; simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > Jon et al, > > I certainly welcome this document, especially section 3. > Please find some comments first concerning the actual requirements: > > - REQ12 and REQ14 define the need for unique identifiers of > segments. I would prefer to see further clarifications > related to these requirements concerning the issue which > entity (PUA or compositor) assigns the identifiers and based > on what. Even if it seems to be obvious that in case of > carrying PIDF in the PUBLISH request, the invention of tuple > ids is the PUA's responsibility. Having unique segment/tuple > ids inside the presentity is the key to detect collisions > from multiple PUAs. Related to the collision situation, I > have a further comment: > > - Assuming publishing partial or incremental presence > information (as written in REQ10), there is also a need for > the PUA to indicate whether it wants to overwrite existing > segment or only add additional attributes to it. Based on > this indication from the PUA, the compositor could decide to > extend or replace the old segment with the newly published > one, or reject the publication. > > - REQ14 states that a PUA must be able to query the > identifiers of all of the segments. Assuming the above > described segment extension functionality, there would be > also a need to query the actual content of the segments, so > that the PUA could decide which operation (segment > extension or segment overwrite) to perform. > > - Concerning partial publication (REQ10), there is also a > need for the PUA to explicitly indicate if it intends to > remove a certain segment from the presence information. > > - REQ6 defines the need to order publishing sequences. Isn't > there also a need for unique identification of PUAs? > > Concerning section 1, some synchronization would be needed > with section 3, as e.g. section 1 states that: > "each publication carries full state, and does not depend on > previous states for the particular PUA. A PUA does not need > to know whether or not other PUAs are also publishing > presence information to the compositor" > > while section 3 states: > "there should also be a way for PUAs to send partial or > incremental presence information" (REQ10); "The publication > mechanism must support a means for a presence compositor to > compose presence information received from multiple PUAs at > different times into a single presence document." (REQ8) > > Regards, > Krisztian > > > > -----Original Message----- > > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Tuesday, February 11, 2003 10:31 PM > > To: Simpletons (E-mail) > > Subject: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > > > Aki is quite right that having these conversations about > > PUBLISH in the > > absence of requirements is wrong-headed. > > > > The authors of the PUBLISH proposal have fielded out some of > > the sections > > relevant to framework, and added some requirements language, to the > > following separate draft. The requirements in this draft were > > also informed > > by recent email list discussion. Until it appears in the repository: > > > > http://www.unreason.com/jfp/ietf/draft-ietf-simple-publish-req > s-00.html > > Comments welcome. > > Jon Peterson > Neustar, Inc. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 21 18:45:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18621 for ; Fri, 21 Feb 2003 18:45:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LNqKV31116 for simple-archive@odin.ietf.org; Fri, 21 Feb 2003 18:52:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LNqKp31113 for ; Fri, 21 Feb 2003 18:52:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18579 for ; Fri, 21 Feb 2003 18:44:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LNqFp31102; Fri, 21 Feb 2003 18:52:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LNpWp31062 for ; Fri, 21 Feb 2003 18:51:32 -0500 Received: from oe-im1.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18563 for ; Fri, 21 Feb 2003 18:43:44 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030221234736.PXIZ1186.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Fri, 21 Feb 2003 17:47:36 -0600 Received: from diacakist ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030221234736.VVKC5684.oe-ismta1.bizmailsrvcs.net@diacakist>; Fri, 21 Feb 2003 17:47:36 -0600 Message-ID: <028a01c2da03$a5478500$45071e0a@myopwv.com> From: "Thanos Diacakis" To: "Henning Schulzrinne" , References: <3E40355F.1060503@cs.columbia.edu> Subject: Re: [Simple] RPIDS: extensions to PIDF MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Feb 2003 16:47:26 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning, Section 4, "Groups of Presentities" is not very clear to me. For example, how is the "status of a group as a whole" defined? Is that an aggregation of the presence documents of all the members? The 4 types listed seem to be combinations of some characteristics such as: - granularity of notifications (all members, individual members) - triggering of notifications - full/delta notifications Are there any more that are missing? Can we express those cases in terms of some more basic features? Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: "Henning Schulzrinne" To: Sent: Tuesday, February 04, 2003 2:49 PM Subject: [Simple] RPIDS: extensions to PIDF > Based on the discussion on this list, we prepared an initial draft to > provide a possible approach. Until it appears in the official archives, > the draft can be found at > > http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-simple-rpids-00.pdf > http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-simple-rpids-00.txt > > Comments are appreciated. > > Henning > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 21 22:21:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22411 for ; Fri, 21 Feb 2003 22:21:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1M3TCK09293 for simple-archive@odin.ietf.org; Fri, 21 Feb 2003 22:29:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M3TCp09290 for ; Fri, 21 Feb 2003 22:29:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22408 for ; Fri, 21 Feb 2003 22:21:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M3T8p09279; Fri, 21 Feb 2003 22:29:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M3Sgp09261 for ; Fri, 21 Feb 2003 22:28:42 -0500 Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22401 for ; Fri, 21 Feb 2003 22:20:50 -0500 (EST) Received: from cs.columbia.edu (164.indianapolis-17rh15rt.in.dial-access.att.net[12.85.0.164]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003022203244011100gs40fe>; Sat, 22 Feb 2003 03:24:41 +0000 Message-ID: <3E56ECD0.2060300@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis CC: simple@ietf.org Subject: Re: [Simple] RPIDS: extensions to PIDF References: <3E40355F.1060503@cs.columbia.edu> <028a01c2da03$a5478500$45071e0a@myopwv.com> In-Reply-To: <028a01c2da03$a5478500$45071e0a@myopwv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Feb 2003 22:21:52 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Section 4, "Groups of Presentities" is not very clear to me. > > For example, how is the "status of a group as a whole" defined? Is that an > aggregation of the presence documents of all the members? Yes. Clearly, some status descriptions won't make sense for a group, but I don't think any of them can be ruled out completely. In general, 'open' would mean that one or more of the members are available. > > The 4 types listed seem to be combinations of some characteristics such as: > - granularity of notifications (all members, individual members) > - triggering of notifications > - full/delta notifications > > Are there any more that are missing? Can we express those cases in terms of > some more basic features? It might be useful to discuss first whether the concept is needed in RPIDS, given the notion of list subscriptions in a different SIMPLE draft. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Feb 22 16:22:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15795 for ; Sat, 22 Feb 2003 16:22:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1MLTnP06190 for simple-archive@odin.ietf.org; Sat, 22 Feb 2003 16:29:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MLTnp06187 for ; Sat, 22 Feb 2003 16:29:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15790 for ; Sat, 22 Feb 2003 16:21:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MLTip06173; Sat, 22 Feb 2003 16:29:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MLSPp06149 for ; Sat, 22 Feb 2003 16:28:25 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15776 for ; Sat, 22 Feb 2003 16:20:11 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.139]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1MLO7YH000784 for ; Sat, 22 Feb 2003 16:24:07 -0500 (EST) Message-ID: <3E57EA70.3040007@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] some thoughts on "warnings" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Feb 2003 16:24:00 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, One of our aims is to ulimately have a set of protocols which can provide features on-par with the commercial IM/presence systems deployed today. One of the interesting features is the "warning" feature on AOL. This feature allows you to warn against a buddy. The more people warn against them, the higher their warn percentage. All subsribers to that buddy see their warning percentage. I believe this is quite easy to do for us. The "warn" operation against a buddy is just a PUBLISH request, but its a third party PUBLISH. If I warn against Henning, my publish would look like this: PUBLISH sip:hgs@cs.columbia.edu SIP/2.0 From: sip:jdrosen@dynamicsoft.com To: sip:jdrosen@dynamicsoft.com Content-Type: application/pidf The presence fragment has Henning as the presentity, and it has a single tuple with a single status. That status would be warn, whose value is a percentage: 100 This would get routed to the PA for henning (another good use of SIP for PUBLISH as opposed to something else, btw). The compositor there would combine my warn with any others, and compute an overall warning that gets applied. This would be distributed as an attribute of the presence document in NOTIFYs. Of course, the main complication is what "warn" really means. Is it a warning against a presentity? A device? A media type? Any or all of the above? This is part of the bigger issue of what a tuple and presentity represent. Assuming that is sorted out, all we need to support this is two things: * another attribute in hennings RPIDS draft, * a discussion of this in the architecture draft that we are chartered to do Do folks believe it is useful to add this, and if so, does the above mechanism make sense? 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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Feb 22 19:30:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18218 for ; Sat, 22 Feb 2003 19:30:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1N0cSm18159 for simple-archive@odin.ietf.org; Sat, 22 Feb 2003 19:38:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N0cSp18156 for ; Sat, 22 Feb 2003 19:38:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18192 for ; Sat, 22 Feb 2003 19:30:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N0cNp18147; Sat, 22 Feb 2003 19:38:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N0bgp18096 for ; Sat, 22 Feb 2003 19:37:42 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18189 for ; Sat, 22 Feb 2003 19:29:24 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1N0XFw22734; Sat, 22 Feb 2003 19:33:15 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA12290; Sat, 22 Feb 2003 18:33:12 -0600 (CST) Message-ID: <3E5816C8.5020604@lucent.com> From: "Vijay K. Gurbani" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@ietf.org Subject: Re: [Simple] some thoughts on "warnings" References: <3E57EA70.3040007@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Feb 2003 18:33:12 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] > Of course, the main complication is what "warn" really means. Is it a > warning against a presentity? A device? A media type? Any or all of the > above? This is part of the bigger issue of what a tuple and presentity > represent. One more reason why I have argued in the past that only principals (or groups of such) be presentities; everything else are devices controlled by the presentities. But I digress... > Assuming that is sorted out, all we need to support this is two things: > > * another attribute in hennings RPIDS draft, > * a discussion of this in the architecture draft that we are chartered > to do > > Do folks believe it is useful to add this, and if so, does the above > mechanism make sense? I have no problem with the mechanism itself (other than what is to stop me from sending a flood of warnings from all my different ids to wilfully harm harm a presentity by upping the warning level on it), or the inclusion of it as an attribute in the RPIDS I-D. But for the AOL uninitiated like me, could you provide more information on what the semantics of warn are? If the intent is to warn other watchers about the presence of an unwanted presentity, why would we even be interested in monitoring the presence of this unwanted presentity in the first place? I am sure I am missing something about the inherent semantics of warn... Cheers. - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Feb 22 19:52:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18413 for ; Sat, 22 Feb 2003 19:52:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1N104b19203 for simple-archive@odin.ietf.org; Sat, 22 Feb 2003 20:00:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N104p19200 for ; Sat, 22 Feb 2003 20:00:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18404 for ; Sat, 22 Feb 2003 19:51:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N0xJp19160; Sat, 22 Feb 2003 19:59:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N0wrp19146 for ; Sat, 22 Feb 2003 19:58:53 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18397 for ; Sat, 22 Feb 2003 19:50:33 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1N0sLQd024679 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 22 Feb 2003 19:54:22 -0500 (EST) Message-ID: <3E581BD8.6070300@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] some thoughts on "warnings" References: <3E57EA70.3040007@dynamicsoft.com> <3E5816C8.5020604@lucent.com> In-Reply-To: <3E5816C8.5020604@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Feb 2003 19:54:48 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit To me, the warning mechanism seems like a special case of a reputation system. These seem notoriously difficult to design if you want something that is not subject to various subversion tactics. I believe EBay and similar ventures have lots of experience with that. This is not just a device-presentity split - somebody may be a perfectly knowledgeable and useful conversation partner on topics related to LOTR, but may believe in new binary arithmetic. Also, as grade inflation shows, pretty soon all the IMers will be above average. Vijay K. Gurbani wrote: > Jonathan Rosenberg wrote: > [...] > >> Of course, the main complication is what "warn" really means. Is it a >> warning against a presentity? A device? A media type? Any or all of >> the above? This is part of the bigger issue of what a tuple and >> presentity represent. > > > One more reason why I have argued in the past that only principals > (or groups of such) be presentities; everything else are devices > controlled by the presentities. But I digress... > >> Assuming that is sorted out, all we need to support this is two things: >> >> * another attribute in hennings RPIDS draft, >> * a discussion of this in the architecture draft that we are chartered >> to do >> >> Do folks believe it is useful to add this, and if so, does the above >> mechanism make sense? > > > I have no problem with the mechanism itself (other than what is to > stop me from sending a flood of warnings from all my different ids > to wilfully harm harm a presentity by upping the warning level on it), > or the inclusion of it as an attribute in the RPIDS I-D. But for > the AOL uninitiated like me, could you provide more information on > what the semantics of warn are? If the intent is to warn other > watchers about the presence of an unwanted presentity, why would > we even be interested in monitoring the presence of this unwanted > presentity in the first place? > > I am sure I am missing something about the inherent semantics of > warn... > > Cheers. > > - vijay > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Feb 22 21:01:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19285 for ; Sat, 22 Feb 2003 21:01:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1N29PO23333 for simple-archive@odin.ietf.org; Sat, 22 Feb 2003 21:09:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N29Pp23330 for ; Sat, 22 Feb 2003 21:09:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19282 for ; Sat, 22 Feb 2003 21:01:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N29Hp23300; Sat, 22 Feb 2003 21:09:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N281p23274 for ; Sat, 22 Feb 2003 21:08:01 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19243 for ; Sat, 22 Feb 2003 20:59:40 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1N237sv019796; Sat, 22 Feb 2003 18:03:07 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ABR52422; Sat, 22 Feb 2003 18:03:23 -0800 (PST) From: "Cullen Jennings" To: "Jonathan Rosenberg" , Subject: RE: [Simple] some thoughts on "warnings" Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-reply-to: <3E57EA70.3040007@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Feb 2003 18:09:57 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Can you trust Henning's PA to correctly tabulate warns that warn against Henning? This seems like a push mechanism where every time someone adds a warn on somebody the message broadcast all over the place. It might be better to have it more a pull mechanism so that when you want to find out if you should trust AOR trying to contact you, you can query some set of people to get a warning for the AOR. The set of people could be random or a set or people you trust. (I have no idea what trust means in this context :-) On a more meta thought which may not lead to anything useful... Seems like this instantly gets wrapped up in the identity problems. Perhaps a warn system that is better than current systems can be build taking advantage of a PUBLISH mechanism but combining it with some ideas like http://www.advogato.org/trust-metric.html or PKI based webs of trusts. Cullen > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Saturday, February 22, 2003 1:24 PM > To: simple@ietf.org > Subject: [Simple] some thoughts on "warnings" > > > Folks, > > One of our aims is to ulimately have a set of protocols which can > provide features on-par with the commercial IM/presence systems deployed > today. One of the interesting features is the "warning" feature on AOL. > This feature allows you to warn against a buddy. The more people warn > against them, the higher their warn percentage. All subsribers to that > buddy see their warning percentage. > > I believe this is quite easy to do for us. The "warn" operation against > a buddy is just a PUBLISH request, but its a third party PUBLISH. If I > warn against Henning, my publish would look like this: > > PUBLISH sip:hgs@cs.columbia.edu SIP/2.0 > From: sip:jdrosen@dynamicsoft.com > To: sip:jdrosen@dynamicsoft.com > Content-Type: application/pidf > > > > The presence fragment has Henning as the presentity, and it has a single > tuple with a single status. That status would be warn, whose value is a > percentage: > > > > > 100 > > > > > This would get routed to the PA for henning (another good use of SIP for > PUBLISH as opposed to something else, btw). The compositor there would > combine my warn with any others, and compute an overall warning that > gets applied. This would be distributed as an attribute of the presence > document in NOTIFYs. > > Of course, the main complication is what "warn" really means. Is it a > warning against a presentity? A device? A media type? Any or all of the > above? This is part of the bigger issue of what a tuple and presentity > represent. > > Assuming that is sorted out, all we need to support this is two things: > > * another attribute in hennings RPIDS draft, > * a discussion of this in the architecture draft that we are > chartered to do > > Do folks believe it is useful to add this, and if so, does the above > mechanism make sense? > > 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@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Feb 23 09:03:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08049 for ; Sun, 23 Feb 2003 09:03:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1NEBcO05495 for simple-archive@odin.ietf.org; Sun, 23 Feb 2003 09:11:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NEBcp05492 for ; Sun, 23 Feb 2003 09:11:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08039 for ; Sun, 23 Feb 2003 09:03:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NEBYp05484; Sun, 23 Feb 2003 09:11:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NEAmp05431 for ; Sun, 23 Feb 2003 09:10:48 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07997 for ; Sun, 23 Feb 2003 09:02:13 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h1NE4GJX000233; Sun, 23 Feb 2003 09:04:16 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sun, 23 Feb 2003 08:06:06 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F325F4F7@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Paul Kyzivat , Adam Roach Cc: "'simple@ietf.org'" Subject: RE: [Simple] New event lists draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Feb 2003 08:06:04 -0600 Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > In section 3.2 (Event Header Parameters) the wording implies that the > id= parameter will be passed thru to subscriptions for elements in a > list. But this is probably a bad thing. Good catch. This is an oversight on my part. I certainly didn't intend to say that the "id" parameter must be passed through. > Shouldn't the event list server have the option to decide > when or if to > associate event ids with the subscriptions it generates? In fact, how the resource list server chooses to service these back-end subscriptions is intended to be largely a matter of implementation. You'll notice that, except for security considerations, there is no *normative* language that describes a formal relationship between the list subscriptions and any downstream subscriptions the RLS might create to service the list subscriptions. I've already received feedback that the current draft doesn't make this point very well, and I'll try to make this clearer in the next version of the document. Thanks for taking the time to look over the document. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sun Feb 23 12:31:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10215 for ; Sun, 23 Feb 2003 12:31:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1NHdeJ15135 for simple-archive@odin.ietf.org; Sun, 23 Feb 2003 12:39:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NHdep15132 for ; Sun, 23 Feb 2003 12:39:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10210 for ; Sun, 23 Feb 2003 12:31:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NHdap15124; Sun, 23 Feb 2003 12:39:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1NHcfp15103 for ; Sun, 23 Feb 2003 12:38:41 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10184 for ; Sun, 23 Feb 2003 12:30:02 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.139]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1NHXxYH000974 for ; Sun, 23 Feb 2003 12:33:59 -0500 (EST) Message-ID: <3E590602.6030200@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] new I-Ds on data manipulation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Feb 2003 12:33:54 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I've submitted an update to the data manipulation requirements spec. Until it appears, you can find it at: http://www.jdrosen.net/papers/draft-ietf-simple-data-req-01.txt There are a bunch of changes, most significantly is the removal of this whole script concept that was there before. I've also worked on a protocol mechanism to meet these requirements. ACAP is a pretty good fit (ftp://ftp.rfc-editor.org/in-notes/rfc2244.txt), so I worked through how to do this with ACAP. The result is a spec which documents an ACAP "dataset class", as its called, which is really a schema for data. Besides meeting the requirements, it has some useful extension and capability discovery mechanisms that are valuable. I am pretty happy with it, and the acap data model was a pretty natural fit for this kind of thing. As it turns out, ACAP as a protocol doesnt quite meet the requirements. So, the document propose to pursue a SOAP encoding of ACAP (which I've dubbed SEACAP), along with a new event package, to meet the requirements. The same dataset class would be used, and most of the semantics of acap too. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-simple-acap-data-00.txt http://www.jdrosen.net/papers/draft-rosenberg-simple-acap-data-00.html We need to determine if this is the direction we want the data manipulation work to go. If so, I will begin drafting the SEACAP details and the corresponding event package. Time is pressing, since 3gpp deadlines are beginning to loom large... 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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 24 03:31:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04704 for ; Mon, 24 Feb 2003 03:31:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O8dVB07339 for simple-archive@odin.ietf.org; Mon, 24 Feb 2003 03:39:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O8dVp07336 for ; Mon, 24 Feb 2003 03:39:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04692 for ; Mon, 24 Feb 2003 03:30:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O8dMp07328; Mon, 24 Feb 2003 03:39:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O8cup07308 for ; Mon, 24 Feb 2003 03:38:56 -0500 Received: from il-tlv-smtpout2.icomverse.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04689 for ; Mon, 24 Feb 2003 03:29:55 -0500 (EST) Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h1O8XVq26757; Mon, 24 Feb 2003 10:33:31 +0200 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id <1W08MPR6>; Mon, 24 Feb 2003 10:33:36 +0200 Message-ID: <385D702A9C11D511A9E90008C7160AD5054540AF@ismail1.comverse.com> From: Cnaan Oded To: "'Jonathan Rosenberg'" , simple@ietf.org Subject: RE: [Simple] new I-Ds on data manipulation MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DBDF.698C95EA" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Feb 2003 10:33:32 +0200 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_01C2DBDF.698C95EA Content-Type: text/plain; charset="iso-8859-1" Some comments on the new draft: 1. In the model depicted in figure 1, the "server" has only write access to the DB which is of course a limiting approach (although it was probably set only for the sake of the clarity). 2. The distinction between the 3 authorization policy types seems redundant, as they can all be derived from a single piece of information. The client should be allowed to choose which presence attributes are authorized for each subscriber. In this case, the binary decision of whether subscription is allowed is a direct derivation of whether there are authorized attributes. Taking this one step further, the second piece of information can also be expressed in terms of the specific attributes authorized for the subscriber. 3. The draft assumes that all the items in the user's buddy list (collection) are presentities, meaning, they have a designated ID (URI) that can be used to subscribe to their presence. However, a more general approach would be to treat this collection as an address book which MAY contain also non-presentity items (e.g., someone with only a street address). Note that this approach is supported by most handsets today. Following this approach, items in the collection should be associated with meta data, maybe in the form of a vCard. If we look ahead to the point where there would be a NAB (Network address book), Presence server and a PAC in the network, this draft doubles the information and transactions as all manipulations should be performed on both the NAB and PAC. The generalized approach would create a single entity that handles collections from all aspects. This generalization should not affect subscriptions made on these collections, as only those who are associated with an ID (URI) will be treated by the presence server. 4. I suggest adding a req. to allow clients to retrieve the list of collections (their URIs). 5. It seems that associating a display name with a collection (as well as with any other item) would be very beneficial for users to handle them. Note that in real implementations, users will probably not be required to even know the SIP URI of these collections. 6. It must be possible to distinguish between a collection and an non-collection item. 7. REQ 17 (section 4) seems too harsh. I suggest changing MUST to SHOULD as this mechanism may co-exist with non-SIMPLE platforms as well. 8. REQ 9 (section 5.1) implies that having someone in my buddy list (meaning that I see his presence) means that he should also be granted access to my presence. Fortunately, Presence authorization is not symmetric and this requirement should be deleted. 9. The draft seems to mix between block lists (which are presence server entities) and collections. I believe that requirements associated with block list should be removed from this draft and be specified in a separate draft. Another approach would be to add block list requirements to this draft. 10. It MUST be possible to extend the information associated with each item and/or collection. 11. REQ 4 (section 5.3): tuples may represent different 'views' (or schemes) of the presence information and this draft does not relate to the question of tuple types. Moreover, users have no idea what tuples are. Users should be able to manipulate information and it's up to the server to compose their presence document using tuples. Note that users (and clients) may not be aware of the way their tuples are composed and published to other watchers. Note also that the composition into tuples may be influenced by the SUBSCRIBE request (e.g., SUBSCRIBE to get all service / devices etc. that follow a certain filter). 12. REQ 7 (section 5.3): there are cases where users may not be aware of the document generated for them by the presence server. They may influence the attributes and values but not the way they are composed into a presence document. 13. The draft specifies that subscriptions may be based on collection URIs but it does not define whether these subscriptions are persistent. In other words, when I subscribe to a collection and then add another item to it, should it be automatically subscribed as well? The same applies to deleting items and un-subscribing. Oded Cnaan > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, February 23, 2003 7:34 PM > To: simple@ietf.org > Subject: [Simple] new I-Ds on data manipulation > > > Folks, > > I've submitted an update to the data manipulation requirements spec. > Until it appears, you can find it at: > > http://www.jdrosen.net/papers/draft-ietf-simple-data-req-01.txt > > There are a bunch of changes, most significantly is the > removal of this > whole script concept that was there before. > > I've also worked on a protocol mechanism to meet these requirements. > ACAP is a pretty good fit > (ftp://ftp.rfc-editor.org/in-notes/rfc2244.txt), so I worked > through how > to do this with ACAP. The result is a spec which documents an ACAP > "dataset class", as its called, which is really a schema for data. > Besides meeting the requirements, it has some useful extension and > capability discovery mechanisms that are valuable. I am pretty happy > with it, and the acap data model was a pretty natural fit for > this kind > of thing. > > As it turns out, ACAP as a protocol doesnt quite meet the > requirements. > So, the document propose to pursue a SOAP encoding of ACAP > (which I've > dubbed SEACAP), along with a new event package, to meet the > requirements. The same dataset class would be used, and most of the > semantics of acap too. > > Until it appears in the archives, you can pick up a copy at: > http://www.jdrosen.net/papers/draft-rosenberg-simple-acap-data-00.txt > http://www.jdrosen.net/papers/draft-rosenberg-simple-acap-data-00.html > > We need to determine if this is the direction we want the data > manipulation work to go. If so, I will begin drafting the > SEACAP details > and the corresponding event package. > > Time is pressing, since 3gpp deadlines are beginning to loom large... > > 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@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > ------_=_NextPart_001_01C2DBDF.698C95EA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] new I-Ds on data manipulation

Some comments on the new draft:

1. In the model depicted in figure 1, the = "server" has only write access to the DB which is of course a = limiting approach (although it was probably set only for the sake of = the clarity).

2. The distinction between the 3 authorization policy = types seems redundant, as they can all be derived from a single piece = of information. The client should be allowed to choose which presence = attributes are authorized for each subscriber. In this case, the binary = decision of whether subscription is allowed is a direct derivation of = whether there are authorized attributes. Taking this one step further, = the second piece of information can also be expressed in terms of the = specific attributes authorized for the subscriber.

3. The draft assumes that all the items in the user's = buddy list (collection) are presentities, meaning, they have a = designated ID (URI) that can be used to subscribe to their presence. = However, a more general approach would be to treat this collection as = an address book which MAY contain also non-presentity items (e.g., = someone with only a street address). Note that this approach is = supported by most handsets today.

Following this approach, items in the collection = should be associated with meta data, maybe in the form of a = vCard.

If we look ahead to the point where there would be a = NAB (Network address book), Presence server and a PAC in the network, = this draft doubles the information and transactions as all = manipulations should be performed on both the NAB and PAC. The = generalized approach would create a single entity that handles = collections from all aspects.

This generalization should not affect subscriptions = made on these collections, as only those who are associated with an ID = (URI) will be treated by the presence server.

4. I suggest adding a req. to allow clients to = retrieve the list of collections (their URIs).

5. It seems that associating a display name with a = collection (as well as with any other item) would be very beneficial = for users to handle them. Note that in real implementations, users will = probably not be required to even know the SIP URI of these = collections.

6. It must be possible to distinguish between a = collection and an non-collection item.

7. REQ 17 (section 4) seems too harsh. I suggest = changing MUST to SHOULD as this mechanism may co-exist with non-SIMPLE = platforms as well.

8. REQ 9 (section 5.1) implies that having someone in = my buddy list (meaning that I see his presence) means that he should = also be granted access to my presence. Fortunately, Presence = authorization is not symmetric and this requirement should be = deleted.

9. The draft seems to mix between block lists (which = are presence server entities) and collections. I believe that = requirements associated with block list should be removed from this = draft and be specified in a separate draft. Another approach would be = to add block list requirements to this draft.

10. It MUST be possible to extend the information = associated with each item and/or collection.

11. REQ 4 (section 5.3): tuples may represent = different 'views' (or schemes) of the presence information and this = draft does not relate to the question of tuple types. Moreover, users = have no idea what tuples are. Users should be able to manipulate = information and it's up to the server to compose their presence = document using tuples. Note that users (and clients) may not be aware = of the way their tuples are composed and published to other watchers. = Note also that the composition into tuples may be influenced by the = SUBSCRIBE request (e.g., SUBSCRIBE to get all service / devices etc. = that follow a certain filter).

12. REQ 7 (section 5.3): there are cases where users = may not be aware of the document generated for them by the presence = server. They may influence the attributes and values but not the way = they are composed into a presence document.

13. The draft specifies that subscriptions may be = based on collection URIs but it does not define whether these = subscriptions are persistent. In other words, when I subscribe to a = collection and then add another item to it, should it be automatically = subscribed as well? The same applies to deleting items and = un-subscribing.


Oded Cnaan


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Sunday, February 23, 2003 7:34 PM
> To: simple@ietf.org
> Subject: [Simple] new I-Ds on data = manipulation
>
>
> Folks,
>
> I've submitted an update to the data = manipulation requirements spec.
> Until it appears, you can find it at:
>
> http://www.jdrosen.net/papers/draft-ietf-simple-data-r= eq-01.txt
>
> There are a bunch of changes, most = significantly is the
> removal of this
> whole script concept that was there = before.
>
> I've also worked on a protocol mechanism to = meet these requirements.
> ACAP is a pretty good fit
> (ftp://ftp.rfc-editor.org/in-notes/rfc2244.txt), = so I worked
> through how
> to do this with ACAP. The result is a spec = which documents an ACAP
> "dataset class", as its called, which = is really a schema for data.
> Besides meeting the requirements, it has some = useful extension and
> capability discovery mechanisms that are = valuable. I am pretty happy
> with it, and the acap data model was a pretty = natural fit for
> this kind
> of thing.
>
> As it turns out, ACAP as a protocol doesnt = quite meet the
> requirements.
> So, the document propose to pursue a SOAP = encoding of ACAP
> (which I've
> dubbed SEACAP), along with a new event package, = to meet the
> requirements. The same dataset class would be = used, and most of the
> semantics of acap too.
>
> Until it appears in the archives, you can pick = up a copy at:
> http://www.jdrosen.net/papers/draft-rosenberg-simple-a= cap-data-00.txt
> http://www.jdrosen.net/papers/draft-rosenberg-simple-a= cap-data-00.html
>
> We need to determine if this is the direction = we want the data
> manipulation work to go. If so, I will begin = drafting the
> SEACAP details
> and the corresponding event package.
>
> Time is pressing, since 3gpp deadlines are = beginning to loom large...
>
> Thanks,
> Jonathan R.
>
>
> --
> Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
> Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> = _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>

------_=_NextPart_001_01C2DBDF.698C95EA-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 24 06:45:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08943 for ; Mon, 24 Feb 2003 06:45:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OBsKj18726 for simple-archive@odin.ietf.org; Mon, 24 Feb 2003 06:54:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OBsKp18723 for ; Mon, 24 Feb 2003 06:54:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08871 for ; Mon, 24 Feb 2003 06:45:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OBsGp18706; Mon, 24 Feb 2003 06:54:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OBrKp18636 for ; Mon, 24 Feb 2003 06:53:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08611; Mon, 24 Feb 2003 06:44:20 -0500 (EST) Message-Id: <200302241144.GAA08611@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-khartabil-simple-winfo-filter-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Feb 2003 06:44:19 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Event Notification Filtering for Watcher Info Author(s) : H. Khartabil, E. Leppanen Filename : draft-khartabil-simple-winfo-filter-00.txt Pages : 18 Date : 2003-2-21 Watcher information template-package for the SIP event framework refers to the set of users subscribed to a particular resource within a particular event package. The Watcher Information I-D does not describe a mechanism of how filtering of watcher information can be achieved. This document defines a watcher info filter. It provides the mechanism whereby a watcherinfo subscriber can specify the watcher info event filtering rules, using XML, for the notifier and how that notifier is to behave when receiving such filter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-khartabil-simple-winfo-filter-00.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-khartabil-simple-winfo-filter-00.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-khartabil-simple-winfo-filter-00.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: <2003-2-21160947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-khartabil-simple-winfo-filter-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-khartabil-simple-winfo-filter-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-21160947.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 24 06:46:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09147 for ; Mon, 24 Feb 2003 06:46:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OBt5V18781 for simple-archive@odin.ietf.org; Mon, 24 Feb 2003 06:55:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OBt4p18778 for ; Mon, 24 Feb 2003 06:55:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09000 for ; Mon, 24 Feb 2003 06:46:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OBt1p18765; Mon, 24 Feb 2003 06:55:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OBs9p18697 for ; Mon, 24 Feb 2003 06:54:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08811; Mon, 24 Feb 2003 06:45:09 -0500 (EST) Message-Id: <200302241145.GAA08811@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-lonnfors-simple-partial-notify-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Feb 2003 06:45:08 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Partial Notification of Presence Information Author(s) : J. Costa-Requena, E. Leppanen et al. Filename : draft-lonnfors-simple-partial-notify-00.txt Pages : 24 Date : 2003-2-21 A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and increasing efficiency, by introducing a new MIME-type æpartial notificationsÆ and a Require header extension æpartial-notificationÆ. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lonnfors-simple-partial-notify-00.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-lonnfors-simple-partial-notify-00.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-lonnfors-simple-partial-notify-00.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: <2003-2-21161114.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lonnfors-simple-partial-notify-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lonnfors-simple-partial-notify-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-21161114.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 24 06:52:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09534 for ; Mon, 24 Feb 2003 06:52:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OC18l19149 for simple-archive@odin.ietf.org; Mon, 24 Feb 2003 07:01:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OC18p19146 for ; Mon, 24 Feb 2003 07:01:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09506 for ; Mon, 24 Feb 2003 06:52:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OC12p19132; Mon, 24 Feb 2003 07:01:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OC0qp19098 for ; Mon, 24 Feb 2003 07:00:52 -0500 Received: from web41506.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09472 for ; Mon, 24 Feb 2003 06:51:51 -0500 (EST) Message-ID: <20030224115544.95174.qmail@web41506.mail.yahoo.com> Received: from [193.12.63.119] by web41506.mail.yahoo.com via HTTP; Mon, 24 Feb 2003 03:55:44 PST From: Sean Olson Subject: RE: [Simple] some thoughts on "warnings" To: Cullen Jennings , Jonathan Rosenberg , simple@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Feb 2003 03:55:44 -0800 (PST) My main concern with this approach would be re-using the PIDF format for this. This doesn't seem like a good fit for a presence attribute. I would prefer a new XML scheme for this rather than do this as an addon to PIDF. --- Cullen Jennings wrote: > > Can you trust Henning's PA to correctly tabulate > warns that warn against > Henning? > > This seems like a push mechanism where every time > someone adds a warn on > somebody the message broadcast all over the place. > It might be better to > have it more a pull mechanism so that when you want > to find out if you > should trust AOR trying to contact you, you can > query some set of people to > get a warning for the AOR. The set of people could > be random or a set or > people you trust. (I have no idea what trust means > in this context :-) > > On a more meta thought which may not lead to > anything useful... Seems like > this instantly gets wrapped up in the identity > problems. Perhaps a warn > system that is better than current systems can be > build taking advantage of > a PUBLISH mechanism but combining it with some ideas > like > http://www.advogato.org/trust-metric.html or PKI > based webs of trusts. > > Cullen > > > > -----Original Message----- > > From: simple-admin@ietf.org > [mailto:simple-admin@ietf.org]On Behalf Of > > Jonathan Rosenberg > > Sent: Saturday, February 22, 2003 1:24 PM > > To: simple@ietf.org > > Subject: [Simple] some thoughts on "warnings" > > > > > > Folks, > > > > One of our aims is to ulimately have a set of > protocols which can > > provide features on-par with the commercial > IM/presence systems deployed > > today. One of the interesting features is the > "warning" feature on AOL. > > This feature allows you to warn against a buddy. > The more people warn > > against them, the higher their warn percentage. > All subsribers to that > > buddy see their warning percentage. > > > > I believe this is quite easy to do for us. The > "warn" operation against > > a buddy is just a PUBLISH request, but its a third > party PUBLISH. If I > > warn against Henning, my publish would look like > this: > > > > PUBLISH sip:hgs@cs.columbia.edu SIP/2.0 > > From: sip:jdrosen@dynamicsoft.com > > To: sip:jdrosen@dynamicsoft.com > > Content-Type: application/pidf > > > > > > > > The presence fragment has Henning as the > presentity, and it has a single > > tuple with a single status. That status would be > warn, whose value is a > > percentage: > > > > > > > > > > 100 > > > > > > > > > > This would get routed to the PA for henning > (another good use of SIP for > > PUBLISH as opposed to something else, btw). The > compositor there would > > combine my warn with any others, and compute an > overall warning that > > gets applied. This would be distributed as an > attribute of the presence > > document in NOTIFYs. > > > > Of course, the main complication is what "warn" > really means. Is it a > > warning against a presentity? A device? A media > type? Any or all of the > > above? This is part of the bigger issue of what a > tuple and presentity > > represent. > > > > Assuming that is sorted out, all we need to > support this is two things: > > > > * another attribute in hennings RPIDS draft, > > * a discussion of this in the architecture draft > that we are > > chartered to do > > > > Do folks believe it is useful to add this, and if > so, does the above > > mechanism make sense? > > > > 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@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 24 09:57:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15845 for ; Mon, 24 Feb 2003 09:57:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OF6MO30527 for simple-archive@odin.ietf.org; Mon, 24 Feb 2003 10:06:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OF6Mp30524 for ; Mon, 24 Feb 2003 10:06:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15838 for ; Mon, 24 Feb 2003 09:57:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OF6Ip30508; Mon, 24 Feb 2003 10:06:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OF5Bp30460 for ; Mon, 24 Feb 2003 10:05:11 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15789 for ; Mon, 24 Feb 2003 09:56:06 -0500 (EST) Received: from cia.cisco.com (IDENT:mirapoint@cia.cisco.com [161.44.85.200]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1OExqJR015571; Mon, 24 Feb 2003 09:59:52 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-89.cisco.com [161.44.87.89]) by cia.cisco.com (Mirapoint) with ESMTP id ABP94759; Mon, 24 Feb 2003 09:49:54 -0500 (EST) Message-Id: <4.3.2.7.2.20030224095323.00b3cc78@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jonathan Rosenberg From: Michael Hammer Subject: Re: [Simple] some thoughts on "warnings" Cc: simple@ietf.org In-Reply-To: <3E57EA70.3040007@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Feb 2003 09:59:50 -0500 Jonathan, You most likely would need to publish this sort of warning to a well-known third-party not controllable by the offending party. The offending identity would need to be part of what is published along with perhaps a timestamp or something to provide some uniqueness and a sense of how often the offense is taken. A percentage may be valid over some base of messages, but only calculatable if the total number of messages sent is known. I'm not sure that will be the case. Also, how do you accumulate statistics, when the identity is set by the end-user, e.g. Marie1234, Marie1235, ... ? Mike At 04:24 PM 2/22/2003 -0500, Jonathan Rosenberg wrote: >Folks, > >One of our aims is to ulimately have a set of protocols which can provide >features on-par with the commercial IM/presence systems deployed today. >One of the interesting features is the "warning" feature on AOL. This >feature allows you to warn against a buddy. The more people warn against >them, the higher their warn percentage. All subsribers to that buddy see >their warning percentage. > >I believe this is quite easy to do for us. The "warn" operation against a >buddy is just a PUBLISH request, but its a third party PUBLISH. If I warn >against Henning, my publish would look like this: > >PUBLISH sip:hgs@cs.columbia.edu SIP/2.0 >From: sip:jdrosen@dynamicsoft.com >To: sip:jdrosen@dynamicsoft.com >Content-Type: application/pidf > > > >The presence fragment has Henning as the presentity, and it has a single >tuple with a single status. That status would be warn, whose value is a >percentage: > > > > > 100 > > > > >This would get routed to the PA for henning (another good use of SIP for >PUBLISH as opposed to something else, btw). The compositor there would >combine my warn with any others, and compute an overall warning that gets >applied. This would be distributed as an attribute of the presence >document in NOTIFYs. > >Of course, the main complication is what "warn" really means. Is it a >warning against a presentity? A device? A media type? Any or all of the >above? This is part of the bigger issue of what a tuple and presentity >represent. > >Assuming that is sorted out, all we need to support this is two things: > >* another attribute in hennings RPIDS draft, >* a discussion of this in the architecture draft that we are chartered to do > >Do folks believe it is useful to add this, and if so, does the above >mechanism make sense? > >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@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 24 14:34:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23864 for ; Mon, 24 Feb 2003 14:34:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OJhFu18340 for simple-archive@odin.ietf.org; Mon, 24 Feb 2003 14:43:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJhFp18337 for ; Mon, 24 Feb 2003 14:43:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23849 for ; Mon, 24 Feb 2003 14:34:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJhBp18315; Mon, 24 Feb 2003 14:43:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJgYp18241 for ; Mon, 24 Feb 2003 14:42:34 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23804 for ; Mon, 24 Feb 2003 14:33:23 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1OJbEC09077; Mon, 24 Feb 2003 19:37:15 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 14:37:19 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E2E@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'krisztian.kiss@nokia.com'" , simple@ietf.org Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Feb 2003 14:37:18 -0500 Some notes inline. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: krisztian.kiss@nokia.com [mailto:krisztian.kiss@nokia.com] > Sent: Thursday, February 20, 2003 5:01 AM > To: jon.peterson@neustar.biz; simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > Jon et al, > > I certainly welcome this document, especially section 3. > Please find some comments first concerning the actual requirements: > > - REQ12 and REQ14 define the need for unique identifiers of > segments. I would prefer to see further clarifications > related to these requirements concerning the issue which > entity (PUA or compositor) assigns the identifiers and based > on what. Even if it seems to be obvious that in case of > carrying PIDF in the PUBLISH request, the invention of tuple > ids is the PUA's responsibility. Having unique segment/tuple > ids inside the presentity is the key to detect collisions > from multiple PUAs. OK, it doesn't seem unreasonable to me to discuss which entity might generate the unique identifiers for segments. I can imagine formats other than PIDF in which it might make sense for the compositor function to generate these identifiers, but I don't know if we particularly need to allow that or not. > Related to the collision situation, I > have a further comment: > > - Assuming publishing partial or incremental presence > information (as written in REQ10), there is also a need for > the PUA to indicate whether it wants to overwrite existing > segment or only add additional attributes to it. Based on > this indication from the PUA, the compositor could decide to > extend or replace the old segment with the newly published > one, or reject the publication. > This one I'm a little less sure about. First of all, the current scope of the requirement discusses 'atomic segments' of presence. This atomicity entails, I think, that a PUA cannot add to a segment - it can only overwrite it. I think in order for the concept of a compositor to be sound, there has to be some kind of atomic element on which the compositor operates. It seems logical, in PIDF, to make the element atomic. As Jonathan pointed out in an earlier thread, however, this really just begs the question about the meaning of tuples themselves. Until we arrive at a solid semantic for s, this will remain unclear, I fear. > - REQ14 states that a PUA must be able to query the > identifiers of all of the segments. Assuming the above > described segment extension functionality, there would be > also a need to query the actual content of the segments, so > that the PUA could decide which operation (segment > extension or segment overwrite) to perform. > Right, since I'm assuming that segments are atomic, only overwrite, not extension, is necesary. In practice, I imagine that the way for a PUA to learn of all existing segments will be to subscribe to its own presence agent, in which case the PUA would get the content as well as the identifiers. > - Concerning partial publication (REQ10), there is also a > need for the PUA to explicitly indicate if it intends to > remove a certain segment from the presence information. > Um... I've been envisioning that instead of 'removal', that segment would be published with status of CLOSED (or with equivalent PIDF extension semantics). Alternatively, the PUA could allow the segment to expire. Ideally, both of these should show up the same way to subscribers. > - REQ6 defines the need to order publishing sequences. Isn't > there also a need for unique identification of PUAs? > Yes... but that is a core SIP requirement, though, rather than a publishing requirement, I think. Is there any reason why the normal ways of identifying user agents in SIP would be insufficient? If not, I don't think there is any publication requirement we need for this. > Concerning section 1, some synchronization would be needed > with section 3, as e.g. section 1 states that: > "each publication carries full state, and does not depend on > previous states for the particular PUA. A PUA does not need > to know whether or not other PUAs are also publishing > presence information to the compositor" > > while section 3 states: > "there should also be a way for PUAs to send partial or > incremental presence information" (REQ10); "The publication > mechanism must support a means for a presence compositor to > compose presence information received from multiple PUAs at > different times into a single presence document." (REQ8) > Well, the question is, does section 1 by 'full state' mean 'full state of the presentity' or 'full state of the PUA'? Clearly the former is what we want, and I'll make that explicit in the text. The statement about 'incremental' presence in requirement is 10 perhaps a little ambitious, and should probably be removed. > Regards, > Krisztian > > > > -----Original Message----- > > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Tuesday, February 11, 2003 10:31 PM > > To: Simpletons (E-mail) > > Subject: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > > > Aki is quite right that having these conversations about > > PUBLISH in the > > absence of requirements is wrong-headed. > > > > The authors of the PUBLISH proposal have fielded out some of > > the sections > > relevant to framework, and added some requirements language, to the > > following separate draft. The requirements in this draft were > > also informed > > by recent email list discussion. Until it appears in the repository: > > > > http://www.unreason.com/jfp/ietf/draft-ietf-simple-publish-req > s-00.html > > Comments welcome. > > Jon Peterson > Neustar, Inc. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 24 14:52:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24238 for ; Mon, 24 Feb 2003 14:52:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OK1DH18879 for simple-archive@odin.ietf.org; Mon, 24 Feb 2003 15:01:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OK1Dp18876 for ; Mon, 24 Feb 2003 15:01:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24215 for ; Mon, 24 Feb 2003 14:52:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OK18p18863; Mon, 24 Feb 2003 15:01:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OK0Zp18803 for ; Mon, 24 Feb 2003 15:00:35 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24185 for ; Mon, 24 Feb 2003 14:51:23 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1OJtFC09543; Mon, 24 Feb 2003 19:55:15 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 14:55:20 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E2F@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Markus.Isomaki@nokia.com'" , krisztian.kiss@nokia.com, simple@ietf.org Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Feb 2003 14:55:19 -0500 Some more notes inline. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Friday, February 21, 2003 6:51 AM > To: krisztian.kiss@nokia.com; jon.peterson@neustar.biz; > simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > Hi, > > I have some further comments on the publish requirements: > > My concern is the hard vs. soft state nature of the published > information. The initial SIP PUBLISH based solution seemed to > borrow its model (Expires header) from REGISTER. For REGISTER > it seems clear that soft state is beneficial, since if the UA > crashes, the registrar would like to get rid of the state, > since that state is no longer valid. > > However, presence information contains both hard state and > soft state components. You would like to maintain some > (relatively) persistent version of parts of your presence > data, even if you have no PUAs connected to the network, and > which you would very seldom update. This kind of information > contains for instance your e-mail contact or web page URL. > This seems to call for a hard state model, or a soft state > with very long expiration (i.e., infinity). > Well, hmm. Ordinarily, I think that presence information exists as a way to distribute a user's availability and disposition towards real-time communication, not to distribute persistent contact addresses. Would your web page, or email address, have associated 'presence'? Are they busy, idle, etc? You can also register HTTP or SMTP URLs as contact addresses in at a SIP registrar. We don't have any means of making these 'hard' state in that case either. > Definitely there are some soft state looking information as > well, such as tuples which are valid only as long as the PUA > is running, e.g. for IM or voice status. For this kind of > information there is some benefit in getting automatically > rid of it, if the PUA crashes. This is a question about the scope of presence itself, I gather. > > The minimum that seems to be needed is an expiration time > associated separately for each segment of the published data. > With this approach there is still one issue with one PUA > overwriting the information set by the other: If the > overwritten data has shorter expiry time than the original > data, what should happen if the overwritten data expires? In > other words, would the overwrite be a replace or a "stack > push" operation. In the latter case if the published > information expires, it will just "pop out of the stack" and > reveal the previous value. > That is an interesting question. I assume that if a segment is overwritten, it is forgotten; it will not go back into effect if the overwriting segment expires. Doing otherwise is needlessly complicated, and moreover there are cases I can imagine in which this would be the wrong behavior altogether. Maybe we do need a requirement to reflect this, though. > Another point of view that people have expressed is that > everything should be hard state. Watcher can evaluate the > correctness of the state based on how long about it was > published. Any refresh mechanism would only update this > "timestamp", but a failure to refresh would not cause the > data to disappear. > I doubt that we will move to a pure hard-state model for presence. Independent of any publication issues, there needs to be some way for old presence information to be garbage-collected and removed. I might use tens, or hundreds of different devices over the course of a year that might publish presence information for me, some of which I employ only very briefly. The tuples generated by these devices, with which I have a transient relationship, need to be removed from my presence state at some point, right? Watchers really don't need to get tuples from me saying that nine months ago, I was standing by this payphone in Tucson. It puts on enormous burden on watchers to sort through lots of trash to find relevant information. It also has potential privacy leaks. Of course, some sort of management interface could be defined so that users could do their own manual garbage collection. But that would be annoying. The REGISTER model, in which stale information automatically goes away for you, is much more suitable to real-time communications. > (My opinion is that the requirements for PUBLISH clearly > point that what actually would be needed is an RPC mechanism > (such as SOAP) on top of SIP. Both routing provided by SIP > and manipulation operations provided by an RPC protocol are > needed. But I know that this is banned in SIP for some > reasons (which leaves us with no such protocol in the > Internet...), so I'm happy to try with the current way.) > I don't think PUBLISH should be any more like an RPC system than REGISTER. > Regards, > Markus > > > > -----Original Message----- > > From: ext krisztian.kiss@nokia.com [mailto:krisztian.kiss@nokia.com] > > Sent: 20 February, 2003 15:01 > > To: jon.peterson@neustar.biz; simple@ietf.org > > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > Jon et al, > > > > I certainly welcome this document, especially section 3. > > Please find some comments first concerning the actual requirements: > > > > - REQ12 and REQ14 define the need for unique identifiers of > > segments. I would prefer to see further clarifications > > related to these requirements concerning the issue which > > entity (PUA or compositor) assigns the identifiers and based > > on what. Even if it seems to be obvious that in case of > > carrying PIDF in the PUBLISH request, the invention of tuple > > ids is the PUA's responsibility. Having unique segment/tuple > > ids inside the presentity is the key to detect collisions > > from multiple PUAs. Related to the collision situation, I > > have a further comment: > > > > - Assuming publishing partial or incremental presence > > information (as written in REQ10), there is also a need for > > the PUA to indicate whether it wants to overwrite existing > > segment or only add additional attributes to it. Based on > > this indication from the PUA, the compositor could decide to > > extend or replace the old segment with the newly published > > one, or reject the publication. > > > > - REQ14 states that a PUA must be able to query the > > identifiers of all of the segments. Assuming the above > > described segment extension functionality, there would be > > also a need to query the actual content of the segments, so > > that the PUA could decide which operation (segment > > extension or segment overwrite) to perform. > > > > - Concerning partial publication (REQ10), there is also a > > need for the PUA to explicitly indicate if it intends to > > remove a certain segment from the presence information. > > > > - REQ6 defines the need to order publishing sequences. Isn't > > there also a need for unique identification of PUAs? > > > > Concerning section 1, some synchronization would be needed > > with section 3, as e.g. section 1 states that: > > "each publication carries full state, and does not depend on > > previous states for the particular PUA. A PUA does not need > > to know whether or not other PUAs are also publishing > > presence information to the compositor" > > > > while section 3 states: > > "there should also be a way for PUAs to send partial or > > incremental presence information" (REQ10); "The publication > > mechanism must support a means for a presence compositor to > > compose presence information received from multiple PUAs at > > different times into a single presence document." (REQ8) > > > > Regards, > > Krisztian > > > > > > > -----Original Message----- > > > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > Sent: Tuesday, February 11, 2003 10:31 PM > > > To: Simpletons (E-mail) > > > Subject: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > > > > > > > Aki is quite right that having these conversations about > > > PUBLISH in the > > > absence of requirements is wrong-headed. > > > > > > The authors of the PUBLISH proposal have fielded out some of > > > the sections > > > relevant to framework, and added some requirements > language, to the > > > following separate draft. The requirements in this draft were > > > also informed > > > by recent email list discussion. Until it appears in the > repository: > > > > > > http://www.unreason.com/jfp/ietf/draft-ietf-simple-publish-req > > s-00.html > > > > Comments welcome. > > > > Jon Peterson > > Neustar, Inc. > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Feb 24 15:33:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25591 for ; Mon, 24 Feb 2003 15:33:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OKgEn22187 for simple-archive@odin.ietf.org; Mon, 24 Feb 2003 15:42:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OKgDp22184 for ; Mon, 24 Feb 2003 15:42:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25562 for ; Mon, 24 Feb 2003 15:33:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OKg9p22175; Mon, 24 Feb 2003 15:42:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OKfpp22155 for ; Mon, 24 Feb 2003 15:41:51 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25539 for ; Mon, 24 Feb 2003 15:32:38 -0500 (EST) From: krisztian.kiss@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1OKZI203120 for ; Mon, 24 Feb 2003 22:35:18 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 24 Feb 2003 22:36:31 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 24 Feb 2003 22:36:31 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 24 Feb 2003 22:36:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: draft-kiss-simple-winfo-filter-reqs-00 (was RE: [Simple] I-D ACTION:draft-khartabil-simple-winfo-filter-00.txt) Message-ID: Thread-Topic: [Simple] I-D ACTION:draft-khartabil-simple-winfo-filter-00.txt Thread-Index: AcLb+tK5ym1ZVFRzTR6uiRMoTDxcAQARyMiQ To: X-OriginalArrivalTime: 24 Feb 2003 20:36:31.0719 (UTC) FILETIME=[6A2FA770:01C2DC44] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1OKfpp22156 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Feb 2003 22:36:31 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit All, The corresponding requirements document (Requirements for Filtering of Watcher Information) is draft-kiss-simple-winfo-filter-reqs-00. Until it appears in the repository, please download from: http://free.x3.hu/krkiss/draft-kiss-simple-winfo-filter-reqs-00.txt Comments are welcome. Regards, Krisztian > -----Original Message----- > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, February 24, 2003 1:44 PM > Cc: simple@ietf.org > Subject: [Simple] I-D > ACTION:draft-khartabil-simple-winfo-filter-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Event Notification Filtering for Watcher Info > Author(s) : H. Khartabil, E. Leppanen > Filename : draft-khartabil-simple-winfo-filter-00.txt > Pages : 18 > Date : 2003-2-21 > > Watcher information template-package for the SIP event framework > refers to the set of users subscribed to a particular resource > within a particular event package. The Watcher Information I-D does > not describe a mechanism of how filtering of watcher information can > be achieved. > This document defines a watcher info filter. It provides the > mechanism whereby a watcherinfo subscriber can specify the watcher > info event filtering rules, using XML, for the notifier and how that > notifier is to behave when receiving such filter. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-khartabil-simple-win fo-filter-00.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-khartabil-simple-winfo-filter-00.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-khartabil-simple-winfo-filter-00.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. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Feb 25 06:52:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25396 for ; Tue, 25 Feb 2003 06:52:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PC1Te21747 for simple-archive@odin.ietf.org; Tue, 25 Feb 2003 07:01:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PC1Tp21744 for ; Tue, 25 Feb 2003 07:01:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25380 for ; Tue, 25 Feb 2003 06:52:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PC1Pp21735; Tue, 25 Feb 2003 07:01:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBxEp21561 for ; Tue, 25 Feb 2003 06:59:14 -0500 Received: from m3001.hostcentric.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25230 for ; Tue, 25 Feb 2003 06:49:45 -0500 (EST) Received: (qmail 10299 invoked by alias); 25 Feb 2003 11:53:38 -0000 Received: from unknown (HELO indigosw.com) (217.136.220.14) by 0 with SMTP; 25 Feb 2003 11:53:38 -0000 Message-ID: <3E5B5941.1050702@indigosw.com> From: Nicolas Dramais Organization: Indigo Software, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: simple@ietf.org CC: jdrosen@dynamicsoft.com, adam@dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Event lists and presence lists relation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Feb 2003 12:53:37 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, Does this brand new I-D on "SIP Event Notification Extension for Collections" obsolete/replace all the generic event list handling mechanism part, valid for any sip event notification system, described for presence lists handling by the PLS in the "Presence List Event Package" I-D ? Thanks, Nicolas Dramais Indigo Software _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 26 00:50:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29723 for ; Wed, 26 Feb 2003 00:50:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1Q60Gh32314 for simple-archive@odin.ietf.org; Wed, 26 Feb 2003 01:00:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q60Gp32311 for ; Wed, 26 Feb 2003 01:00:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29707 for ; Wed, 26 Feb 2003 00:50:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q60Cp32303; Wed, 26 Feb 2003 01:00:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q5xdp32252 for ; Wed, 26 Feb 2003 00:59:39 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29691 for ; Wed, 26 Feb 2003 00:49:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.58]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1Q5rjYH003223; Wed, 26 Feb 2003 00:53:46 -0500 (EST) Message-ID: <3E5C5662.7010903@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Dramais CC: simple@ietf.org, adam@dynamicsoft.com References: <3E5B5941.1050702@indigosw.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Event lists and presence lists relation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Feb 2003 00:53:38 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes. -Jonathan R. Nicolas Dramais wrote: > Dear all, > > Does this brand new I-D on "SIP Event Notification Extension for > Collections" obsolete/replace all the generic event list handling > mechanism part, valid for any sip event notification system, described > for presence lists handling by the PLS in the "Presence List Event > Package" I-D ? > > Thanks, > > Nicolas Dramais > Indigo Software > > -- 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@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 26 04:53:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29405 for ; Wed, 26 Feb 2003 04:53:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QA3Jm25959 for simple-archive@odin.ietf.org; Wed, 26 Feb 2003 05:03:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QA3Jp25956 for ; Wed, 26 Feb 2003 05:03:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29399 for ; Wed, 26 Feb 2003 04:53:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QA3Fp25947; Wed, 26 Feb 2003 05:03:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QA2Ep25904 for ; Wed, 26 Feb 2003 05:02:14 -0500 Received: from web41501.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29390 for ; Wed, 26 Feb 2003 04:52:15 -0500 (EST) Message-ID: <20030226095610.46207.qmail@web41501.mail.yahoo.com> Received: from [193.12.63.119] by web41501.mail.yahoo.com via HTTP; Wed, 26 Feb 2003 01:56:10 PST From: Sean Olson Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 To: "Peterson, Jon" , "'Markus.Isomaki@nokia.com'" , krisztian.kiss@nokia.com, simple@ietf.org In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214E2F@stntexch2.va.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Feb 2003 01:56:10 -0800 (PST) I second Jon's interpretation of the requirements for presence publication. While I think hard-state for presence may be an interesting concerpt in some scenarios, I believe it is entirely out of scope for the PUBLISH mechanism. More to the point, I believe hard-start for presence is a matter of local policy and is best handled in an implementation specific manner. As a first approximation of "hard-state", a PUBLISH with a suitably large Expires header value accomplishes much the same effect. --- "Peterson, Jon" wrote: > > Some more notes inline. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Markus.Isomaki@nokia.com > [mailto:Markus.Isomaki@nokia.com] > > Sent: Friday, February 21, 2003 6:51 AM > > To: krisztian.kiss@nokia.com; > jon.peterson@neustar.biz; > > simple@ietf.org > > Subject: RE: [Simple] > draft-ietf-simple-publish-reqs-00 > > > > > > Hi, > > > > I have some further comments on the publish > requirements: > > > > My concern is the hard vs. soft state nature of > the published > > information. The initial SIP PUBLISH based > solution seemed to > > borrow its model (Expires header) from REGISTER. > For REGISTER > > it seems clear that soft state is beneficial, > since if the UA > > crashes, the registrar would like to get rid of > the state, > > since that state is no longer valid. > > > > However, presence information contains both hard > state and > > soft state components. You would like to maintain > some > > (relatively) persistent version of parts of your > presence > > data, even if you have no PUAs connected to the > network, and > > which you would very seldom update. This kind of > information > > contains for instance your e-mail contact or web > page URL. > > This seems to call for a hard state model, or a > soft state > > with very long expiration (i.e., infinity). > > > > Well, hmm. Ordinarily, I think that presence > information exists as a way to > distribute a user's availability and disposition > towards real-time > communication, not to distribute persistent contact > addresses. Would your > web page, or email address, have associated > 'presence'? Are they busy, > idle, etc? > > You can also register HTTP or SMTP URLs as contact > addresses in at a SIP > registrar. We don't have any means of making these > 'hard' state in that case > either. > > > Definitely there are some soft state looking > information as > > well, such as tuples which are valid only as long > as the PUA > > is running, e.g. for IM or voice status. For this > kind of > > information there is some benefit in getting > automatically > > rid of it, if the PUA crashes. > > This is a question about the scope of presence > itself, I gather. > > > > > The minimum that seems to be needed is an > expiration time > > associated separately for each segment of the > published data. > > With this approach there is still one issue with > one PUA > > overwriting the information set by the other: If > the > > overwritten data has shorter expiry time than the > original > > data, what should happen if the overwritten data > expires? In > > other words, would the overwrite be a replace or a > "stack > > push" operation. In the latter case if the > published > > information expires, it will just "pop out of the > stack" and > > reveal the previous value. > > > > That is an interesting question. I assume that if a > segment is overwritten, > it is forgotten; it will not go back into effect if > the overwriting segment > expires. Doing otherwise is needlessly complicated, > and moreover there are > cases I can imagine in which this would be the wrong > behavior altogether. > > Maybe we do need a requirement to reflect this, > though. > > > Another point of view that people have expressed > is that > > everything should be hard state. Watcher can > evaluate the > > correctness of the state based on how long about > it was > > published. Any refresh mechanism would only update > this > > "timestamp", but a failure to refresh would not > cause the > > data to disappear. > > > > I doubt that we will move to a pure hard-state model > for presence. > Independent of any publication issues, there needs > to be some way for old > presence information to be garbage-collected and > removed. I might use tens, > or hundreds of different devices over the course of > a year that might > publish presence information for me, some of which I > employ only very > briefly. The tuples generated by these devices, with > which I have a > transient relationship, need to be removed from my > presence state at some > point, right? Watchers really don't need to get > tuples from me saying that > nine months ago, I was standing by this payphone in > Tucson. It puts on > enormous burden on watchers to sort through lots of > trash to find relevant > information. It also has potential privacy leaks. > > Of course, some sort of management interface could > be defined so that users > could do their own manual garbage collection. But > that would be annoying. > The REGISTER model, in which stale information > automatically goes away for > you, is much more suitable to real-time > communications. > > > (My opinion is that the requirements for PUBLISH > clearly > > point that what actually would be needed is an RPC > mechanism > > (such as SOAP) on top of SIP. Both routing > provided by SIP > > and manipulation operations provided by an RPC > protocol are > > needed. But I know that this is banned in SIP for > some > > reasons (which leaves us with no such protocol in > the > > Internet...), so I'm happy to try with the current > way.) > > > > I don't think PUBLISH should be any more like an RPC > system than REGISTER. > > > Regards, > > Markus > > > > > > > -----Original Message----- > > > From: ext krisztian.kiss@nokia.com > [mailto:krisztian.kiss@nokia.com] > > > Sent: 20 February, 2003 15:01 > > > To: jon.peterson@neustar.biz; simple@ietf.org > > > Subject: RE: [Simple] > draft-ietf-simple-publish-reqs-00 > > > > > > > > > Jon et al, > > > > > > I certainly welcome this document, especially > section 3. > > > Please find some comments first concerning the > actual requirements: > > > > > > - REQ12 and REQ14 define the need for unique > identifiers of > > > segments. I would prefer to see further > clarifications > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 26 06:20:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01155 for ; Wed, 26 Feb 2003 06:20:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QBUHK32094 for simple-archive@odin.ietf.org; Wed, 26 Feb 2003 06:30:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QBUHp32091 for ; Wed, 26 Feb 2003 06:30:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01152 for ; Wed, 26 Feb 2003 06:20:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QBUBp32082; Wed, 26 Feb 2003 06:30:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QBTPp32033 for ; Wed, 26 Feb 2003 06:29:25 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01143 for ; Wed, 26 Feb 2003 06:19:23 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1QBQQm14600 for ; Wed, 26 Feb 2003 13:26:26 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Feb 2003 13:23:18 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 13:23:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194517C@esebe013.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLcQDDI4hwaYUPpQkmzGrwMnRhhywBQiC2Q To: , , , X-OriginalArrivalTime: 26 Feb 2003 11:23:18.0461 (UTC) FILETIME=[7649EED0:01C2DD89] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1QBTPp32034 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Feb 2003 13:23:17 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Few comments inline. BTW, a good set of requirements. Cheers, Aki > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 24 February, 2003 21:55 > To: Isomaki Markus (NRC/Helsinki); Kiss Krisztian (NRC/Tampere); > simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > Some more notes inline. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > Sent: Friday, February 21, 2003 6:51 AM > > To: krisztian.kiss@nokia.com; jon.peterson@neustar.biz; > > simple@ietf.org > > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > Hi, > > > > I have some further comments on the publish requirements: > > > > My concern is the hard vs. soft state nature of the published > > information. The initial SIP PUBLISH based solution seemed to > > borrow its model (Expires header) from REGISTER. For REGISTER > > it seems clear that soft state is beneficial, since if the UA > > crashes, the registrar would like to get rid of the state, > > since that state is no longer valid. > > > > However, presence information contains both hard state and > > soft state components. You would like to maintain some > > (relatively) persistent version of parts of your presence > > data, even if you have no PUAs connected to the network, and > > which you would very seldom update. This kind of information > > contains for instance your e-mail contact or web page URL. > > This seems to call for a hard state model, or a soft state > > with very long expiration (i.e., infinity). > > > > Well, hmm. Ordinarily, I think that presence information > exists as a way to > distribute a user's availability and disposition towards real-time > communication, not to distribute persistent contact > addresses. Would your > web page, or email address, have associated 'presence'? Are > they busy, > idle, etc? I would imagine my email being always OPEN, with varying degrees of "availability", like "Gone to my summer cottage, only intermittent access" or "Actively reading". I hope the presence service isn't discriminatory against communication means that show a fairly good availability, i.e., OPEN all the time? > You can also register HTTP or SMTP URLs as contact addresses > in at a SIP > registrar. We don't have any means of making these 'hard' > state in that case > either. This is true. However, I think we're overlooking the fact that there is always a base line "hard state" at a registrar for a given AoR. And that is "no registered contacts". It's not like your AoR disappears if there are no active registrations. IMO, tuples shouldn't disappear either if there are no active publications. They should just show unavailability. I think this is the key issue here. > > Definitely there are some soft state looking information as > > well, such as tuples which are valid only as long as the PUA > > is running, e.g. for IM or voice status. For this kind of > > information there is some benefit in getting automatically > > rid of it, if the PUA crashes. > > This is a question about the scope of presence itself, I gather. Well, I think a reasonable implementation needs some tools to do garbage collection, so that the presence document bears some resemblance to real life availability. > > The minimum that seems to be needed is an expiration time > > associated separately for each segment of the published data. > > With this approach there is still one issue with one PUA > > overwriting the information set by the other: If the > > overwritten data has shorter expiry time than the original > > data, what should happen if the overwritten data expires? In > > other words, would the overwrite be a replace or a "stack > > push" operation. In the latter case if the published > > information expires, it will just "pop out of the stack" and > > reveal the previous value. > > > > That is an interesting question. I assume that if a segment > is overwritten, > it is forgotten; it will not go back into effect if the > overwriting segment > expires. Doing otherwise is needlessly complicated, and > moreover there are > cases I can imagine in which this would be the wrong > behavior altogether. Hmm. I think that modeling the pool of published segments as a stack is actually quite elegant. The operation would be: 1) The stack is initiated by pushing a "default" value (usually CLOSED) which is never popped. 2) Whenever a publication arrives, the published segment is pushed on the stack. A push will also usually trigger a notification (depending on PS local policy, filters, etc) 3) A topmost entry that has expired is always popped. If the stack has many elements, it is popped until an un-expired element, or the "default" value appears. Usually this also results in a notification being generated, just as in case 2. > Maybe we do need a requirement to reflect this, though. Maybe the lifetime of a segment should be considered separately from any crash recovery, or heartbeat type functionality of the publication process? > > Another point of view that people have expressed is that > > everything should be hard state. Watcher can evaluate the > > correctness of the state based on how long about it was > > published. Any refresh mechanism would only update this > > "timestamp", but a failure to refresh would not cause the > > data to disappear. > > > > I doubt that we will move to a pure hard-state model for presence. > Independent of any publication issues, there needs to be > some way for old > presence information to be garbage-collected and removed. I agree completely. > I > might use tens, > or hundreds of different devices over the course of a year that might > publish presence information for me, some of which I employ only very > briefly. The tuples generated by these devices, with which I have a > transient relationship, need to be removed from my presence > state at some > point, right? The state, yes. About the tuple's themselves, I'm not so sure. To me these type of "temporary" tuples look more like leasing an AoR than registering a contact for an AoR to use the registrar analogy. However, I fear I may have missed the discussion earlier about the meaning of a device in this context. I don't think each device should always have its own tuples, rather each separate device would usually publish state pertaining to a single tuple. > Watchers really don't need to get tuples from > me saying that > nine months ago, I was standing by this payphone in Tucson. > It puts on > enormous burden on watchers to sort through lots of trash to > find relevant > information. It also has potential privacy leaks. I completely agree. > Of course, some sort of management interface could be > defined so that users > could do their own manual garbage collection. But that would > be annoying. > The REGISTER model, in which stale information automatically > goes away for > you, is much more suitable to real-time communications. Similarly, when all devices are off, or out of coverage, I would like to see a presence document that says *something* even though that something is unavailable at the moment. Just like when I get a 480 and not 404 back when the callee is in an unregistered state. > > (My opinion is that the requirements for PUBLISH clearly > > point that what actually would be needed is an RPC mechanism > > (such as SOAP) on top of SIP. Both routing provided by SIP > > and manipulation operations provided by an RPC protocol are > > needed. But I know that this is banned in SIP for some > > reasons (which leaves us with no such protocol in the > > Internet...), so I'm happy to try with the current way.) > > > > I don't think PUBLISH should be any more like an RPC system > than REGISTER. I agree in that all RPC-type aspects (which I agree do exist) should not be in scope for the PUBLISH method. > > Regards, > > Markus > > > > > > > -----Original Message----- > > > From: ext krisztian.kiss@nokia.com > [mailto:krisztian.kiss@nokia.com] > > > Sent: 20 February, 2003 15:01 > > > To: jon.peterson@neustar.biz; simple@ietf.org > > > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > > > > Jon et al, > > > > > > I certainly welcome this document, especially section 3. > > > Please find some comments first concerning the actual > requirements: > > > > > > - REQ12 and REQ14 define the need for unique identifiers of > > > segments. I would prefer to see further clarifications > > > related to these requirements concerning the issue which > > > entity (PUA or compositor) assigns the identifiers and based > > > on what. Even if it seems to be obvious that in case of > > > carrying PIDF in the PUBLISH request, the invention of tuple > > > ids is the PUA's responsibility. Having unique segment/tuple > > > ids inside the presentity is the key to detect collisions > > > from multiple PUAs. Related to the collision situation, I > > > have a further comment: > > > > > > - Assuming publishing partial or incremental presence > > > information (as written in REQ10), there is also a need for > > > the PUA to indicate whether it wants to overwrite existing > > > segment or only add additional attributes to it. Based on > > > this indication from the PUA, the compositor could decide to > > > extend or replace the old segment with the newly published > > > one, or reject the publication. > > > > > > - REQ14 states that a PUA must be able to query the > > > identifiers of all of the segments. Assuming the above > > > described segment extension functionality, there would be > > > also a need to query the actual content of the segments, so > > > that the PUA could decide which operation (segment > > > extension or segment overwrite) to perform. > > > > > > - Concerning partial publication (REQ10), there is also a > > > need for the PUA to explicitly indicate if it intends to > > > remove a certain segment from the presence information. > > > > > > - REQ6 defines the need to order publishing sequences. Isn't > > > there also a need for unique identification of PUAs? > > > > > > Concerning section 1, some synchronization would be needed > > > with section 3, as e.g. section 1 states that: > > > "each publication carries full state, and does not depend on > > > previous states for the particular PUA. A PUA does not need > > > to know whether or not other PUAs are also publishing > > > presence information to the compositor" > > > > > > while section 3 states: > > > "there should also be a way for PUAs to send partial or > > > incremental presence information" (REQ10); "The publication > > > mechanism must support a means for a presence compositor to > > > compose presence information received from multiple PUAs at > > > different times into a single presence document." (REQ8) > > > > > > Regards, > > > Krisztian > > > > > > > > > > -----Original Message----- > > > > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > > Sent: Tuesday, February 11, 2003 10:31 PM > > > > To: Simpletons (E-mail) > > > > Subject: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > > > > > > > > > > > Aki is quite right that having these conversations about > > > > PUBLISH in the > > > > absence of requirements is wrong-headed. > > > > > > > > The authors of the PUBLISH proposal have fielded out some of > > > > the sections > > > > relevant to framework, and added some requirements > > language, to the > > > > following separate draft. The requirements in this draft were > > > > also informed > > > > by recent email list discussion. Until it appears in the > > repository: > > > > > > > > http://www.unreason.com/jfp/ietf/draft-ietf-simple-publish-req > > > s-00.html > > > > > > Comments welcome. > > > > > > Jon Peterson > > > Neustar, Inc. > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 26 06:28:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01292 for ; Wed, 26 Feb 2003 06:28:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QBc8m00672 for simple-archive@odin.ietf.org; Wed, 26 Feb 2003 06:38:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QBc8p00669 for ; Wed, 26 Feb 2003 06:38:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01287 for ; Wed, 26 Feb 2003 06:28:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QBc2p00660; Wed, 26 Feb 2003 06:38:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QBbpp00646 for ; Wed, 26 Feb 2003 06:37:51 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01282 for ; Wed, 26 Feb 2003 06:27:49 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1QBYqm22423 for ; Wed, 26 Feb 2003 13:34:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Feb 2003 13:31:44 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 13:31:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD308@esebe013.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLdfYb/RIevVGmsS76jGNf1Pz2OvQADNBMw To: , , , , X-OriginalArrivalTime: 26 Feb 2003 11:31:44.0230 (UTC) FILETIME=[A3C02860:01C2DD8A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1QBbpp00647 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Feb 2003 13:31:43 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Comment inline. > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: 26 February, 2003 11:56 > To: Peterson, Jon; Isomaki Markus (NRC/Helsinki); Kiss Krisztian > (NRC/Tampere); simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > I second Jon's interpretation of the requirements > for presence publication. While I think hard-state > for presence may be an interesting concerpt in > some scenarios, I believe it is entirely out of > scope for the PUBLISH mechanism. More to the point, > I believe hard-start for presence is a matter of > local policy and is best handled in an implementation > specific manner. As a first approximation of > "hard-state", a PUBLISH with a suitably large > Expires header value accomplishes much the same > effect. But isn't this the same as saying that hard-state manipulation *is* in the scope of PUBLISH? I mean, a presence segment with over 100 years expiry seems pretty hard-state to me. Cheers, Aki > > --- "Peterson, Jon" wrote: > > > > Some more notes inline. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Markus.Isomaki@nokia.com > > [mailto:Markus.Isomaki@nokia.com] > > > Sent: Friday, February 21, 2003 6:51 AM > > > To: krisztian.kiss@nokia.com; > > jon.peterson@neustar.biz; > > > simple@ietf.org > > > Subject: RE: [Simple] > > draft-ietf-simple-publish-reqs-00 > > > > > > > > > Hi, > > > > > > I have some further comments on the publish > > requirements: > > > > > > My concern is the hard vs. soft state nature of > > the published > > > information. The initial SIP PUBLISH based > > solution seemed to > > > borrow its model (Expires header) from REGISTER. > > For REGISTER > > > it seems clear that soft state is beneficial, > > since if the UA > > > crashes, the registrar would like to get rid of > > the state, > > > since that state is no longer valid. > > > > > > However, presence information contains both hard > > state and > > > soft state components. You would like to maintain > > some > > > (relatively) persistent version of parts of your > > presence > > > data, even if you have no PUAs connected to the > > network, and > > > which you would very seldom update. This kind of > > information > > > contains for instance your e-mail contact or web > > page URL. > > > This seems to call for a hard state model, or a > > soft state > > > with very long expiration (i.e., infinity). > > > > > > > Well, hmm. Ordinarily, I think that presence > > information exists as a way to > > distribute a user's availability and disposition > > towards real-time > > communication, not to distribute persistent contact > > addresses. Would your > > web page, or email address, have associated > > 'presence'? Are they busy, > > idle, etc? > > > > You can also register HTTP or SMTP URLs as contact > > addresses in at a SIP > > registrar. We don't have any means of making these > > 'hard' state in that case > > either. > > > > > Definitely there are some soft state looking > > information as > > > well, such as tuples which are valid only as long > > as the PUA > > > is running, e.g. for IM or voice status. For this > > kind of > > > information there is some benefit in getting > > automatically > > > rid of it, if the PUA crashes. > > > > This is a question about the scope of presence > > itself, I gather. > > > > > > > > The minimum that seems to be needed is an > > expiration time > > > associated separately for each segment of the > > published data. > > > With this approach there is still one issue with > > one PUA > > > overwriting the information set by the other: If > > the > > > overwritten data has shorter expiry time than the > > original > > > data, what should happen if the overwritten data > > expires? In > > > other words, would the overwrite be a replace or a > > "stack > > > push" operation. In the latter case if the > > published > > > information expires, it will just "pop out of the > > stack" and > > > reveal the previous value. > > > > > > > That is an interesting question. I assume that if a > > segment is overwritten, > > it is forgotten; it will not go back into effect if > > the overwriting segment > > expires. Doing otherwise is needlessly complicated, > > and moreover there are > > cases I can imagine in which this would be the wrong > > behavior altogether. > > > > Maybe we do need a requirement to reflect this, > > though. > > > > > Another point of view that people have expressed > > is that > > > everything should be hard state. Watcher can > > evaluate the > > > correctness of the state based on how long about > > it was > > > published. Any refresh mechanism would only update > > this > > > "timestamp", but a failure to refresh would not > > cause the > > > data to disappear. > > > > > > > I doubt that we will move to a pure hard-state model > > for presence. > > Independent of any publication issues, there needs > > to be some way for old > > presence information to be garbage-collected and > > removed. I might use tens, > > or hundreds of different devices over the course of > > a year that might > > publish presence information for me, some of which I > > employ only very > > briefly. The tuples generated by these devices, with > > which I have a > > transient relationship, need to be removed from my > > presence state at some > > point, right? Watchers really don't need to get > > tuples from me saying that > > nine months ago, I was standing by this payphone in > > Tucson. It puts on > > enormous burden on watchers to sort through lots of > > trash to find relevant > > information. It also has potential privacy leaks. > > > > Of course, some sort of management interface could > > be defined so that users > > could do their own manual garbage collection. But > > that would be annoying. > > The REGISTER model, in which stale information > > automatically goes away for > > you, is much more suitable to real-time > > communications. > > > > > (My opinion is that the requirements for PUBLISH > > clearly > > > point that what actually would be needed is an RPC > > mechanism > > > (such as SOAP) on top of SIP. Both routing > > provided by SIP > > > and manipulation operations provided by an RPC > > protocol are > > > needed. But I know that this is banned in SIP for > > some > > > reasons (which leaves us with no such protocol in > > the > > > Internet...), so I'm happy to try with the current > > way.) > > > > > > > I don't think PUBLISH should be any more like an RPC > > system than REGISTER. > > > > > Regards, > > > Markus > > > > > > > > > > -----Original Message----- > > > > From: ext krisztian.kiss@nokia.com > > [mailto:krisztian.kiss@nokia.com] > > > > Sent: 20 February, 2003 15:01 > > > > To: jon.peterson@neustar.biz; simple@ietf.org > > > > Subject: RE: [Simple] > > draft-ietf-simple-publish-reqs-00 > > > > > > > > > > > > Jon et al, > > > > > > > > I certainly welcome this document, especially > > section 3. > > > > Please find some comments first concerning the > > actual requirements: > > > > > > > > - REQ12 and REQ14 define the need for unique > > identifiers of > > > > segments. I would prefer to see further > > clarifications > > > === message truncated === > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 26 09:03:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05520 for ; Wed, 26 Feb 2003 09:03:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QED9811258 for simple-archive@odin.ietf.org; Wed, 26 Feb 2003 09:13:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QED9p11255 for ; Wed, 26 Feb 2003 09:13:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05488 for ; Wed, 26 Feb 2003 09:03:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QED5p11193; Wed, 26 Feb 2003 09:13:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QEBrp10982 for ; Wed, 26 Feb 2003 09:11:53 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05376; Wed, 26 Feb 2003 09:01:52 -0500 (EST) Message-Id: <200302261401.JAA05376@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-data-req-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Feb 2003 09:01:51 -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 : Requirements for Manipulation of Data Elements in SIMPLE Systems Author(s) : J. Rosenberg, M. Isomaki Filename : draft-ietf-simple-data-req-01.txt Pages : 15 Date : 2003-2-25 In any presence application, it is frequently necessary for the user to configure a number of pieces of information. Users will need to manipulate their presentity list, adding and removing presentities, and manipulate their authorization lists, which specify the set of users that can subscribe to their presence. In this document, we provide a framework and requirements for such data manipulations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-01.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-data-req-01.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-data-req-01.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: <2003-2-25160404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-data-req-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-data-req-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-25160404.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Feb 26 14:52:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21703 for ; Wed, 26 Feb 2003 14:52:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QK2JN05582 for simple-archive@odin.ietf.org; Wed, 26 Feb 2003 15:02:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QK2Jp05579 for ; Wed, 26 Feb 2003 15:02:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21698 for ; Wed, 26 Feb 2003 14:52:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QK2Fp05567; Wed, 26 Feb 2003 15:02:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QK1gp05542 for ; Wed, 26 Feb 2003 15:01:42 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21640 for ; Wed, 26 Feb 2003 14:51:32 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1QJtOC27704; Wed, 26 Feb 2003 19:55:25 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Feb 2003 14:55:31 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E59@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'aki.niemi@nokia.com'" , Markus.Isomaki@nokia.com, krisztian.kiss@nokia.com, simple@ietf.org Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Feb 2003 14:55:29 -0500 The argument that there is some 'hard state' that exists in the absence of any publications (namely, the state or document expressing that the user is away) is in some ways attractive, yes. You are correct that a registrar doesn't supply null contact addresses or something when the user in question has no registration, but rather provides a specific failure response. Of course, the events framework has a different semantics - subscriptions are accepted when there is currently no published presence information for a user. Sending a failure response wouldn't be workable. There are, however, a couple of NOTIFY syntaxes that might communicate that there is no available presence information. One is that a NOTIFY might not contain any body. Another is that the presence agent or compositor invents a simple tuple that contains a status of CLOSED. The latter option may sound a lot like hard state, whereas the former does not. Whether or not the latter option is really 'state' though is debatable - almost an implementation question. Having a default response to queries in the absence of state does not, in and of itself, constitute state in my opinion. It does not require, for example, per-user tables in memory that have some specific values, as far as I can imagine how it would be implemented. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Wednesday, February 26, 2003 3:23 AM > To: jon.peterson@neustar.biz; Markus.Isomaki@nokia.com; > krisztian.kiss@nokia.com; simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > Hi, > > Few comments inline. BTW, a good set of requirements. > > Cheers, > Aki > [snip] > > > Of course, some sort of management interface could be > > defined so that users > > could do their own manual garbage collection. But that would > > be annoying. > > The REGISTER model, in which stale information automatically > > goes away for > > you, is much more suitable to real-time communications. > > Similarly, when all devices are off, or out of coverage, I > would like to see a presence document that says *something* > even though that something is unavailable at the moment. > > Just like when I get a 480 and not 404 back when the callee > is in an unregistered state. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 03:49:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23050 for ; Thu, 27 Feb 2003 03:49:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1R8xQu31929 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 03:59:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8xPp31926 for ; Thu, 27 Feb 2003 03:59:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23044 for ; Thu, 27 Feb 2003 03:49:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8xDp31916; Thu, 27 Feb 2003 03:59:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8uDp31816 for ; Thu, 27 Feb 2003 03:56:13 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23009 for ; Thu, 27 Feb 2003 03:45:47 -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.2.1/Switch-2.2.0) with ESMTP id h1R8mQ224370 for ; Thu, 27 Feb 2003 10:48:26 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Feb 2003 10:49:40 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 10:49:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945180@esebe013.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLd0QLonoQNsw6rSV+Nb/UxNj1lpQAaD4ig To: , , , X-OriginalArrivalTime: 27 Feb 2003 08:49:40.0858 (UTC) FILETIME=[2A9515A0:01C2DE3D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1R8uEp31817 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 10:49:40 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I think we're on the same page here. Getting an error response or an empty notification to subscriptions is not valuable to the subscriber. Whether the composer acts as a PUA in the absence of any other PUAs and publishes unavailability, or whether the user can compose a default unavailability document, or something else - this is out of scope for PUBLISH. I also agree that it is probably an implementation question. So it seems the main issue is garbage collection. I think there is a requirement here not yet covered in the reqs-draft, that the PUBLISH mechanism must provide the composer means to do garbage collection in case a PUA dies. I think this implies a hearbeat / refresh type function for the publications. Then there's another question on how a composer does grabage collection. I think the two options presented in this thread are the "replace" model and the "stack" model. In theory, the stack model is better, but I can't think of an actual use case scenario where that would be striclty needed. So to avoid the complexity, I'm fine with the replace model. Cheers, Aki > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 26 February, 2003 21:55 > To: Niemi Aki (NMP/Helsinki); Isomaki Markus (NRC/Helsinki); Kiss > Krisztian (NRC/Tampere); simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > The argument that there is some 'hard state' that exists in > the absence of > any publications (namely, the state or document expressing > that the user is > away) is in some ways attractive, yes. You are correct that > a registrar > doesn't supply null contact addresses or something when the > user in question > has no registration, but rather provides a specific failure > response. Of > course, the events framework has a different semantics - > subscriptions are > accepted when there is currently no published presence > information for a > user. Sending a failure response wouldn't be workable. > > There are, however, a couple of NOTIFY syntaxes that might > communicate that > there is no available presence information. One is that a > NOTIFY might not > contain any body. Another is that the presence agent or > compositor invents a > simple tuple that contains a status of CLOSED. The latter > option may sound a > lot like hard state, whereas the former does not. Whether or > not the latter > option is really 'state' though is debatable - almost an > implementation > question. Having a default response to queries in the > absence of state does > not, in and of itself, constitute state in my opinion. It > does not require, > for example, per-user tables in memory that have some > specific values, as > far as I can imagine how it would be implemented. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > Sent: Wednesday, February 26, 2003 3:23 AM > > To: jon.peterson@neustar.biz; Markus.Isomaki@nokia.com; > > krisztian.kiss@nokia.com; simple@ietf.org > > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > Hi, > > > > Few comments inline. BTW, a good set of requirements. > > > > Cheers, > > Aki > > > [snip] > > > > > Of course, some sort of management interface could be > > > defined so that users > > > could do their own manual garbage collection. But that would > > > be annoying. > > > The REGISTER model, in which stale information automatically > > > goes away for > > > you, is much more suitable to real-time communications. > > > > Similarly, when all devices are off, or out of coverage, I > > would like to see a presence document that says *something* > > even though that something is unavailable at the moment. > > > > Just like when I get a 480 and not 404 back when the callee > > is in an unregistered state. > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 04:24:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23643 for ; Thu, 27 Feb 2003 04:24:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1R9YOh01818 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 04:34:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R9YOp01815 for ; Thu, 27 Feb 2003 04:34:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23622 for ; Thu, 27 Feb 2003 04:23:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R9YKp01806; Thu, 27 Feb 2003 04:34:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R9Xpp01788 for ; Thu, 27 Feb 2003 04:33:51 -0500 Received: from web41501.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23616 for ; Thu, 27 Feb 2003 04:23:25 -0500 (EST) Message-ID: <20030227092720.82521.qmail@web41501.mail.yahoo.com> Received: from [193.12.63.119] by web41501.mail.yahoo.com via HTTP; Thu, 27 Feb 2003 01:27:20 PST From: Sean Olson Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 To: aki.niemi@nokia.com, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com, krisztian.kiss@nokia.com, simple@ietf.org In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945180@esebe013.ntc.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 01:27:20 -0800 (PST) > So it seems the main issue is garbage collection. I > think there is a requirement here not yet covered in > the reqs-draft, that the PUBLISH mechanism must > provide the composer means to do garbage collection > in case a PUA dies. I think this implies a hearbeat > / refresh type function for the publications. > > Then there's another question on how a composer does > grabage collection. I think the two options > presented in this thread are the "replace" model and > the "stack" model. In theory, the stack model is > better, but I can't think of an actual use case > scenario where that would be striclty needed. So to > avoid the complexity, I'm fine with the replace > model. I'm confused about these two models. Are you speaking about two different PUAs publishing to the same tuple -or- are do you mean two different PUAs publishing to two different tuples that the composer aggregates? I'm trying to understand how these models relate to garbage collection (and if there are other models we need to consider) I assume you are talking about two PUAs publishing to the same tuple. In the stack model, when one PUA dies its state is popped and the second PUA's state becomes the new state for that tuple. In the replace model, I assume you mean latest PUA wins and therefore when one PUA dies, the other would have to re-PUBLISH its state for it to take effect -- how does the second PUA know to re-PUBLISH and when does that occur? In a possible third model, local policy at the composer determines the "winner". It's not necessarily a stack or a last-one-wins model. In this case, it may not be necessary for the second PUA to re-PUBLISH. __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 07:51:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28392 for ; Thu, 27 Feb 2003 07:51:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RD1Vb15271 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 08:01:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RD1Vp15268 for ; Thu, 27 Feb 2003 08:01:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28357 for ; Thu, 27 Feb 2003 07:51:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RD1Rp15246; Thu, 27 Feb 2003 08:01:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCu9p14712 for ; Thu, 27 Feb 2003 07:56:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27933; Thu, 27 Feb 2003 07:45:38 -0500 (EST) Message-Id: <200302271245.HAA27933@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-publish-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 07:45:38 -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 : SIMPLE Presence Publication Mechanism Author(s) : B. Campbell et al. Filename : draft-ietf-simple-publish-00.txt Pages : 18 Date : 2003-2-26 This document describes an extension to the Session Initiation Protocol (SIP) [1]. The purpose of this extension to create a means for publishing event state used within the framework for SIP Event Notification (RFC3265 [2]). The first application of this extension is targeted at the publication of presence information as defined by the SIMPLE [7] working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-publish-00.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-publish-00.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-publish-00.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: <2003-2-26161009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-publish-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-publish-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26161009.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 08:29:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01229 for ; Thu, 27 Feb 2003 08:29:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RDdOR19104 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 08:39:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDdOp19101 for ; Thu, 27 Feb 2003 08:39:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01221 for ; Thu, 27 Feb 2003 08:28:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDdDp19091; Thu, 27 Feb 2003 08:39:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDcup19055 for ; Thu, 27 Feb 2003 08:38:56 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01208 for ; Thu, 27 Feb 2003 08:28:22 -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.2.1/Switch-2.2.0) with ESMTP id h1RDV2221218 for ; Thu, 27 Feb 2003 15:31:02 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Feb 2003 15:32:18 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 15:32:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Garbage collection in publish RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD31F@esebe013.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLeR2FZk/FTIHt8QgS1SlysRoio8wAAnhvA To: , , , , X-OriginalArrivalTime: 27 Feb 2003 13:32:15.0994 (UTC) FILETIME=[A4A185A0:01C2DE64] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RDcup19056 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 15:32:15 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Comments inline. > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: 27 February, 2003 11:27 > To: Niemi Aki (NMP/Helsinki); jon.peterson@neustar.biz; > Isomaki Markus > (NRC/Helsinki); Kiss Krisztian (NRC/Tampere); simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > So it seems the main issue is garbage collection. I > > think there is a requirement here not yet covered in > > the reqs-draft, that the PUBLISH mechanism must > > provide the composer means to do garbage collection > > in case a PUA dies. I think this implies a hearbeat > > / refresh type function for the publications. > > > > Then there's another question on how a composer does > > grabage collection. I think the two options > > presented in this thread are the "replace" model and > > the "stack" model. In theory, the stack model is > > better, but I can't think of an actual use case > > scenario where that would be striclty needed. So to > > avoid the complexity, I'm fine with the replace > > model. > > I'm confused about these two models. Are you speaking > about two different PUAs publishing to the same > tuple -or- are do you mean two different PUAs > publishing to two different tuples that the > composer aggregates? I'm trying to understand how > these models relate to garbage collection (and if > there are other models we need to consider) > > I assume you are talking about > two PUAs publishing to the same tuple. Yes. > In the stack model, when one > PUA dies its state is popped and the second PUA's > state becomes the new state for that tuple. > > In the replace model, I assume you mean latest > PUA wins and therefore when one PUA dies, the other > would have to re-PUBLISH its state for it to take > effect -- how does the second PUA know to re-PUBLISH > and when does that occur? I was assuming that the second PUA would simply re-publish when it is its time to refresh. In fact, the stack model is only needed if publications from different PUAs had different expirys (like one being a multiple of the other). But if the composer can always guarantee that the refresh rates are aligned, I think the two models are the same. And since the composer can always lower a publisher's rate, I guess the only thing missing is "Min-Expires" for the opposite case? > In a possible third model, local policy at the > composer > determines the "winner". It's not necessarily a stack > or a last-one-wins model. In this case, it may not > be necessary for the second PUA to re-PUBLISH. This is true, there are actually three models. Out of the three, I think the "replace" model and the "winner" model are the relevant ones. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 08:34:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01447 for ; Thu, 27 Feb 2003 08:34:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RDi5i19467 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 08:44:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDi5p19464 for ; Thu, 27 Feb 2003 08:44:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01391 for ; Thu, 27 Feb 2003 08:33:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDi1p19455; Thu, 27 Feb 2003 08:44:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDhMp19434 for ; Thu, 27 Feb 2003 08:43:22 -0500 Received: from ihemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01386 for ; Thu, 27 Feb 2003 08:32:50 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1RDajn13319 for ; Thu, 27 Feb 2003 08:36:46 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 13:36:45 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EC1B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: simple@ietf.org Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-publish-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 13:36:43 -0000 I assume this draft is meant to be the next stage in the progress of the work resulting from draft-olson-simple-publish-01.txt, and that document is now obsolete. Can you clarify what is the current intention of the authors with regard to the header definitions. Facet and Stream are still in the examples, but there are no longer any definitions. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 27 February 2003 12:46 > Cc: simple@ietf.org > Subject: [Simple] I-D ACTION:draft-ietf-simple-publish-00.txt > > > 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 : SIMPLE Presence Publication Mechanism > Author(s) : B. Campbell et al. > Filename : draft-ietf-simple-publish-00.txt > Pages : 18 > Date : 2003-2-26 > > This document describes an extension to the Session Initiation > Protocol (SIP) [1]. The purpose of this extension to create a means > for publishing event state used within the framework for SIP Event > Notification (RFC3265 [2]). The first application of this extension > is targeted at the publication of presence information as defined by > the SIMPLE [7] working group. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-publish-00.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-publish-00.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-publish-00.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. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 08:53:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02805 for ; Thu, 27 Feb 2003 08:53:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RE3DG20624 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 09:03:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RE3Dp20621 for ; Thu, 27 Feb 2003 09:03:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02794 for ; Thu, 27 Feb 2003 08:52:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RE37p20597; Thu, 27 Feb 2003 09:03:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RE21p20538 for ; Thu, 27 Feb 2003 09:02:01 -0500 Received: from web41507.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02748 for ; Thu, 27 Feb 2003 08:51:30 -0500 (EST) Message-ID: <20030227135523.52970.qmail@web41507.mail.yahoo.com> Received: from [193.12.63.119] by web41507.mail.yahoo.com via HTTP; Thu, 27 Feb 2003 05:55:23 PST From: Sean Olson Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-publish-00.txt To: "Drage, Keith \(Keith\)" , simple@ietf.org In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EC1B@en0033exch001u.uk.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 05:55:23 -0800 (PST) I am issuing an updated draft-olson-simple-publish-02 draft. This confusion is because of some miscommunication on my part with the other authors of the draft. Specifically, the Facet and Stream headers have been removed from the new draft as was agreed at the last IETF. Sorry for the confusion ... almost as difficult as finding the right 3GPP draft ;-) Regards, Sean --- "Drage, Keith (Keith)" wrote: > I assume this draft is meant to be the next stage in > the progress of the work resulting from > draft-olson-simple-publish-01.txt, and that document > is now obsolete. > > Can you clarify what is the current intention of the > authors with regard to the header definitions. Facet > and Stream are still in the examples, but there are > no longer any definitions. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Internet-Drafts@ietf.org > [mailto:Internet-Drafts@ietf.org] > > Sent: 27 February 2003 12:46 > > Cc: simple@ietf.org > > Subject: [Simple] I-D > ACTION:draft-ietf-simple-publish-00.txt > > > > > > 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 : SIMPLE Presence Publication Mechanism > > Author(s) : B. Campbell et al. > > Filename : draft-ietf-simple-publish-00.txt > > Pages : 18 > > Date : 2003-2-26 > > > > This document describes an extension to the > Session Initiation > > Protocol (SIP) [1]. The purpose of this extension > to create a means > > for publishing event state used within the > framework for SIP Event > > Notification (RFC3265 [2]). The first application > of this extension > > is targeted at the publication of presence > information as defined by > > the SIMPLE [7] working group. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-publish-00.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-publish-00.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-publish-00.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. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 09:12:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03808 for ; Thu, 27 Feb 2003 09:12:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1REMKf22337 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 09:22:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1REMJp22332 for ; Thu, 27 Feb 2003 09:22:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03790 for ; Thu, 27 Feb 2003 09:11:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1REMDp22315; Thu, 27 Feb 2003 09:22:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RELcp22245 for ; Thu, 27 Feb 2003 09:21:38 -0500 Received: from d12lmsgate-5.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03762 for ; Thu, 27 Feb 2003 09:11:02 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1REEpb0101904 for ; Thu, 27 Feb 2003 15:14:53 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1REEojF126854 for ; Thu, 27 Feb 2003 15:14:51 +0100 To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 27/02/2003 16:14:51, Serialize complete at 27/02/2003 16:14:51 Content-Type: text/plain; charset="US-ASCII" Subject: [Simple] Fw: I-D ACTION:draft-houri-simple-arch-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 16:14:29 +0200 ----- Forwarded by Avshalom Houri/Haifa/IBM on 27/02/2003 16:13 ----- Internet-Drafts@ietf.org Sent by: owner-ietf-announce@ietf.org 27/02/2003 14:44 Please respond to Internet-Drafts@ietf.org To IETF-Announce: ; cc Subject I-D ACTION:draft-houri-simple-arch-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP/SIMPLE Based Presence and IM Architecture Author(s) : A. Houri, T. Hansen Filename : draft-houri-simple-arch-00.txt Pages : 32 Date : 2003-2-26 This document collects information required for the creation a complete Presence and IM system using SIMPLE and other IETF protocols. This information has been spread out across numerous other internet drafts and RFCs. The document tries to put everything together, discussing the servers involved, security mechanisms, call flows, etc. The goal of this document is that someone, who is not an expert in the IETF protocols, can read this document and understand how the IETF protocols can be used for building a complete system and how it should work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-houri-simple-arch-00.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-houri-simple-arch-00.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-houri-simple-arch-00.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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-houri-simple-arch-00.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 10:28:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08132 for ; Thu, 27 Feb 2003 10:28:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RFcFs28609 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 10:38:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFcEp28606 for ; Thu, 27 Feb 2003 10:38:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08108 for ; Thu, 27 Feb 2003 10:27:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFc8p28594; Thu, 27 Feb 2003 10:38:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFb9p28025 for ; Thu, 27 Feb 2003 10:37:09 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08048 for ; Thu, 27 Feb 2003 10:26:34 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1RFXdm20550 for ; Thu, 27 Feb 2003 17:33:39 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Feb 2003 17:30:28 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 17:30:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945188@esebe013.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLdfYb/RIevVGmsS76jGNf1Pz2OvQA9BGng To: , , , , X-OriginalArrivalTime: 27 Feb 2003 15:30:28.0420 (UTC) FILETIME=[280BD840:01C2DE75] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RFb9p28026 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 17:30:28 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi All, A further thought on this. > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: 26 February, 2003 11:56 > To: Peterson, Jon; Isomaki Markus (NRC/Helsinki); Kiss Krisztian > (NRC/Tampere); simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > I second Jon's interpretation of the requirements > for presence publication. While I think hard-state > for presence may be an interesting concerpt in > some scenarios, I believe it is entirely out of > scope for the PUBLISH mechanism. More to the point, > I believe hard-start for presence is a matter of > local policy and is best handled in an implementation > specific manner. As a first approximation of > "hard-state", a PUBLISH with a suitably large > Expires header value accomplishes much the same > effect. A suitably large Expires value would probably not work with any composer that wishes to do garbage collection in a reasonable way. It would instead lower the value to one that conforms with its local policy. So instead, what if we define the semantics of a PUBLISH without an Expires header to accomplish this? In other words, a PUBLISH without an Expires header wouldn't expire, and would instead "initiate the composer" with a default status. Cheers, Aki > > > --- "Peterson, Jon" wrote: > > > > Some more notes inline. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Markus.Isomaki@nokia.com > > [mailto:Markus.Isomaki@nokia.com] > > > Sent: Friday, February 21, 2003 6:51 AM > > > To: krisztian.kiss@nokia.com; > > jon.peterson@neustar.biz; > > > simple@ietf.org > > > Subject: RE: [Simple] > > draft-ietf-simple-publish-reqs-00 > > > > > > > > > Hi, > > > > > > I have some further comments on the publish > > requirements: > > > > > > My concern is the hard vs. soft state nature of > > the published > > > information. The initial SIP PUBLISH based > > solution seemed to > > > borrow its model (Expires header) from REGISTER. > > For REGISTER > > > it seems clear that soft state is beneficial, > > since if the UA > > > crashes, the registrar would like to get rid of > > the state, > > > since that state is no longer valid. > > > > > > However, presence information contains both hard > > state and > > > soft state components. You would like to maintain > > some > > > (relatively) persistent version of parts of your > > presence > > > data, even if you have no PUAs connected to the > > network, and > > > which you would very seldom update. This kind of > > information > > > contains for instance your e-mail contact or web > > page URL. > > > This seems to call for a hard state model, or a > > soft state > > > with very long expiration (i.e., infinity). > > > > > > > Well, hmm. Ordinarily, I think that presence > > information exists as a way to > > distribute a user's availability and disposition > > towards real-time > > communication, not to distribute persistent contact > > addresses. Would your > > web page, or email address, have associated > > 'presence'? Are they busy, > > idle, etc? > > > > You can also register HTTP or SMTP URLs as contact > > addresses in at a SIP > > registrar. We don't have any means of making these > > 'hard' state in that case > > either. > > > > > Definitely there are some soft state looking > > information as > > > well, such as tuples which are valid only as long > > as the PUA > > > is running, e.g. for IM or voice status. For this > > kind of > > > information there is some benefit in getting > > automatically > > > rid of it, if the PUA crashes. > > > > This is a question about the scope of presence > > itself, I gather. > > > > > > > > The minimum that seems to be needed is an > > expiration time > > > associated separately for each segment of the > > published data. > > > With this approach there is still one issue with > > one PUA > > > overwriting the information set by the other: If > > the > > > overwritten data has shorter expiry time than the > > original > > > data, what should happen if the overwritten data > > expires? In > > > other words, would the overwrite be a replace or a > > "stack > > > push" operation. In the latter case if the > > published > > > information expires, it will just "pop out of the > > stack" and > > > reveal the previous value. > > > > > > > That is an interesting question. I assume that if a > > segment is overwritten, > > it is forgotten; it will not go back into effect if > > the overwriting segment > > expires. Doing otherwise is needlessly complicated, > > and moreover there are > > cases I can imagine in which this would be the wrong > > behavior altogether. > > > > Maybe we do need a requirement to reflect this, > > though. > > > > > Another point of view that people have expressed > > is that > > > everything should be hard state. Watcher can > > evaluate the > > > correctness of the state based on how long about > > it was > > > published. Any refresh mechanism would only update > > this > > > "timestamp", but a failure to refresh would not > > cause the > > > data to disappear. > > > > > > > I doubt that we will move to a pure hard-state model > > for presence. > > Independent of any publication issues, there needs > > to be some way for old > > presence information to be garbage-collected and > > removed. I might use tens, > > or hundreds of different devices over the course of > > a year that might > > publish presence information for me, some of which I > > employ only very > > briefly. The tuples generated by these devices, with > > which I have a > > transient relationship, need to be removed from my > > presence state at some > > point, right? Watchers really don't need to get > > tuples from me saying that > > nine months ago, I was standing by this payphone in > > Tucson. It puts on > > enormous burden on watchers to sort through lots of > > trash to find relevant > > information. It also has potential privacy leaks. > > > > Of course, some sort of management interface could > > be defined so that users > > could do their own manual garbage collection. But > > that would be annoying. > > The REGISTER model, in which stale information > > automatically goes away for > > you, is much more suitable to real-time > > communications. > > > > > (My opinion is that the requirements for PUBLISH > > clearly > > > point that what actually would be needed is an RPC > > mechanism > > > (such as SOAP) on top of SIP. Both routing > > provided by SIP > > > and manipulation operations provided by an RPC > > protocol are > > > needed. But I know that this is banned in SIP for > > some > > > reasons (which leaves us with no such protocol in > > the > > > Internet...), so I'm happy to try with the current > > way.) > > > > > > > I don't think PUBLISH should be any more like an RPC > > system than REGISTER. > > > > > Regards, > > > Markus > > > > > > > > > > -----Original Message----- > > > > From: ext krisztian.kiss@nokia.com > > [mailto:krisztian.kiss@nokia.com] > > > > Sent: 20 February, 2003 15:01 > > > > To: jon.peterson@neustar.biz; simple@ietf.org > > > > Subject: RE: [Simple] > > draft-ietf-simple-publish-reqs-00 > > > > > > > > > > > > Jon et al, > > > > > > > > I certainly welcome this document, especially > > section 3. > > > > Please find some comments first concerning the > > actual requirements: > > > > > > > > - REQ12 and REQ14 define the need for unique > > identifiers of > > > > segments. I would prefer to see further > > clarifications > > > === message truncated === > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 11:09:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09589 for ; Thu, 27 Feb 2003 11:09:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RGJ8u31290 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 11:19:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RGJ8p31287 for ; Thu, 27 Feb 2003 11:19:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09575 for ; Thu, 27 Feb 2003 11:08:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RGJ3p31279; Thu, 27 Feb 2003 11:19:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RGITp31260 for ; Thu, 27 Feb 2003 11:18:29 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09567 for ; Thu, 27 Feb 2003 11:07:54 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1RGExm17728 for ; Thu, 27 Feb 2003 18:15:00 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Feb 2003 18:11:49 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 18:11:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLd0QMA3O2qSaB/RGy2UXEJq4r2VwAp2bIQ To: , , , X-OriginalArrivalTime: 27 Feb 2003 16:11:49.0394 (UTC) FILETIME=[EED26F20:01C2DE7A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RGITp31261 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 18:11:48 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, If we think that there is some value (as at least I do) in having some kind of 'hard state' in the absense of any published information (which needs to be garbage collected), and we think that SIP PUBLISH is not the right way to manage it, should we consider it being in the scope of Data Manipulation (we have such a mechanism on our charter)? The user could set the data whenever, and overwrite it using SIP PUBLISH. Uploading a PIDF document should be good enough. Assignment of tuple ids and labels would of course need to be consistent with SIP PUBLISH. I guess Jon's idea is to have some default response for all AoRs/users served by a particular PA, whereas I think it should be a per user thing. I would like to have a tuple describing my e-mail status (basically always open, but the note might indicate that messages won't be read until Monday). It has been argued that this might not be part of presence, but what else would be as nice a way of letting people know this type of information. Markus > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 26 February, 2003 21:55 > To: Niemi Aki (NMP/Helsinki); Isomaki Markus (NRC/Helsinki); Kiss > Krisztian (NRC/Tampere); simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > The argument that there is some 'hard state' that exists in > the absence of > any publications (namely, the state or document expressing > that the user is > away) is in some ways attractive, yes. You are correct that a > registrar > doesn't supply null contact addresses or something when the > user in question > has no registration, but rather provides a specific failure > response. Of > course, the events framework has a different semantics - > subscriptions are > accepted when there is currently no published presence > information for a > user. Sending a failure response wouldn't be workable. > > There are, however, a couple of NOTIFY syntaxes that might > communicate that > there is no available presence information. One is that a > NOTIFY might not > contain any body. Another is that the presence agent or > compositor invents a > simple tuple that contains a status of CLOSED. The latter > option may sound a > lot like hard state, whereas the former does not. Whether or > not the latter > option is really 'state' though is debatable - almost an > implementation > question. Having a default response to queries in the absence > of state does > not, in and of itself, constitute state in my opinion. It > does not require, > for example, per-user tables in memory that have some > specific values, as > far as I can imagine how it would be implemented. > > Jon Peterson > NeuStar, Inc. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 11:34:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10483 for ; Thu, 27 Feb 2003 11:34:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RGiOr00832 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 11:44:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RGiNp00829 for ; Thu, 27 Feb 2003 11:44:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10472 for ; Thu, 27 Feb 2003 11:33:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RGiJp00815; Thu, 27 Feb 2003 11:44:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RGhsp00770 for ; Thu, 27 Feb 2003 11:43:54 -0500 Received: from web41506.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10459 for ; Thu, 27 Feb 2003 11:33:19 -0500 (EST) Message-ID: <20030227163713.59390.qmail@web41506.mail.yahoo.com> Received: from [193.12.63.119] by web41506.mail.yahoo.com via HTTP; Thu, 27 Feb 2003 08:37:13 PST From: Sean Olson Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 To: aki.niemi@nokia.com, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com, krisztian.kiss@nokia.com, simple@ietf.org In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945188@esebe013.ntc.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 08:37:13 -0800 (PST) > A suitably large Expires value would probably not > work with any composer that wishes to do garbage > collection in a reasonable way. It would instead > lower the value to one that conforms with its local > policy. This I don't quite understand. Either the composer is going to authorize you to store state for a long time or its not. Why would the composer be more willing to store hard-state vs. state that lasts a very long time? > So instead, what if we define the semantics of a > PUBLISH without an Expires header to accomplish > this? In other words, a PUBLISH without an Expires > header wouldn't expire, and would instead "initiate > the composer" with a default status. I would prefer that a PUBLISH without an Expires header be reserved to mean that the client wishes the server to choose an expiration value for the publication. > > Cheers, > Aki > __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 11:44:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10866 for ; Thu, 27 Feb 2003 11:44:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RGs7t01439 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 11:54:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RGs7p01436 for ; Thu, 27 Feb 2003 11:54:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10861 for ; Thu, 27 Feb 2003 11:43:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RGs2p01415; Thu, 27 Feb 2003 11:54:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RGp8p01286 for ; Thu, 27 Feb 2003 11:51:08 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10780 for ; Thu, 27 Feb 2003 11:40:32 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1RGhC207155 for ; Thu, 27 Feb 2003 18:43:12 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Feb 2003 18:44:27 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 18:44:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] new I-Ds on data manipulation Message-ID: Thread-Topic: [Simple] new I-Ds on data manipulation Thread-Index: AcLbYglxgYDLKDpIS7CcfvM1l26MPgC16gsA To: , X-OriginalArrivalTime: 27 Feb 2003 16:44:27.0321 (UTC) FILETIME=[7DD66290:01C2DE7F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RGp8p01287 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 18:44:26 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Thanks for the SEACAP draft, Jonathan. First, some general comments: ACAP seems to be a reasonable fit to the data manipulation problem. If it is chosen as a baseline, I support doing the SOAP encoding + SIP event package for notifications for the purposes listed in the draft. Having to maintain a long lived TCP connection is not a preferable solution. Ability to run through intermediaries may be important in some cases. While agreeing on one protocol is important, I would still like to analyse SyncML as an alternative solution. Data manipulation will mostly be needed in wireless terminals, and there SyncML is getting widely deployed. SyncML also seems to be applicaple in this problem space. Of course it is not an IETF protocol, it is currently developed within the Open Mobile Alliance (OMA). But I think it would be sad to leave it out based on this kind of argument - anyway, SOAP is not IETF either. My proposal would be to do as has been done in some cases already. Assign a deadline for proposals (I'm not expecting there would be too many), and based on them do the selection. If no other proposals appear by the deadline, let's do SEACAP (assuming there are no major technical problems with it). We are planning to evaluate SyncML based on SEACAP, and can submit a draft for the agreed deadline, whether its use is really feasible, and if yes, how the solution would look like. A deadline sometime in April would still not delay this work considerably. (A similar approach was taken for messaging sessions last year. Basically that resulted IMHO in a somewhat messy situation, so I hope this time it would be more clear.) Then some technical comments: * Authorizations based on filters (Section 3.2.2.2.1 and 3.2.2.2.2) I have to say I don't really understand the need for some of the attributes. As I understand it ReqStatus, ReqTuples and OnEvent.Filter are related to filters in SUBSCRIBE body. I don't see it necessary to use filters as a requirement for accepting/rejecting a subscription. As I see it a filter always somehow reduces either the number or content of notifications. If I approved a subscription without a filter, I should thus always approve it with a filter. If I only wanted to give part of my tuples, I could use Content Attributes instead of approving it with a correct filter only. This way I could easier hide from a particular watcher that I have some extra information not shown to him. => My proposal would be simply to leave them out. * Notification & Content Attributes vs. Filtering The draft defines these attributes on the ACAP dataset level, and basically restricts the decisions on a limited set of PIDF attibutes, such as contact, tuple label, status type and status value. A more flexible way would perhaps be just to have a single attribute on ACAP level, which contains similar type of XPath expressions as defined in http://www.ietf.org/internet-drafts/draft-khartabil-simple-presence-filter-00.txt. In this way the ACAP structure would be very simple and would need no updates based on new reqs on attributes that authorization would like to use. => My proposal is to pursue this latter way (as speculated in the draft), obviously this requires that the solution is chosen for filtering in the first place. Also I think the relation between notifiation and content attributes shuould be clarified, as proposed in the editor's note in Chapter 3.2.2.2.2. This comment applies to filters in SUBSCRIBE as well. * Transformational attributes vs. the real needs There is a requirement (at least in 3GPP), that the presentity should be able to authorize different values of the otherwise same "data segment" to different watchers. One motivation is the ability to give different level of detail (e.g. w.r.t. location), the other simply to allow the possibility to - well, mislead. I think the current transformational attributes help in this, but don't solve it well enough. The solution I have in mind is that there would really be separate tuples, out of which only one is given to a particular watcher based on authentication rules. Maybe using different labels and authorizing them separately would be sufficient. In this case I'm not sure whether there are other specific needs for the transformational attributes. BTW, are we going to allow transform requests in the SUBSCRIBE filters? I don't see this necessary. I like the derived permissions and authorization capabilities dataset classes. One question: Would it be possible to use somehow the same list of "entities" for both presence list and for authorization. OnList attribute seems to point to this direction, but perhaps the better way would be to inherit from some commonly usable dataset ("generic list"). I don't know whether this could be done in ACAP. From users point of view it would make sense. Sharing groups among apps is quite valuable. Regards, Markus > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 23 February, 2003 19:34 > To: simple@ietf.org > Subject: [Simple] new I-Ds on data manipulation > > > Folks, > > I've submitted an update to the data manipulation requirements spec. > Until it appears, you can find it at: > > http://www.jdrosen.net/papers/draft-ietf-simple-data-req-01.txt > > There are a bunch of changes, most significantly is the > removal of this > whole script concept that was there before. > > I've also worked on a protocol mechanism to meet these requirements. > ACAP is a pretty good fit > (ftp://ftp.rfc-editor.org/in-notes/rfc2244.txt), so I worked > through how > to do this with ACAP. The result is a spec which documents an ACAP > "dataset class", as its called, which is really a schema for data. > Besides meeting the requirements, it has some useful extension and > capability discovery mechanisms that are valuable. I am pretty happy > with it, and the acap data model was a pretty natural fit for > this kind > of thing. > > As it turns out, ACAP as a protocol doesnt quite meet the > requirements. > So, the document propose to pursue a SOAP encoding of ACAP > (which I've > dubbed SEACAP), along with a new event package, to meet the > requirements. The same dataset class would be used, and most of the > semantics of acap too. > > Until it appears in the archives, you can pick up a copy at: > http://www.jdrosen.net/papers/draft-rosenberg-simple-acap-data-00.txt > http://www.jdrosen.net/papers/draft-rosenberg-simple-acap-data-00.html > > We need to determine if this is the direction we want the data > manipulation work to go. If so, I will begin drafting the > SEACAP details > and the corresponding event package. > > Time is pressing, since 3gpp deadlines are beginning to loom large... > > 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@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 12:13:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12040 for ; Thu, 27 Feb 2003 12:13:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RHN8a04673 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 12:23:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHN8p04670 for ; Thu, 27 Feb 2003 12:23:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12016 for ; Thu, 27 Feb 2003 12:12:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHN4p04645; Thu, 27 Feb 2003 12:23:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHLip04521 for ; Thu, 27 Feb 2003 12:21:44 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11950 for ; Thu, 27 Feb 2003 12:11:08 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1RHIDm25688 for ; Thu, 27 Feb 2003 19:18:13 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Feb 2003 19:15:03 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 19:15:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194518A@esebe013.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLefn1f6XS5k4QGRT6us1P6DwGIswAAhW8A To: , , , , X-OriginalArrivalTime: 27 Feb 2003 17:15:03.0302 (UTC) FILETIME=[C42ADA60:01C2DE83] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RHLip04522 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 19:15:03 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Maybe I'm missing something here, but as I see it, in order to do garbage collection, the composer needs to assign PUAs to refresh their publications in certain intervals. The shorter this refresh period is, the more efficient the garbage collection is; the longer the period, the more garbage state will be around. Now I agree that a large Expires would seem to accomplish the hard-state publication, but to what value do we draw the line? When will the composer simply accept a long lasting publication, and not reduce the Expires value to its local default to enable efficient garbage collection? I think the problem is that the Expires has dual meening in this case. It implies the lifetime of the presence info, as well as the validity period of the publication. Unless we standardize a value for Expires, after which it becomes solely the lifetime of the presence info (to indicate that the state is not to be garbage collected), different systems will behave differently. What if we define this explicitly, say Expires=0, or Expires=4294967295 means this is meant to be stored "indefinitely"? Cheers, Aki > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: 27 February, 2003 18:37 > To: Niemi Aki (NMP/Helsinki); jon.peterson@neustar.biz; > Isomaki Markus > (NRC/Helsinki); Kiss Krisztian (NRC/Tampere); simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > A suitably large Expires value would probably not > > work with any composer that wishes to do garbage > > collection in a reasonable way. It would instead > > lower the value to one that conforms with its local > > policy. > > This I don't quite understand. Either the composer > is going to authorize you to store state for a > long time or its not. Why would the composer be > more willing to store hard-state vs. state that > lasts a very long time? > > > So instead, what if we define the semantics of a > > PUBLISH without an Expires header to accomplish > > this? In other words, a PUBLISH without an Expires > > header wouldn't expire, and would instead "initiate > > the composer" with a default status. > > I would prefer that a PUBLISH without an Expires > header be reserved to mean that the client wishes > the server to choose an expiration value for the > publication. > > > > > Cheers, > > Aki > > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 15:37:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21098 for ; Thu, 27 Feb 2003 15:37:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RKlNU20144 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 15:47:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKlNp20141 for ; Thu, 27 Feb 2003 15:47:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21059 for ; Thu, 27 Feb 2003 15:36:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKlJp20132; Thu, 27 Feb 2003 15:47:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKl0p20092 for ; Thu, 27 Feb 2003 15:47:00 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21048 for ; Thu, 27 Feb 2003 15:36:20 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1RKeEC22470; Thu, 27 Feb 2003 20:40:15 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 15:40:23 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E70@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Drage, Keith (Keith)'" , simple@ietf.org Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-publish-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 15:40:21 -0500 Yes, um, that would be my fault. I thought I had removed instances of Facet and Stream from the document entirely. The examples are in error. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Thursday, February 27, 2003 5:37 AM > To: simple@ietf.org > Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-publish-00.txt > > > I assume this draft is meant to be the next stage in the > progress of the work resulting from > draft-olson-simple-publish-01.txt, and that document is now obsolete. > > Can you clarify what is the current intention of the authors > with regard to the header definitions. Facet and Stream are > still in the examples, but there are no longer any definitions. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: 27 February 2003 12:46 > > Cc: simple@ietf.org > > Subject: [Simple] I-D ACTION:draft-ietf-simple-publish-00.txt > > > > > > 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 : SIMPLE Presence Publication Mechanism > > Author(s) : B. Campbell et al. > > Filename : draft-ietf-simple-publish-00.txt > > Pages : 18 > > Date : 2003-2-26 > > > > This document describes an extension to the Session Initiation > > Protocol (SIP) [1]. The purpose of this extension to create a means > > for publishing event state used within the framework for SIP Event > > Notification (RFC3265 [2]). The first application of this extension > > is targeted at the publication of presence information as defined by > > the SIMPLE [7] working group. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-publish-00.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-publish-00.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-publish-00.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. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 15:46:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22317 for ; Thu, 27 Feb 2003 15:46:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RKu8f20643 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 15:56:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKu8p20640 for ; Thu, 27 Feb 2003 15:56:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22258 for ; Thu, 27 Feb 2003 15:45:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKu4p20632; Thu, 27 Feb 2003 15:56:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKtqp20534 for ; Thu, 27 Feb 2003 15:55:52 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22226 for ; Thu, 27 Feb 2003 15:45:13 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1RKn8C22685; Thu, 27 Feb 2003 20:49:08 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 15:49:17 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E72@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "Simpletons (E-mail)" Cc: "'rsparks@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] agenda requests for ietf56 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Feb 2003 15:49:13 -0500 There are a number of new SIMPLE drafts out for this coming IETF, and the chairs are now accepting requests for agenda time in SIMPLE. Please send requests to Robert and myself. Jon Peterson NeuStar, Inc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Feb 27 18:36:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27839 for ; Thu, 27 Feb 2003 18:36:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RNkCA31537 for simple-archive@odin.ietf.org; Thu, 27 Feb 2003 18:46:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RNkCp31534 for ; Thu, 27 Feb 2003 18:46:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27825 for ; Thu, 27 Feb 2003 18:35:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RNk8p31524; Thu, 27 Feb 2003 18:46:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RNj6p31483 for ; Thu, 27 Feb 2003 18:45:06 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27808 for ; Thu, 27 Feb 2003 18:34:22 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1RNb1202017 for ; Fri, 28 Feb 2003 01:37:02 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Feb 2003 01:38:17 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Feb 2003 01:38:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701428E3A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] draft-ietf-simple-publish-reqs-00 Thread-Index: AcLd0T/MPC3nreBvT7mC5HbAyI7nbQAe8hHA To: , , , , X-OriginalArrivalTime: 27 Feb 2003 23:38:16.0641 (UTC) FILETIME=[4D43F310:01C2DEB9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RNj6p31484 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 28 Feb 2003 01:38:16 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit When you send a NOTIFY with status of CLOSED. Is that soft state? does it expire? I guess not. So, we have some sort of hard state. How else would I interpret a status of closed? Could it be like the following: - whatever is published in a tuple is soft state. - When the state published expires, we default to the hard state (this could be open or closed). Are you Sean suggesting that this hard state is not set using the PUBLISH message? Regards, Hisham > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Wednesday, February 26, 2003 9:55 PM > To: Niemi Aki (NMP/Helsinki); Isomaki Markus (NRC/Helsinki); Kiss > Krisztian (NRC/Tampere); simple@ietf.org > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > The argument that there is some 'hard state' that exists in > the absence of > any publications (namely, the state or document expressing > that the user is > away) is in some ways attractive, yes. You are correct that a > registrar > doesn't supply null contact addresses or something when the > user in question > has no registration, but rather provides a specific failure > response. Of > course, the events framework has a different semantics - > subscriptions are > accepted when there is currently no published presence > information for a > user. Sending a failure response wouldn't be workable. > > There are, however, a couple of NOTIFY syntaxes that might > communicate that > there is no available presence information. One is that a > NOTIFY might not > contain any body. Another is that the presence agent or > compositor invents a > simple tuple that contains a status of CLOSED. The latter > option may sound a > lot like hard state, whereas the former does not. Whether or > not the latter > option is really 'state' though is debatable - almost an > implementation > question. Having a default response to queries in the absence > of state does > not, in and of itself, constitute state in my opinion. It > does not require, > for example, per-user tables in memory that have some > specific values, as > far as I can imagine how it would be implemented. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > Sent: Wednesday, February 26, 2003 3:23 AM > > To: jon.peterson@neustar.biz; Markus.Isomaki@nokia.com; > > krisztian.kiss@nokia.com; simple@ietf.org > > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 > > > > > > Hi, > > > > Few comments inline. BTW, a good set of requirements. > > > > Cheers, > > Aki > > > [snip] > > > > > Of course, some sort of management interface could be > > > defined so that users > > > could do their own manual garbage collection. But that would > > > be annoying. > > > The REGISTER model, in which stale information automatically > > > goes away for > > > you, is much more suitable to real-time communications. > > > > Similarly, when all devices are off, or out of coverage, I > > would like to see a presence document that says *something* > > even though that something is unavailable at the moment. > > > > Just like when I get a 480 and not 404 back when the callee > > is in an unregistered state. > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 28 04:10:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17980 for ; Fri, 28 Feb 2003 04:10:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S9LNl10678 for simple-archive@odin.ietf.org; Fri, 28 Feb 2003 04:21:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S9LMp10675 for ; Fri, 28 Feb 2003 04:21:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17971 for ; Fri, 28 Feb 2003 04:10:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S9LIp10659; Fri, 28 Feb 2003 04:21:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S9J4p10539 for ; Fri, 28 Feb 2003 04:19:04 -0500 Received: from web41506.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17959 for ; Fri, 28 Feb 2003 04:08:09 -0500 (EST) Message-ID: <20030228091205.93012.qmail@web41506.mail.yahoo.com> Received: from [193.12.63.119] by web41506.mail.yahoo.com via HTTP; Fri, 28 Feb 2003 01:12:05 PST From: Sean Olson Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00 To: hisham.khartabil@nokia.com, jon.peterson@neustar.biz, aki.niemi@nokia.com, Markus.Isomaki@nokia.com, krisztian.kiss@nokia.com, simple@ietf.org In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701428E3A@esebe019.ntc.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 28 Feb 2003 01:12:05 -0800 (PST) --- hisham.khartabil@nokia.com wrote: > When you send a NOTIFY with status of CLOSED. Is > that soft state? does it expire? I guess not. So, we > have some sort of hard state. How else would I > interpret a status of closed? Hmmm. Does this mean you would expect a PUA to store this status persistently? The NOTIFY is a snapshot of state at a particular point in time. It can be considered to expire when the subscription expires --- after your subscription expires, there is no way to refresh this state other than re-subscribing. I would interpret the state in the NOTIFY to endure until another NOTIFY is received or until the subscription expires, whichever comes first. > > Could it be like the following: > - whatever is published in a tuple is soft state. > - When the state published expires, we default to > the hard state (this could be open or closed). That is exactly what I had in mind. The only open issue is how to set this hard state. I believe this is best done through a separate administrative interface and not through PUBLISH. I'm open to other opinions. If someone can come up with a simple mechanism for indicating hard state in the PUBLISH request, I don't have any strong objections to doing this. > > Are you Sean suggesting that this hard state is not > set using the PUBLISH message? That's my opinion. Again, I'm open to being proven wrong. > Regards, > Hisham > > > -----Original Message----- > > From: ext Peterson, Jon > [mailto:jon.peterson@neustar.biz] > > Sent: Wednesday, February 26, 2003 9:55 PM > > To: Niemi Aki (NMP/Helsinki); Isomaki Markus > (NRC/Helsinki); Kiss > > Krisztian (NRC/Tampere); simple@ietf.org > > Subject: RE: [Simple] > draft-ietf-simple-publish-reqs-00 > > > > > > > > The argument that there is some 'hard state' that > exists in > > the absence of > > any publications (namely, the state or document > expressing > > that the user is > > away) is in some ways attractive, yes. You are > correct that a > > registrar > > doesn't supply null contact addresses or something > when the > > user in question > > has no registration, but rather provides a > specific failure > > response. Of > > course, the events framework has a different > semantics - > > subscriptions are > > accepted when there is currently no published > presence > > information for a > > user. Sending a failure response wouldn't be > workable. > > > > There are, however, a couple of NOTIFY syntaxes > that might > > communicate that > > there is no available presence information. One is > that a > > NOTIFY might not > > contain any body. Another is that the presence > agent or > > compositor invents a > > simple tuple that contains a status of CLOSED. The > latter > > option may sound a > > lot like hard state, whereas the former does not. > Whether or > > not the latter > > option is really 'state' though is debatable - > almost an > > implementation > > question. Having a default response to queries in > the absence > > of state does > > not, in and of itself, constitute state in my > opinion. It > > does not require, > > for example, per-user tables in memory that have > some > > specific values, as > > far as I can imagine how it would be implemented. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: aki.niemi@nokia.com > [mailto:aki.niemi@nokia.com] > > > Sent: Wednesday, February 26, 2003 3:23 AM > > > To: jon.peterson@neustar.biz; > Markus.Isomaki@nokia.com; > > > krisztian.kiss@nokia.com; simple@ietf.org > > > Subject: RE: [Simple] > draft-ietf-simple-publish-reqs-00 > > > > > > > > > Hi, > > > > > > Few comments inline. BTW, a good set of > requirements. > > > > > > Cheers, > > > Aki > > > > > [snip] > > > > > > > Of course, some sort of management interface > could be > > > > defined so that users > > > > could do their own manual garbage collection. > But that would > > > > be annoying. > > > > The REGISTER model, in which stale > information automatically > > > > goes away for > > > > you, is much more suitable to real-time > communications. > > > > > > Similarly, when all devices are off, or out of > coverage, I > > > would like to see a presence document that says > *something* > > > even though that something is unavailable at the > moment. > > > > > > Just like when I get a 480 and not 404 back when > the callee > > > is in an unregistered state. > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 28 07:26:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22979 for ; Fri, 28 Feb 2003 07:26:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SCb8Y22537 for simple-archive@odin.ietf.org; Fri, 28 Feb 2003 07:37:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCb8p22532 for ; Fri, 28 Feb 2003 07:37:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22828 for ; Fri, 28 Feb 2003 07:26:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCb4p22433; Fri, 28 Feb 2003 07:37:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCaLp22282 for ; Fri, 28 Feb 2003 07:36:21 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22637; Fri, 28 Feb 2003 07:25:22 -0500 (EST) Message-Id: <200302281225.HAA22637@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-kiss-simple-winfo-filter-reqs-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 28 Feb 2003 07:25:22 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Filtering of Watcher Information Author(s) : K. Kiss, E. Leppanen, H. Khartabil Filename : draft-kiss-simple-winfo-filter-reqs-00.txt Pages : 7 Date : 2003-2-27 This document defines a set of structured requirements whereby a watcher information subscriber (client) may select specific information to be received in the watcherinfo notification sent by the notifier (server). The purpose is to limit the content so that only essential information is delivered by the server. Also the preference for full or partial state information is considered in requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kiss-simple-winfo-filter-reqs-00.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-kiss-simple-winfo-filter-reqs-00.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-kiss-simple-winfo-filter-reqs-00.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: <2003-2-27132834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kiss-simple-winfo-filter-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kiss-simple-winfo-filter-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27132834.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Feb 28 08:55:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28561 for ; Fri, 28 Feb 2003 08:55:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SE6G730047 for simple-archive@odin.ietf.org; Fri, 28 Feb 2003 09:06:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SE6Gp30044 for ; Fri, 28 Feb 2003 09:06:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28521 for ; Fri, 28 Feb 2003 08:55:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SE6Bp30016; Fri, 28 Feb 2003 09:06:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SE5Lp29974 for ; Fri, 28 Feb 2003 09:05:21 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28451 for ; Fri, 28 Feb 2003 08:54:19 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1SDwG6R025991 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 28 Feb 2003 08:58:16 -0500 (EST) Message-ID: <3E5F6AFE.3010800@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: multipart/mixed; boundary="------------030706010709050202050404" Subject: [Simple] [Fwd: I-D ACTION:draft-schulzrinne-simple-iscomposing-00.txt] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 28 Feb 2003 08:58:22 -0500 This is a multi-part message in MIME format. --------------030706010709050202050404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------030706010709050202050404 Content-Type: message/rfc822; name="I-D ACTION:draft-schulzrinne-simple-iscomposing-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-schulzrinne-simple-iscomposing-00.txt" Return-Path: Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h1SD0Y714146; Fri, 28 Feb 2003 08:00:34 -0500 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id h1SD0X0B024831; Fri, 28 Feb 2003 08:00:33 -0500 (EST) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18ojjc-0008Ho-00 for ietf-announce-list@ran.ietf.org; Fri, 28 Feb 2003 07:35:28 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18ojjD-0008Cj-00 for all-ietf@ran.ietf.org; Fri, 28 Feb 2003 07:35:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22431 for ; Fri, 28 Feb 2003 07:24:24 -0500 (EST) Message-Id: <200302281224.HAA22431@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-schulzrinne-simple-iscomposing-00.txt Date: Fri, 28 Feb 2003 07:24:24 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-Spam-Status: No, hits=4.6 required=5.0 tests=AWL,MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : is-composing Indication for Instant Messaging Using the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne Filename : draft-schulzrinne-simple-iscomposing-00.txt Pages : 8 Date : 2003-2-27 In instant messaging systems, it is useful to know that the other party is composing a message, e.g., typing. This document defines a new content type and XML namespace that conveys information about a message being composed. The message could be of any type, including text, voice or video A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schulzrinne-simple-iscomposing-00.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-schulzrinne-simple-iscomposing-00.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-schulzrinne-simple-iscomposing-00.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: <2003-2-27132652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-schulzrinne-simple-iscomposing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-schulzrinne-simple-iscomposing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27132652.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------030706010709050202050404-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple