From simple-admin@mailman.dynamicsoft.com Fri Mar 1 01:53:00 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07232 for ; Fri, 1 Mar 2002 01:53:00 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g216mcZq005564; Fri, 1 Mar 2002 01:48:39 -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 BAA18071; Fri, 1 Mar 2002 01:50:04 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18058 for ; Fri, 1 Mar 2002 01:49:05 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.62]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g216nE6Y021194 for ; Fri, 1 Mar 2002 01:49:14 -0500 (EST) Message-ID: <3C7F2433.851EE7B5@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] updated presence spec Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 01 Mar 2002 01:48:19 -0500 Content-Transfer-Encoding: 7bit Folks, I've just submitted an update to the main presence spec. Until it appears in the archives, you can grab a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-presence-05.txt The changes since -04 are: * alignment with sip-events-04 * alignment with bis-09 * removal of 3/4 examples, remaining example doesn't show PIDF any more (we kept getting out of sync) * additional words on security, mentioning the new SIPS and S/MIME capabilities for SIP * removal of text redundant with sip-events and bis * added a recommendation that PUA implement this package, to allow for a PA to obtain user presence by subscribing to the various PUA * added formal IANA registration of the presence package * broke references into normative and informative * added 2119 terminology section This document had already completed working group last call, and was merely parked behind sip-events. Now that those are done, we can move forward. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 1 05:02:33 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03024 for ; Fri, 1 Mar 2002 05:02:33 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g219xwZq007209 for ; Fri, 1 Mar 2002 04:59:58 -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 FAA20179 for ; Fri, 1 Mar 2002 05:02:51 -0500 (EST) Date: Fri, 1 Mar 2002 05:02:51 -0500 (EST) Message-Id: <200203011002.FAA20179@mailman.dynamicsoft.com> Subject: mailman.dynamicsoft.com mailing list memberships reminder From: mailman-owner@mailman.dynamicsoft.com To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk This is a reminder, sent out once a month, about your mailman.dynamicsoft.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@mailman.dynamicsoft.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@mailman.dynamicsoft.com. Thanks! Passwords for simple-archive@lists.ietf.org: List Password // URL ---- -------- simple@mailman.dynamicsoft.com ifheto http://mailman.dynamicsoft.com/mailman/options/simple/simple-archive%40lists.ietf.org From simple-admin@mailman.dynamicsoft.com Fri Mar 1 10:05:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28848 for ; Fri, 1 Mar 2002 10:05:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g21F0aZq009518; Fri, 1 Mar 2002 10:00:36 -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 KAA22480; Fri, 1 Mar 2002 10:02:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22468 for ; Fri, 1 Mar 2002 10:01:28 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g21F0QZ21467 for ; Fri, 1 Mar 2002 07:00:36 -0800 (PST) Received: from oranlt ([161.44.238.50]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACD60520; Fri, 1 Mar 2002 07:00:34 -0800 (PST) From: "David R. Oran" To: Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) Organization: Cisco Systems Message-ID: <041201c1c131$d33db740$32ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <200202281724.MAA04612@dynasty.cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 1 Mar 2002 10:00:27 -0500 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > Petri K. Koskelainen > Sent: Thursday, February 28, 2002 12:24 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Re: > draft-rosenberg-simple-components-00.txt (threading) > > > > Hi, > > The draft proposes that In-Reply-To header should > be used for message threading in paging mode, > and the draft also states that in message session > mode threading is already provided. > > I don't fully agree here. It works for two-party messaging > but not well in group messaging scenarios. > > Problem 1: Message session supports only one discussion thread > per session. > This does not well reflect real-life scenarios. > For example, there may be a group chat session with 20 people. > It is very likely that they have different > conversation topics going-on at the same time although they > are in the same group. It is also likely that smaller > sub-threads emerge and it would be nice if these can be > somehow shown in the user interface similarly to current > network news UIs. For example, if there are several questions > asked in the group and users respond with "yes!" or "no" in > the message body it is > quite difficult to know to which question they were intended. > User Interface could show them nicely if there were header support > for it. > Actually, I think there are two related, but not identical problems to be solved here. One is the logical grouping of messages by thread/topic, for which In-reply-to: is helpful but not completely adequate. The second is constructing a causal order of the messages in a multi-party chat session. In-reply-to can in fact be used for this, as long as each message is in fact tagged with the message-id of the message that provoked it (some UI support is of course needed to identify this). However, this usage would conflict with the classical threading usage we see in newsgroups. I think the threading/topic stuff would best be solved with adding a hierarchical structure to the Subject: (or In-reply-to) header, or a new header, such as "context:" and some conventions thereto, as was suggested. However, that leaves the problem of how to establish the causal order if the In-reply-to header is used. For that, I believe a new header would be called for. I frankly find a causal order more useful than a threading feature, but that may just be me... > > Problem 2: Group messaging server creates new Call-IDs for > each call-leg. In-Reply-To has also problems in group IM > paging mode since the server creates new Call-IDs for each > participant. One call-id is valid only between one user and > the server. The server has to remember all previous Call-IDs > so it can change Call-IDs in In-Reply-To accordingly when somebody > is responding to group message. > It must have the history and know that a message it sent to Bob > a day ago with Call-ID=X is in fact the same message than > message sent to Alice with Call-ID=Y. This becomes quite complicated. > This would argue for "in-reply-to" (and whatever we use for causal order) having a global scope as opposed to a dialog/call scope, right. If we did this and tied the context to the URI of the group chat and not the dialog, this problem would go away, right? > > Problem 3: Lack of global and common ID for each group > message. Now it is difficult to reference a specific group > instant message afterwards so that everybody understands it. > Only the server has the knowledge (if it keeps the history). > The recipients don't know that group IM sent to me with > Call-ID=X is the same than group IM sent to Alice with > Call-ID=Y. In some cases it would be useful to have the > information available in the message. > > > These problems can be solved if new header (Message-ID) > is defined and References header is used (like in NNTP messages). > This would work, I think, and if my proposal for causal orders used this as the referent we could get a long way toward a nice system model. > > BR, > -- > Petri > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinf> o/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Mar 2 14:41:18 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03917 for ; Sat, 2 Mar 2002 14:41:18 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g22JcKZq017176; Sat, 2 Mar 2002 14:38:21 -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 OAA27605; Sat, 2 Mar 2002 14:41:06 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27594 for ; Sat, 2 Mar 2002 14:40:14 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g22JeK6Y023500 for ; Sat, 2 Mar 2002 14:40:20 -0500 (EST) Message-ID: <3C812A6D.BA894505@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] watcherinfo format draft Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sat, 02 Mar 2002 14:39:25 -0500 Content-Transfer-Encoding: 7bit I submitted an update to the watcher info XML specification. This update basically reflects comments during last call, along with alignment with sip-events-04. Until it appears, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-winfo-format-01.txt Changes since -00: * Changed first-subscribed to refer to the time the subscribe was first received for this subscription, rather than the first EVER across subscriptions. * Removed notify-address element * Added expiration parameter. * Removed most-recently-subscribed as per IETF 52 agreement. * Alignment with sip-events-04 * Generalized to any package, not just presence -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 4 02:52:00 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16605 for ; Mon, 4 Mar 2002 02:52:00 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g247mJZq020694; Mon, 4 Mar 2002 02:48:19 -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 CAA04068; Mon, 4 Mar 2002 02:51:05 -0500 (EST) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04056 for ; Mon, 4 Mar 2002 02:50:39 -0500 (EST) Received: from d23rh902.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 2.0) with ESMTP id g247iox127394 for ; Mon, 4 Mar 2002 17:44:50 +1000 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g247p5D51006 for ; Mon, 4 Mar 2002 18:51:06 +1100 To: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 04/03/2002 15:50:00 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] watcher info problem in PA/Proxy/Registrar model Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 4 Mar 2002 15:49:57 +0800 Hi,all Using a PA/Proxy/Registrar model, I find it's difficult for PS to handle Event:presence.winfo subscription. If a Event:presence subscription is proxying (when PS acts as a proxy), PS can't get to know the watcher status anymore. That means if a presentity wants to learn who have subscribed to its presence by sending a Event:presence.winfo subscription, PS can only return watcher info about which status is pending or waiting. So I doubt the PA/Proxy/Registrar model again. Is there any good solution to this? Best regards, Tang Lihua Email: tanglih@cn.ibm.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 4 06:40:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19960 for ; Mon, 4 Mar 2002 06:40:56 -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 g24BbDT8000626; Mon, 4 Mar 2002 06:37:14 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00675; Mon, 4 Mar 2002 06:40:06 -0500 (EST) Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id GAA00662 for ; Mon, 4 Mar 2002 06:39:57 -0500 (EST) Received: (qmail 10160 invoked by alias); 4 Mar 2002 11:39:09 -0000 Received: from unknown (HELO indigosw.com) (194.78.202.25) by 0 with SMTP; 4 Mar 2002 11:39:09 -0000 Message-ID: <3C835CDC.1070309@indigosw.com> From: Torrey Searle Organization: Indigo Software, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Re: is there any draft for presence Status Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 04 Mar 2002 12:39:08 +0100 Content-Transfer-Encoding: 7bit In the CPIM draft, it says that the values for the status-type:im will be defined in a later document. Does this document exist, and if so where? Torrey Searle Indigo Software tsearle@indigosw.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 4 07:10:33 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21064 for ; Mon, 4 Mar 2002 07:10:32 -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 g24C7BT8000750; Mon, 4 Mar 2002 07:07:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00787; Mon, 4 Mar 2002 07:10:03 -0500 (EST) Received: from mailnpd.hcltech.com ([203.197.145.76]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id HAA00774 for ; Mon, 4 Mar 2002 07:09:53 -0500 (EST) Received: from npd.hcltech.com ([192.168.100.97]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g24BxNm29886; Mon, 4 Mar 2002 17:29:24 +0530 Message-ID: <3C836322.C5B06E1D@npd.hcltech.com> From: Abdul Rahman Kadir Organization: HCL Technologies X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Pls give some info in PS operation ? Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 04 Mar 2002 17:35:54 +0530 Content-Transfer-Encoding: 7bit Hi Can some one help me understanding the foll. in Presence server operation? 1. Can the SUBSCRIBE request received at the Presence Server be REJECTED immediatelty after authentication process is over if there is no access permission for the subscriber or due to any other reason ?. or SUBSCRIBE request MUST always come to PENDING State before getting REJECTED ? - that is, Presence Server will move to pending state as no access permission given for subscriber at present (presentity not alive) and will try get it authorized . And so after some time slot,it decides to REJECT since subscriber not authorized so far. 2. Will there be any access-list present for the subscriber in the PS while the presentity is off-line. thanks Abdul Rahman _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 4 19:31:08 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01494 for ; Mon, 4 Mar 2002 19:31:08 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g250RPT8007244; Mon, 4 Mar 2002 19:27:25 -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 TAA03234; Mon, 4 Mar 2002 19:30:14 -0500 (EST) Received: from pteam.dfw.dynamicsoft.com (pteam.dfw.dynamicsoft.com [63.110.3.12]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03221 for ; Mon, 4 Mar 2002 19:29:38 -0500 (EST) Received: from txbcampbell (pteam.dfw.dynamicsoft.com [63.110.3.12]) by pteam.dfw.dynamicsoft.com (8.9.3/8.9.3) with SMTP id TAA10807; Mon, 4 Mar 2002 19:37:47 -0600 From: "Ben Campbell" To: "Abdul Rahman Kadir" , Subject: RE: [Simple] Pls give some info in PS operation ? 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: <3C836322.C5B06E1D@npd.hcltech.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 4 Mar 2002 18:27:54 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Abdul Rahman > Kadir > Sent: Monday, March 04, 2002 6:06 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Pls give some info in PS operation ? > > > Hi > > Can some one help me understanding the foll. in Presence server > operation? > > > > 1. Can the SUBSCRIBE request received at the Presence Server be > REJECTED immediatelty after authentication process is over if > there is no access permission for the subscriber or due to any > other reason ?. > > or SUBSCRIBE request MUST always come to PENDING State before > getting REJECTED ? - that is, Presence Server will move to pending > state as no access permission given for subscriber at present > (presentity not alive) and will try get it authorized . > And so after some time slot,it decides to REJECT since subscriber > not authorized so far. > If the PS can make an immediate decision on the matter, then there is no need for a pending state. It can just reject the subscription with an appropriate 400 or 600 class response. > 2. Will there be any access-list present for the subscriber in the > PS while the presentity is off-line. This depends entirely on the application design and local policy. It is certainly possible to build a presence service where that is true. > > > thanks > Abdul Rahman > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 4 19:57:38 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02392 for ; Mon, 4 Mar 2002 19:57:38 -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 g250s9T8007389; Mon, 4 Mar 2002 19:54:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03336; Mon, 4 Mar 2002 19:57:02 -0500 (EST) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03325 for ; Mon, 4 Mar 2002 19:56:10 -0500 (EST) Received: from d23rh902.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g250pAn215312 for ; Tue, 5 Mar 2002 10:51:10 +1000 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g250ucH86054 for ; Tue, 5 Mar 2002 11:56:38 +1100 Subject: Re: [Simple] Pls give some info in PS operation ? To: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Wei BJ Lu" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 05/03/2002 08:55:33 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 5 Mar 2002 08:56:40 +0800 See my comments below, starting from ">>>" ------------------------------ Dr. LU Wei Staff Research Member Infrastructure Technology IBM China Research Lab Phone: (8610)62986677-549 Tie-line: 905-549 Fax: (8610)82899634 Email: luw@cn.ibm.com Abdul Rahman Kadir To: simple@mailman.dynamicsoft.com Sent by: cc: simple-admin@mailman.dynam Subject: [Simple] Pls give some info in PS operation ? icsoft.com 2002-03-04 20:05 Please respond to Abdul Rahman Kadir Hi Can some one help me understanding the foll. in Presence server operation? 1. Can the SUBSCRIBE request received at the Presence Server be REJECTED immediatelty after authentication process is over if there is no access permission for the subscriber or due to any other reason ?. or SUBSCRIBE request MUST always come to PENDING State before getting REJECTED ? - that is, Presence Server will move to pending state as no access permission given for subscriber at present (presentity not alive) and will try get it authorized . And so after some time slot,it decides to REJECT since subscriber not authorized so far. >>>The latter one. If the Presence Server cannot find a policy to authorize the incoming subscription, it should move to pending state and wait for the presentity to define a policy for the new watcher. 2. Will there be any access-list present for the subscriber in the PS while the presentity is off-line. >>> Yes. Even if the presentity goes offline, its access list thanks Abdul Rahman _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 4 20:02:39 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02547 for ; Mon, 4 Mar 2002 20:02:39 -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 g250xAT8007517; Mon, 4 Mar 2002 19:59:10 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03377; Mon, 4 Mar 2002 20:02:02 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03365 for ; Mon, 4 Mar 2002 20:01:35 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g250weT8007508; Mon, 4 Mar 2002 19:58:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 20:00:47 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36300E6@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Chiou, Mark'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Question regarding SIP-Specific Event Notification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 4 Mar 2002 20:00:45 -0500 Read the section in the draft about forking. /a > -----Original Message----- > From: Chiou, Mark [mailto:MChiou@Santera.com] > Sent: Wednesday, February 27, 2002 2:18 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Question regarding SIP-Specific Event Notification > > > Hi Adam, > > Could you explain why the immediately NOTIFY request is > required when Notifier receives a SUBSCRIBER request? For my > opinion, the 200 OK response for the SUBSCRIBER request is sufficient. > > Thanks, > > Mark > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 4 20:22:55 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03024 for ; Mon, 4 Mar 2002 20:22:54 -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 g251JOT8007681; Mon, 4 Mar 2002 20:19:24 -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 UAA03482; Mon, 4 Mar 2002 20:22:18 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03454 for ; Mon, 4 Mar 2002 20:21:33 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g251LW6Y025482; Mon, 4 Mar 2002 20:21:35 -0500 (EST) Message-ID: <3C841D64.C98CF677@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Hua Tang CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 04 Mar 2002 20:20:36 -0500 Content-Transfer-Encoding: 7bit Li Hua Tang wrote: > > Hi,all > > Using a PA/Proxy/Registrar model, I find it's difficult for PS to handle > Event:presence.winfo subscription. > > If a Event:presence subscription is proxying (when PS acts as a proxy), > PS > can't get to know the watcher status anymore. Right. > That means if a presentity > wants to learn who have subscribed to its presence by sending a > Event:presence.winfo subscription, PS can only return watcher info about > which status is pending or waiting. So I doubt the PA/Proxy/Registrar > model > again. Is there any good solution to this? The PS wouldn't terminate the subscriptions for watcher information; it would proxy them, just as it did the original presence information. The server that handles the subscriptions for some package foo needs to handle foo.winfo. This is much clearer in the next rev of the specification. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 4 20:23:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03039 for ; Mon, 4 Mar 2002 20:23:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g251J9T8007672; Mon, 4 Mar 2002 20:19:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03465; Mon, 4 Mar 2002 20:22:02 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03447 for ; Mon, 4 Mar 2002 20:20:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g251KE6Y025479; Mon, 4 Mar 2002 20:20:17 -0500 (EST) Message-ID: <3C841D16.8E0D792A@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Torrey Searle CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: is there any draft for presence Status References: <3C835CDC.1070309@indigosw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 04 Mar 2002 20:19:18 -0500 Content-Transfer-Encoding: 7bit Nope, doesn't exist AFAIK. Please go ahead and write one - its loooooonnnnnnnggggg overdue. -Jonathan R. Torrey Searle wrote: > > In the CPIM draft, it says that the values for the status-type:im will > be defined in a later document. Does this document exist, and if so > where? > > Torrey Searle > Indigo Software > tsearle@indigosw.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 4 20:53:50 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03822 for ; Mon, 4 Mar 2002 20:53:50 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g251oAT8007917; Mon, 4 Mar 2002 20:50:10 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03618; Mon, 4 Mar 2002 20:53:04 -0500 (EST) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03607 for ; Mon, 4 Mar 2002 20:52:09 -0500 (EST) Received: from d23rh902.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 2.0) with ESMTP id g251kKx104862; Tue, 5 Mar 2002 11:46:20 +1000 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g251qWH10716; Tue, 5 Mar 2002 12:52:33 +1100 Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model To: Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 05/03/2002 09:51:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 5 Mar 2002 09:51:25 +0800 Jonathan Rosenberg wrote: >The PS wouldn't terminate the subscriptions for watcher information; it >would proxy them, just as it did the original presence information. The >server that handles the subscriptions for some package foo needs to >handle foo.winfo. This is much clearer in the next rev of the >specification. Then who can terminate the subscriptions for watcher information? Let us detail two cases. These two cases have been described in draft-ietf-simple-winfo-format-01. One is a user, A, subscribes to the presence of another user, B. A would like to find out about the status of their subscription. If no PS, the subscriptions for watcher information is sent directly to B and it's easy to do handle it. If there is a PS existing between A and B, my first question is what will the To header be in SUBSCRIBE request? If it's a registered SIP address and the request may be forked, another question comes out. There is no clear definition in winfo-package-00 about how to handle this forked SUBSCRIBE requests. If the request is proxying and not forked, B will terminate this subscription. The other case is a user B, wishes to learn the set of people who have subscribed to B's presence. What is the To header of this SUBSCRIBE request? More, if the PS can't terminate this subscription, are they the set of watchers who return their watcher information to B independently? It's difficult to understand this way. Best regards, Tang Lihua Email: tanglih@cn.ibm.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 4 20:58:51 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03999 for ; Mon, 4 Mar 2002 20:58:51 -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 g251t7T8007986; Mon, 4 Mar 2002 20:55:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03658; Mon, 4 Mar 2002 20:58:02 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03647 for ; Mon, 4 Mar 2002 20:57:55 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g251vw6Y025534; Mon, 4 Mar 2002 20:57:59 -0500 (EST) Message-ID: <3C8425EC.586661D2@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Hua Tang CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 04 Mar 2002 20:57:00 -0500 Content-Transfer-Encoding: 7bit Li Hua Tang wrote: > > Jonathan Rosenberg wrote: > > >The PS wouldn't terminate the subscriptions for watcher information; it > >would proxy them, just as it did the original presence information. The > >server that handles the subscriptions for some package foo needs to > >handle foo.winfo. This is much clearer in the next rev of the > >specification. > > Then who can terminate the subscriptions for watcher information? Whatever element is terminating the presence subscriptions. > Let us > detail two cases. These two cases have been described in > draft-ietf-simple-winfo-format-01. > > One is a user, A, subscribes to the presence of another user, B. A would > like to find out about the status of their subscription. If no PS, the > subscriptions for watcher information is sent directly to B and it's > easy > to do handle it. If there is a PS existing between A and B, my first > question is what will the To header be in SUBSCRIBE request? Same as it was for the SUBSCRIBE for presence state. > If it's a > registered SIP address and the request may be forked, another question > comes out. There is no clear definition in winfo-package-00 about how to > handle this forked SUBSCRIBE requests. If the request is proxying and > not > forked, B will terminate this subscription. winfo-package-01 talks about this case. It recommends that the watcherinfo subscription be sent on the same dialog as the presence subscription. THis guarantees that the same server handling presence, is also handling watcherinfo. > > The other case is a user B, wishes to learn the set of people who have > subscribed to B's presence. What is the To header of this SUBSCRIBE > request? Same as it was for the presence subscription. > More, if the PS can't terminate this subscription, are they the > set of watchers who return their watcher information to B independently? > It's difficult to understand this way. There are two solutions for this case. Both are docuented in -01. In the first case, the PS will fork the watcherinfo subscription, and the result is that multiple subscriptions are installed. In the second case, the PS can direct the watcherinfo subscription to a server that the network has explicitly designated as the winfo server, and it knows about all watchers. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 5 02:28:48 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19773 for ; Tue, 5 Mar 2002 02:28:48 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g257PAT8008945; Tue, 5 Mar 2002 02:25:10 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04640; Tue, 5 Mar 2002 02:28:02 -0500 (EST) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04629 for ; Tue, 5 Mar 2002 02:27:20 -0500 (EST) Received: from d23rh902.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g257Lrn310940; Tue, 5 Mar 2002 17:21:54 +1000 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g257RJH47720; Tue, 5 Mar 2002 18:27:20 +1100 To: Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 05/03/2002 15:26:17 MIME-Version: 1.0 Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mailman.dynamicsoft.com id CAA04629 Subject: [Simple] id attribute of winfo format? Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 5 Mar 2002 15:26:12 +0800 Content-Transfer-Encoding: 8bit Jonathan£¬ I go to see the winfo-package-01 (at http://www.jdrosen.net/papers/draft-ietf-simple-winfo-package-01.txt) and it mentions an id attribute of winfo format. But I can't find this attribute in the latest winfo-format-01. Do I misunderstand somthing or a new version is coming soon? Best regards, Tang Lihua Email: tanglih@cn.ibm.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 5 02:51:34 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20426 for ; Tue, 5 Mar 2002 02:51:33 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g257mBT8009073; Tue, 5 Mar 2002 02:48:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04741; Tue, 5 Mar 2002 02:51:05 -0500 (EST) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04730 for ; Tue, 5 Mar 2002 02:50:34 -0500 (EST) Received: from d23rh901.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 2.0) with ESMTP id g257ikx65068; Tue, 5 Mar 2002 17:44:46 +1000 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh901.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g257oQ532636; Tue, 5 Mar 2002 18:50:27 +1100 Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model To: Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 05/03/2002 15:49:56 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 5 Mar 2002 15:49:54 +0800 Jonathan Rosenberg wrote: >It recommends that the >watcherinfo subscription be sent on the same dialog as the presence >subscription. THis guarantees that the same server handling presence, is >also handling watcherinfo. Why the same dialog? It's possible that no presence subscription hasn't been sent before a winfo subscription. And a SUBSCRIBE request for winfo will definitely create a new dialog since it has a new callID. >> More, if the PS can't terminate this subscription, are they the >> set of watchers who return their watcher information to B independently? >> It's difficult to understand this way. >There are two solutions for this case. Both are docuented in -01. In the >first case, the PS will fork the watcherinfo subscription, and the >result is that multiple subscriptions are installed. In the second case, >the PS can direct the watcherinfo subscription to a server that the >network has explicitly designated as the winfo server, and it knows >about all watchers. I'm much confused. What you have said seems selfcontradicting. Since PS will handle the presence subscription, in your opinion, the PS should be the same server to handle the winfo subscription. Return to my original question. If the PS uses PA/Proxy/Registrar model, it can't act as the winfo server at the same time. Due to the recursion, it's reasonable to colocate presence sever and winfo server. But if the SUBSCRIBE request is proxying, the server will lose control of presence status. One more point I am not very clear about winfo-package-01. Should a notification of winfo subscription return immediately? Best regards, Tang Lihua Email: tanglih@cn.ibm.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 5 03:09:35 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20719 for ; Tue, 5 Mar 2002 03:09:34 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g25869T8009166; Tue, 5 Mar 2002 03:06:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04816; Tue, 5 Mar 2002 03:09:02 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04805 for ; Tue, 5 Mar 2002 03:08:19 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2588J6Y025722; Tue, 5 Mar 2002 03:08:20 -0500 (EST) Message-ID: <3C847CBB.6423FBF4@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Hua Tang CC: simple@mailman.dynamicsoft.com References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [Simple] Re: id attribute of winfo format? Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 05 Mar 2002 03:07:23 -0500 Content-Transfer-Encoding: 8bit Li Hua Tang wrote: > > Jonathan£¬ > > I go to see the winfo-package-01 (at > http://www.jdrosen.net/papers/draft-ietf-simple-winfo-package-01.txt) > and > it mentions an id attribute of winfo format. But I can't find this > attribute in the latest winfo-format-01. Do I misunderstand somthing or > a > new version is coming soon? It will be in the -02 version. I got overzealous and submitted the format document before revving the package document. While doing the package document, I realized I needed this change to the format document. My apologies. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 5 03:13:44 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20776 for ; Tue, 5 Mar 2002 03:13:44 -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 g258A8T8009228; Tue, 5 Mar 2002 03:10:08 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04854; Tue, 5 Mar 2002 03:13:02 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04843 for ; Tue, 5 Mar 2002 03:12:57 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g258D36Y025725; Tue, 5 Mar 2002 03:13:03 -0500 (EST) Message-ID: <3C847DD7.1EE1E7EE@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Hua Tang CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 05 Mar 2002 03:12:07 -0500 Content-Transfer-Encoding: 7bit Li Hua Tang wrote: > > Jonathan Rosenberg wrote: > >It recommends that the > >watcherinfo subscription be sent on the same dialog as the presence > >subscription. THis guarantees that the same server handling presence, > is > >also handling watcherinfo. > > Why the same dialog? So that it gets to the same server handling the presence subscription. > It's possible that no presence subscription hasn't > been sent before a winfo subscription. That is not the case we are discussing. IN this case, a user wants to track the status of his own subscription to some other resource. By definition, this is a watcherinfo subscription associated with some other existing subscription. > And a SUBSCRIBE request for winfo > will definitely create a new dialog since it has a new callID. Not in this case. The meaning of sending the subscription on the same dialog is to reuse the call-id, to, from. > > >> More, if the PS can't terminate this subscription, are they the > >> set of watchers who return their watcher information to B > independently? > >> It's difficult to understand this way. > > >There are two solutions for this case. Both are docuented in -01. In > the > >first case, the PS will fork the watcherinfo subscription, and the > >result is that multiple subscriptions are installed. In the second > case, > >the PS can direct the watcherinfo subscription to a server that the > >network has explicitly designated as the winfo server, and it knows > >about all watchers. > > I'm much confused. What you have said seems selfcontradicting. Since PS > will handle the presence subscription, in your opinion, the PS should be > the same server to handle the winfo subscription. Whatever handles the presence subscription, handles the watcherinfo subscriptions. > Return to my original > question. If the PS uses PA/Proxy/Registrar model, it can't act as the > winfo server at the same time. Now to me, you are saying contradicting things. Either the PS is a PA, or it is a proxy. If its a PA, it terminates the watcherinfo subscriptions. If its a proxy, it proxies the watcherinfo subscriptions. > Due to the recursion, it's reasonable to > colocate presence sever and winfo server. But if the SUBSCRIBE request > is > proxying, the server will lose control of presence status. Whatever handles the presence subscription, handles the watcherinfo subscriptions. > > One more point I am not very clear about winfo-package-01. Should a > notification of winfo subscription return immediately? What does "return immediately" mean? It generates an immediate NOTIFY, if that is what you mean. That is true for all sip event packages. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 5 07:34:16 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26235 for ; Tue, 5 Mar 2002 07:34:15 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g25CUDT8010058; Tue, 5 Mar 2002 07:30:14 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05740; Tue, 5 Mar 2002 07:33:03 -0500 (EST) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05729 for ; Tue, 5 Mar 2002 07:32:05 -0500 (EST) Received: from d23rh901.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g258wWn12948; Tue, 5 Mar 2002 18:58:32 +1000 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh901.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2593P564160; Tue, 5 Mar 2002 20:03:26 +1100 Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model To: Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 05/03/2002 17:02:56 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 5 Mar 2002 17:02:52 +0800 Jonathan Rosenberg wrote: > > It's possible that no presence subscription hasn't > > been sent before a winfo subscription. > That is not the case we are discussing. IN this case, a user wants to > rack the status of his own subscription to some other resource. By > definition, this is a watcherinfo subscription associated with some > other existing subscription. > > And a SUBSCRIBE request for winfo > > will definitely create a new dialog since it has a new callID. > Not in this case. The meaning of sending the subscription on the same > dialog is to reuse the call-id, to, from. I can't agree with you. In order to do realtime authorization (or say, in oder to be notified as soon as being subscribed), the presentity can send winfo subscription to the PS first even if there is no presence subscription to it. It's independent on whether a watcher has subscribed or will subscribe to the resource of this presentity. It's not associated with an exsiting subscription. And it can be guaranteed that all the winfo subscriptions to one resource have the same callid since they may be generated by any watcher or the presentity itself. > Now to me, you are saying contradicting things. Either the PS is a PA, > or it is a proxy. If its a PA, it terminates the watcherinfo > subscriptions. If its a proxy, it proxies the watcherinfo subscriptions. Either the PS is a PA, or it is a proxy. Do you mean the PS can't be a combination of PA/Proxy/Registrar? Or do you mean the PS can't change the role between PA and Proxy when handling subscriptions whenever the presentity changes status (available or not)? Best regards, Tang Lihua Email: tanglih@cn.ibm.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 5 11:59:49 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09120 for ; Tue, 5 Mar 2002 11:59:44 -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 g25GuDT8012607; Tue, 5 Mar 2002 11:56:13 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06616; Tue, 5 Mar 2002 11:59:03 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05532 for ; Tue, 5 Mar 2002 06:33:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24297; Tue, 5 Mar 2002 06:32:12 -0500 (EST) Message-Id: <200203051132.GAA24297@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-05.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 05 Mar 2002 06:32:12 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Presence Author(s) : J. Rosenberg et al. Filename : draft-ietf-simple-presence-05.txt Pages : 27 Date : 04-Mar-02 This document proposes an extension to SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. Subscriptions and notifications of user presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence and Instant Messaging (CPIM) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-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-presence-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-presence-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: <20020304141759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304141759.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 6 05:10:18 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29094 for ; Wed, 6 Mar 2002 05:10:17 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g26A6JT8017873; Wed, 6 Mar 2002 05:06:19 -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 FAA09782; Wed, 6 Mar 2002 05:09:04 -0500 (EST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09771 for ; Wed, 6 Mar 2002 05:08:24 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id LAA88668 for ; Wed, 6 Mar 2002 11:07:29 +0100 Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g26A9TX92728 for ; Wed, 6 Mar 2002 11:09:29 +0100 To: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Lamine Brahimi" X-MIMETrack: Serialize by Router on D13ML006/13/M/IBM(Release 5.0.9a |January 7, 2002) at 06/03/2002 11:07:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] about Cseq sequence numbers Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 6 Mar 2002 11:07:13 +0100 Dear all, Suppose a watcher subscribes to a presentity presence info with an initial SUBSCRIBE msg with a Cseq value of 1. the watcher receives the corresponding NOTIFY with a Cseq value of 1 (the same). Then the presentity updates several times its presence info and the watcher receives several NOTIFY with incremented Cseq values. (ie if the presence info changed twice the last NOTIFY has a Cseq value of 3, right ?). Then when the watcher wants to refresh its subscription I do that: it sends a SUBSCRIBE with a CSeq value of 2 and a matching Dialog To tag. It receives its corresponding NOTIFY with a CSeq value of 2. So my (little) problem is that I have two transactions which have the same Cseq number of 2 in the same dialog : the latest NOTIFY and the first one notifying an update in Presentity presence info. Is it correct like that ? A possible solution to avoid that is to set the Cseq value of the refreshing SUBSCRIBE to a value one higher than the latest NOTIFY received in that dialog (in our case 4, if presence info changed twice before the refresh) and not the latest SUBSCRIBE sent. Does someone knows what to do ? Thanks, Lamine. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 6 05:57:41 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00444 for ; Wed, 6 Mar 2002 05:57:41 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g26As7T8018028; Wed, 6 Mar 2002 05:54:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09975; Wed, 6 Mar 2002 05:57:02 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09960 for ; Wed, 6 Mar 2002 05:55:55 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26AssZ05940 for ; Wed, 6 Mar 2002 12:54:54 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 12:54:42 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 12:54:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] about Cseq sequence numbers Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77790BA@esebe019.NOE.Nokia.com> Thread-Topic: [Simple] about Cseq sequence numbers Thread-Index: AcHE92FXAo8wUHyBS7+pdks+fbH4fwABXWLQ To: , X-OriginalArrivalTime: 06 Mar 2002 10:54:44.0052 (UTC) FILETIME=[52F32140:01C1C4FD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA09960 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 6 Mar 2002 12:54:43 +0200 Content-Transfer-Encoding: 8bit The SUBSCRIBE CSeq and NOTIFY CSeq are independent. Your Subscription refresh carried a Cseq of 2. The NOTIFY following that should carry a Cseq of 5. When receiving a NOTIFY, all you do is update the Dialog state with the new remote Cseq. Regards, Hisham > -----Original Message----- > From: ext Lamine Brahimi [mailto:LAM@zurich.ibm.com] > Sent: Wednesday, March 06, 2002 12:07 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] about Cseq sequence numbers > > > > Dear all, > > Suppose a watcher subscribes to a presentity presence info with > an initial SUBSCRIBE msg with a Cseq value of 1. > the watcher receives the corresponding NOTIFY with a Cseq > value of 1 (the > same). > Then the presentity updates several times its presence info > and the watcher > receives several NOTIFY with incremented Cseq values. (ie if > the presence > info changed twice > the last NOTIFY has a Cseq value of 3, right ?). > Then when the watcher wants to refresh its subscription I do that: > it sends a SUBSCRIBE with a CSeq value of 2 and a matching > Dialog To tag. > It receives its corresponding NOTIFY with a CSeq value of 2. > So my (little) problem is that I have two transactions which > have the same > Cseq number of 2 in the same dialog : > the latest NOTIFY and the first one notifying an update in Presentity > presence info. > Is it correct like that ? > A possible solution to avoid that is to set the Cseq value of the > refreshing SUBSCRIBE to a value one > higher than the latest NOTIFY received in that dialog (in our > case 4, if > presence info changed twice before the refresh) > and not the latest SUBSCRIBE sent. > > Does someone knows what to do ? > Thanks, > Lamine. > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 6 11:22:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15842 for ; Wed, 6 Mar 2002 11:22:05 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g26GIFT8020525; Wed, 6 Mar 2002 11:18:15 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10946; Wed, 6 Mar 2002 11:21:04 -0500 (EST) Received: from pteam.dfw.dynamicsoft.com (pteam.dfw.dynamicsoft.com [63.110.3.12]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10934 for ; Wed, 6 Mar 2002 11:20:08 -0500 (EST) Received: from txbcampbell (pteam.dfw.dynamicsoft.com [63.110.3.12]) by pteam.dfw.dynamicsoft.com (8.9.3/8.9.3) with SMTP id LAA27050; Wed, 6 Mar 2002 11:28:09 -0600 From: "Ben Campbell" To: "Lamine Brahimi" , Subject: RE: [Simple] about Cseq sequence numbers 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 6 Mar 2002 10:18:09 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Lamine Brahimi > Sent: Wednesday, March 06, 2002 4:07 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] about Cseq sequence numbers > > > > Dear all, > > Suppose a watcher subscribes to a presentity presence info with > an initial SUBSCRIBE msg with a Cseq value of 1. > the watcher receives the corresponding NOTIFY with a Cseq value of 1 (the > same). > Then the presentity updates several times its presence info and > the watcher > receives several NOTIFY with incremented Cseq values. (ie if the presence > info changed twice > the last NOTIFY has a Cseq value of 3, right ?). > Then when the watcher wants to refresh its subscription I do that: > it sends a SUBSCRIBE with a CSeq value of 2 and a matching Dialog To tag. > It receives its corresponding NOTIFY with a CSeq value of 2. > So my (little) problem is that I have two transactions which have the same > Cseq number of 2 in the same dialog : > the latest NOTIFY and the first one notifying an update in Presentity > presence info. No. Each endpoint has its own separate CSeq state for requests--that is, each endpoint has its own numbering sequence for requests. In your example, the NOTIFY after the re-subscribe would have a CSeq of 4 (the next in sequence of all the NOTIFYs). The NOTIFY does not share the CSeq of the INVITE. (Note that NOTIFY is a request, not a response.) In your example, it is only coincidence that the initial SUBSCRIBE and NOTIFY had the same CSeq. (In the real world, CSeqs should rarely start with 1, and each side would probably choose a different initial CSeq.) > Is it correct like that ? > A possible solution to avoid that is to set the Cseq value of the > refreshing SUBSCRIBE to a value one > higher than the latest NOTIFY received in that dialog (in our case 4, if > presence info changed twice before the refresh) > and not the latest SUBSCRIBE sent. No, that is incorrect behavior. See above. > > Does someone knows what to do ? > Thanks, > Lamine. > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 6 18:54:01 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16226 for ; Wed, 6 Mar 2002 18:54:01 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g26NnFT8025985; Wed, 6 Mar 2002 18:49:15 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12369; Wed, 6 Mar 2002 18:52:03 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11425 for ; Wed, 6 Mar 2002 13:43:27 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26289; Wed, 6 Mar 2002 13:42:36 -0500 (EST) Message-Id: <200203061842.NAA26289@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org, simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-sip-message-01.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 06 Mar 2002 13:42:36 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Extensions for Instant Messaging Author(s) : J. Rosenberg et al. Filename : draft-ietf-sip-message-01.txt Pages : 22 Date : 05-Mar-02 This document defines a SIP extension (a single new method) that supports Instant Messaging (IM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-message-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-sip-message-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-sip-message-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: <20020305135345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-message-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-message-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305135345.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 7 15:59:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23825 for ; Thu, 7 Mar 2002 15:59:01 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g27KrXT8002892; Thu, 7 Mar 2002 15:53:33 -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 PAA16314; Thu, 7 Mar 2002 15:56:05 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16303 for ; Thu, 7 Mar 2002 15:55:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g27Ktt6Y028625; Thu, 7 Mar 2002 15:55:55 -0500 (EST) Message-ID: <3C87D3A0.AE0A55CA@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Hua Tang CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 07 Mar 2002 15:54:56 -0500 Content-Transfer-Encoding: 7bit Li Hua Tang wrote: > > Jonathan Rosenberg wrote: > > > > It's possible that no presence subscription hasn't > > > been sent before a winfo subscription. > > > That is not the case we are discussing. IN this case, a user wants to > > rack the status of his own subscription to some other resource. By > > definition, this is a watcherinfo subscription associated with some > > other existing subscription. > > > > And a SUBSCRIBE request for winfo > > > will definitely create a new dialog since it has a new callID. > > > Not in this case. The meaning of sending the subscription on the same > > dialog is to reuse the call-id, to, from. > > I can't agree with you. In order to do realtime authorization (or say, > in > oder to be notified as soon as being subscribed), the presentity can > send > winfo subscription to the PS first even if there is no presence > subscription to it. It's independent on whether a watcher has subscribed > or > will subscribe to the resource of this presentity. It's not associated > with > an exsiting subscription. That is correct, but that is not the case I am talking about here. I think we are talking past each other. There are TWO separate uses of a watcher info subscription. One, is a subscription by the watcher themself, and the other, is from the presentity. Pictorially: Please view in a fixed-width font such as Courier. (1) sub winfo (2) sub winfo +-------------------+ +---------------------+ | | | | | V V | +--------+ +--------+ +----+---+ |presence| | | | | | watcher|------------>| PA |<------------ |presentity | | sub presence| | publish pres| | | | | | | | +--------+ +--------+ +--------+ Case (1) is the presence subscriber being the watcherinfo subscriber. Case (2) is the presentity being the watcherinfo subscriber. In case (1), the winfo subscription, by definition, follows a presence subscription. It can therefore go on the same dialog. In case (2), the winfo subscription happens independently, and needs to go to all PA which are publishing presence for that presentity. > > Now to me, you are saying contradicting things. Either the PS is a PA, > > or it is a proxy. If its a PA, it terminates the watcherinfo > > subscriptions. If its a proxy, it proxies the watcherinfo > subscriptions. > > Either the PS is a PA, or it is a proxy. Do you mean the PS can't be a > combination of PA/Proxy/Registrar? Or do you mean the PS can't change > the > role between PA and Proxy when handling subscriptions whenever the > presentity changes status (available or not)? No. I am saying that if a PS is a proxy for a presence subscription, it has to be a proxy for a watcherinfo subscription for the same user. If a PS is a PA for a presence subscription, it has to be a PA for a watcherinfo subscription for the same user. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 00:22:39 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14317 for ; Fri, 8 Mar 2002 00:22:38 -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 g285JDT8005269; Fri, 8 Mar 2002 00:19:14 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17803; Fri, 8 Mar 2002 00:22:04 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17792 for ; Fri, 8 Mar 2002 00:21:31 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g285KV6Y029017; Fri, 8 Mar 2002 00:20:32 -0500 (EST) Message-ID: <3C8849E5.5066603F@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Hua Tang CC: simple@mailman.dynamicsoft.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-rosenberg-simple-components-00.txt (Realtime Authorization) Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 08 Mar 2002 00:19:33 -0500 Content-Transfer-Encoding: 7bit Li Hua Tang wrote: > > Jonathan, > > Thanks for your indication to user presence status. I find related > definition in RFC2778. > > One more question about realtime authorization. > > If the presentity has subscribed for winfo event, the PS can send the > pending wacther status to the presentity to ask for authorization. But > if > the presentity didn't do so at early time, how can the PS notify it of a > waiting authorization? If the presentity wants to find out about waiting or pending subscriptions, it needs to subscribe to, or fetch, watcherinfo. If the presentity doesn't subscribe or fetch the watcherinfo, it won't know, and there is no way for the server to tell it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 01:29:31 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15381 for ; Fri, 8 Mar 2002 01:29:31 -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 g286PAT8005485; Fri, 8 Mar 2002 01:25:10 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18018; Fri, 8 Mar 2002 01:28:02 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18007 for ; Fri, 8 Mar 2002 01:27:55 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g286RW6Y029063; Fri, 8 Mar 2002 01:27:34 -0500 (EST) Message-ID: <3C885999.CC029951@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Petri K. Koskelainen" CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) References: <200202281724.MAA04612@dynasty.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 08 Mar 2002 01:26:33 -0500 Content-Transfer-Encoding: 7bit "Petri K. Koskelainen" wrote: > > Hi, > > The draft proposes that In-Reply-To header should > be used for message threading in paging mode, > and the draft also states that in message session > mode threading is already provided. > > I don't fully agree here. It works for two-party messaging > but not well in group messaging scenarios. It is good that we are finally having some discussion on this. Do note that draft-ietf-sip-message does actually talk about In-Reply-To as the threading mechanism... > > Problem 1: Message session supports only one discussion thread > per session. > This does not well reflect real-life scenarios. > For example, there may be a group chat session with 20 people. > It is very likely that they have different > conversation topics going-on at the same time although they > are in the same group. It is also likely that smaller sub-threads > emerge and it would be nice if these can be somehow shown > in the user interface similarly to current network news UIs. > For example, if there are several questions asked in the group > and users respond with "yes!" or "no" in the message body it is > quite difficult to know to which question they were intended. > User Interface could show them nicely if there were header support > for it. I'll buy that this would be handy, although not super critical. If MESSAGE were used for messaging within the session model, wouldn't In-Reply-To be sufficient for it? > > Problem 2: Group messaging server creates new Call-IDs for each call-leg. > In-Reply-To has also problems in group IM paging mode > since the server creates new Call-IDs for each > participant. One call-id is valid only between one user and the server. > The server has to remember all previous Call-IDs so > it can change Call-IDs in In-Reply-To accordingly when somebody > is responding to group message. > It must have the history and know that a message it sent to Bob > a day ago with Call-ID=X is in fact the same message than > message sent to Alice with Call-ID=Y. This becames quite complicated. No doubt. A discussion we REALLY need to have, is whether we think that the paging model even makes sense for multiparty. I am really not convinced. It seems that multiparty paging model is really more like email, and that is not what IM is supposed to be. If group IM is supposed to be real time, It just works so much better in the session model. So many problems (like this one above) just evaporate. Can anyone suggest a reason why the paging model is preferrable for group chat? Simplicity is one, but that simplicity might be elusive as you try to fill in all the missing pieces. > > > Problem 3: Lack of global and common ID for each group message. > Now it is difficult to reference a specific group instant message > afterwards so that everybody understands it. Only the server > has the knowledge (if it keeps the history). The recipients > don't know that group IM sent to me with Call-ID=X is the same than > group IM sent to Alice with Call-ID=Y. In some cases it would > be useful to have the information available in the message. Agree that a unique message ID is needed. For session model, if MESSAGE is used, it is NOT clear to me that Call-ID would have to change for each leg of the conference. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 01:35:34 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15449 for ; Fri, 8 Mar 2002 01:35:34 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g286W7T8005563; Fri, 8 Mar 2002 01:32:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18066; Fri, 8 Mar 2002 01:35:04 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18053 for ; Fri, 8 Mar 2002 01:34:32 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g286Yc6Y029067; Fri, 8 Mar 2002 01:34:38 -0500 (EST) Message-ID: <3C885B44.4D8F4D6B@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "David R. Oran" CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) References: <041201c1c131$d33db740$32ee2ca1@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 08 Mar 2002 01:33:40 -0500 Content-Transfer-Encoding: 7bit "David R. Oran" wrote: > > > Problem 1: Message session supports only one discussion thread > > per session. > > This does not well reflect real-life scenarios. > > For example, there may be a group chat session with 20 people. > > It is very likely that they have different > > conversation topics going-on at the same time although they > > are in the same group. It is also likely that smaller > > sub-threads emerge and it would be nice if these can be > > somehow shown in the user interface similarly to current > > network news UIs. For example, if there are several questions > > asked in the group and users respond with "yes!" or "no" in > > the message body it is > > quite difficult to know to which question they were intended. > > User Interface could show them nicely if there were header support > > for it. > > > Actually, I think there are two related, but not identical problems to > be solved here. One is the logical grouping of messages by thread/topic, > for which In-reply-to: is helpful but not completely adequate. The > second is constructing a causal order of the messages in a multi-party > chat session. Good observation. I think you are right. In-reply-to can in fact be used for this, as long as each > message is in fact tagged with the message-id of the message that > provoked it (some UI support is of course needed to identify this). > However, this usage would conflict with the classical threading usage we > see in newsgroups. In-Reply-To can play either role, depending on what you think should go in there. If, when you respond to a message, you place into In-Reply-To, the value of In-Reply-To from the message you are responding to, you get threading. You change threads by basically deleting In-Reply-To when you create a new thread. If you place into In-Reply-To, the Call-ID of the message you are responding to, you get causal order. Its not clear which is a "more correct" usage of In-Reply-To. If I had to guess, its probably the latter usage, which would get you causal order. > > I think the threading/topic stuff would best be solved with adding a > hierarchical structure to the Subject: (or In-reply-to) header, or a new > header, such as "context:" and some conventions thereto, as was > suggested. However, that leaves the problem of how to establish the > causal order if the In-reply-to header is used. For that, I believe a > new header would be called for. Why is a new header needed for causal order if you use In-Reply-To? Theading may very well better be handled by Subject. I hadn't thought about that.... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 01:54:35 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15584 for ; Fri, 8 Mar 2002 01:54:35 -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 g286p7T8005674; Fri, 8 Mar 2002 01:51:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18154; Fri, 8 Mar 2002 01:54:02 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18142 for ; Fri, 8 Mar 2002 01:53:20 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g286rT6Y029083; Fri, 8 Mar 2002 01:53:29 -0500 (EST) Message-ID: <3C885FAF.A82A3222@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Hansen CC: SIMPLE list Subject: Re: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again) References: <20020206000526.76476.qmail@web11608.mail.yahoo.com> <3C7C0CCC.D6EBC1BC@att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 08 Mar 2002 01:52:31 -0500 Content-Transfer-Encoding: 7bit Tony Hansen wrote: > > Here are some ideas on how this could play out within the IETF. > > One of the documents being put out in the SIP WG is SIP Call Flow > Examples. It shows how the SIP protocol should be used in an IP > Telephony service. > > Another effort in the IETF is the Voice Profile for Internet Messaging > (VPIM) working group. That group has been figuring out how to do voice > messaging (for voice mailboxes) using existing protocols, such as SMTP > and IMAP. Where the existing protocols were lacking, they also worked on > filling in the gaps, either within the VPIM WG or in conjunction with > other working groups (e.g., imap-ext). Note: the VPIM WG was originally > formed due to input from an external organization, the EMA, but the work > has all been done here in the IETF. > > The problem we're facing here in SIMPLE seems to be in the same > category, and the solution may be similar. It appears that what is > required is a profile for an instant messaging service saying how it > should pull together the different piece parts to form a coherent whole. Well, there are two parts. Part one, is to specify the pieces, and to make sure they are all there. Part two, is to specify an architecture that puts them together as a whole. Part one is definitely an IETF activity. We really have most of the pieces, and the few that remain, are easy. I have written an I-D on this subject, which discusess the pieces needed for a consumer IM/buddy-list application: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-components-00.txt I'd really like to get group input on whether there is interest/agreement on which aspects of my proposed plan. The second piece, part two, is to specify an architecture that pulls it all together. If such a thing were done here, it would need to be informational to say the least. There is precendent for publication of informational architecture docs generated by other bodies (the DCS architecture). I think SOMEONE needs to put this together, that is for certain. If no one else is stepping up to the plate, I'd prefer IETF to nobody, thats for sure. > > I'm convinced we can solve this problem. Getting feedback from the > industry is absolutely useful in the process, but I think the work needs > to happen here, in the IETF. And I'm willing to work on it. > > Comments? Should something like this go on the SIMPLE agenda for > Minneapolis? I'd like to discuss it, yes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 02:10:32 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23866 for ; Fri, 8 Mar 2002 02:10:32 -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 g28768T8005776; Fri, 8 Mar 2002 02:06:08 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18224; Fri, 8 Mar 2002 02:09:03 -0500 (EST) Received: from fdd.com (dsl081-147-080.chi1.dsl.speakeasy.net [64.81.147.80]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18212 for ; Fri, 8 Mar 2002 02:08:26 -0500 (EST) Received: (from vektor@localhost) by fdd.com (8.11.3/8.10.1) id g2877Wt30719; Fri, 8 Mar 2002 01:07:32 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: "Petri K. Koskelainen" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) Message-ID: <20020308010731.A17757@dumbterm.net> References: <200202281724.MAA04612@dynasty.cs.columbia.edu> <3C885999.CC029951@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3C885999.CC029951@dynamicsoft.com>; from jdrosen@dynamicsoft.com on Fri, Mar 08, 2002 at 01:26:33AM -0500 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 8 Mar 2002 01:07:31 -0600 Jonathan Rosenberg (jdrosen@dynamicsoft.com): > A discussion we REALLY need to have, is whether we think that the > paging model even makes sense for multiparty. I am really not > convinced. It seems that multiparty paging model is really more like > email, and that is not what IM is supposed to be. If group IM is > supposed to be real time, It just works so much better in the session > model. So many problems (like this one above) just evaporate. > > Can anyone suggest a reason why the paging model is preferrable for > group chat? Simplicity is one, but that simplicity might be elusive as > you try to fill in all the missing pieces. The session model for group messaging implies the existance of a centralized server, otherwise it becomes unmanageable (all the complexities of distributed state in a full mesh). If all messaging is done through paging, it seems like you could build an end-to-end conference on the fly with transparent migration from point-to-point and multi-recipient messages. I believe that the simplicity remains only if you allow membership inconsistencies, like email. Each group member retains their own membership state which may or may not match the other recipients, and while optional membership add/drop requests may be sent by members, each client is ultimately free to make their own decisions as to who they send messages to. This allows for 'bcc' functionality as well. However, if messages are not autonomous and themselves contain state, this would break the model. -- Billy Biggs billy@billybiggs.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 06:35:58 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28939 for ; Fri, 8 Mar 2002 06:35:58 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g28BWCT8006450; Fri, 8 Mar 2002 06:32:13 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19042; Fri, 8 Mar 2002 06:35:04 -0500 (EST) Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id GAA19029 for ; Fri, 8 Mar 2002 06:34:39 -0500 (EST) Received: (qmail 23171 invoked by alias); 8 Mar 2002 11:33:50 -0000 Received: from unknown (HELO indigosw.com) (194.78.202.25) by 0 with SMTP; 8 Mar 2002 11:33:50 -0000 Message-ID: <3C88A1A5.8020102@indigosw.com> From: Torrey Searle Organization: Indigo Software, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Date header and offline messages Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 08 Mar 2002 12:33:57 +0100 Content-Transfer-Encoding: 7bit in 9.5 it seems to allow for a store and forward mechanism with sip messaging. Am I correct in assuming that the Date header a forwared delayed request must have an updated date header to avoid being blocked by the replay prevention described in 11.3? If the date header is updated on the forward, can there be an "Originally-Sent" header? In the case when a message stored on the server because the final destination was offline. Informing the user of the time the message originally was sent can be informative. IM services such as Yahoo also have timestamps to indicate when an offline message was originally sent. Torrey Searle Indigo Software tsearle@indigosw.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 07:02:46 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00520 for ; Fri, 8 Mar 2002 07:02:45 -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 g28BxJT8006595; Fri, 8 Mar 2002 06:59:19 -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 HAA19166; Fri, 8 Mar 2002 07:02:16 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19138 for ; Fri, 8 Mar 2002 07:01:14 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00180; Fri, 8 Mar 2002 07:00:24 -0500 (EST) Message-Id: <200203081200.HAA00180@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-format-01.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 08 Mar 2002 07:00:24 -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 XML Based Format for Watcher Information Author(s) : J. Rosenberg Filename : draft-ietf-simple-winfo-format-01.txt Pages : 10 Date : 07-Mar-02 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-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-winfo-format-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-winfo-format-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: <20020307120951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-winfo-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-winfo-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307120951.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 07:07:28 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00964 for ; Fri, 8 Mar 2002 07:07:28 -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 g28Bx6T8006585; Fri, 8 Mar 2002 06:59:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19150; Fri, 8 Mar 2002 07:02:02 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19133 for ; Fri, 8 Mar 2002 07:01:10 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00150; Fri, 8 Mar 2002 07:00:19 -0500 (EST) Message-Id: <200203081200.HAA00150@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-package-01.txt Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 08 Mar 2002 07:00:19 -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 SIP Event Sub-Package for Watcher Information Author(s) : J. Rosenberg Filename : draft-ietf-simple-winfo-package-01.txt Pages : 17 Date : 07-Mar-02 This document defines the watcher information sub-package for the SIP event infrastructure. Watcher information refers to the set of users subcribed to a particular resource within a particular event package. This set changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A subscriber can subscribe to this information, and therefore learn about changes to it. This event package is a sub-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-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-winfo-package-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-winfo-package-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: <20020307120938.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-winfo-package-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-winfo-package-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307120938.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 09:29:47 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06683 for ; Fri, 8 Mar 2002 09:29:46 -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 g28EQAT8007442; Fri, 8 Mar 2002 09:26:10 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19650; Fri, 8 Mar 2002 09:29:03 -0500 (EST) Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA19638 for ; Fri, 8 Mar 2002 09:28:18 -0500 (EST) Received: (qmail 26352 invoked by alias); 8 Mar 2002 14:27:29 -0000 Received: from unknown (HELO antihe.ro) (194.78.202.25) by 0 with SMTP; 8 Mar 2002 14:27:29 -0000 Message-ID: <3C88CA59.5070306@antihe.ro> From: Torrey Searle User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com References: <200203081203.HAA19210@mailman.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 08 Mar 2002 15:27:37 +0100 Content-Transfer-Encoding: 7bit On reason that makes group discussions via e-mail easy and quick to start up is the ability to "reply to all" in response to the e-mail, in the case of page mode of IM a person reciving an IM does not know who the other recipents of the message are, rendering it difficult for everybody to determine the proper members of the conversation. Listing the members in a Contact header is not allowed because no dialog is created. Perhaps a "Respond-To" header can be added to a message in order to suggest to the recipient which addresses should a response to the given message be sent to. Torrey Searle Indigo Software > I believe that the simplicity remains only if you allow membership >inconsistencies, like email. Each group member retains their own >membership state which may or may not match the other recipients, and >while optional membership add/drop requests may be sent by members, each >client is ultimately free to make their own decisions as to who they >send messages to. This allows for 'bcc' functionality as well. > > However, if messages are not autonomous and themselves contain state, >this would break the model. > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 10:36:49 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10479 for ; Fri, 8 Mar 2002 10:36:48 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g28FXBT8008181; Fri, 8 Mar 2002 10:33:12 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19874; Fri, 8 Mar 2002 10:36:04 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19862 for ; Fri, 8 Mar 2002 10:35:17 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g28FYO317051; Fri, 8 Mar 2002 07:34:24 -0800 (PST) Received: from oranlt ([161.44.238.50]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACF17050; Fri, 8 Mar 2002 07:34:38 -0800 (PST) From: "David R. Oran" To: "'Jonathan Rosenberg'" Cc: Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) Organization: Cisco Systems Message-ID: <003801c1c6b6$b693c690$32ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3C885B44.4D8F4D6B@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 8 Mar 2002 10:34:17 -0500 Content-Transfer-Encoding: 7bit Clarifying a couple of points for Jonathan: > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, March 08, 2002 1:34 AM > To: David R. Oran > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Re: > draft-rosenberg-simple-components-00.txt (threading) > > > > > "David R. Oran" wrote: > > > > > > Problem 1: Message session supports only one discussion > thread per > > > session. This does not well reflect real-life scenarios. > > > For example, there may be a group chat session with 20 people. > > > It is very likely that they have different > > > conversation topics going-on at the same time although they > > > are in the same group. It is also likely that smaller > > > sub-threads emerge and it would be nice if these can be > > > somehow shown in the user interface similarly to current > > > network news UIs. For example, if there are several questions > > > asked in the group and users respond with "yes!" or "no" in > > > the message body it is > > > quite difficult to know to which question they were intended. > > > User Interface could show them nicely if there were header support > > > for it. > > > > > Actually, I think there are two related, but not identical > problems to > > be solved here. One is the logical grouping of messages by > > thread/topic, for which In-reply-to: is helpful but not completely > > adequate. The second is constructing a causal order of the > messages in > > a multi-party chat session. > > Good observation. I think you are right. > > In-reply-to can in fact be used for this, as long as each > > message is in fact tagged with the message-id of the message that > > provoked it (some UI support is of course needed to identify this). > > However, this usage would conflict with the classical > threading usage > > we see in newsgroups. > > In-Reply-To can play either role, depending on what you think > should go in there. If, when you respond to a message, you > place into In-Reply-To, the value of In-Reply-To from the > message you are responding to, you get threading. Yup. > You change > threads by basically deleting In-Reply-To when you create a > new thread. Well, news systems allow you to have "hierarchical" threading, which would not be easy/possible unless you either have some hierarchy in In-Reply-To: and/or a way to explicitly start a sub-thread, perhaps by using Subject: in a clever way as you allude to below. The mixing of this not-quite-right causal ordering results in annoying structures like the cascading-thread with each message indented further. Such threads are very hard to follow which is why both threading and causal ordering is needed. > If you place into In-Reply-To, the Call-ID of the > message you are responding to, you get causal order. Yes, either the Call-ID itself or some other global identifier. I suppose Call-ID can be used without usage confusion, but I haven't thought about it long enough to be sure. > Its not > clear which is a "more correct" usage of In-Reply-To. If I > had to guess, its probably the latter usage, which would get > you causal order. > I'm inclined to agree. Again though, I'd need to ponder a bit more to see if this is indeed the way to go. > > > > I think the threading/topic stuff would best be solved with > adding a > > hierarchical structure to the Subject: (or In-reply-to) > header, or a > > new header, such as "context:" and some conventions > thereto, as was > > suggested. However, that leaves the problem of how to establish the > > causal order if the In-reply-to header is used. For that, I > believe a > > new header would be called for. > > Why is a new header needed for causal order if you use In-Reply-To? > Sorry, my ruminations were sloppy. I meant that if you used In-Reply-To: for threading you'd need a new header for establishing causal order. > Threading may very well better be handled by Subject. I hadn't > thought about that.... > Definitely worth considering. Given the general history and sloppiness around Subject:, it might be better to have an explicit "Threading:" header than try to figure out what to put in subject, which today simply does "approximate pattern match using the natural intelligence engine". There are also the issues around the (inconsistent) conventions for manipulating Subject: headers with things like "Re:" "Fwd:" etc. Dave. > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 11:51:50 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15734 for ; Fri, 8 Mar 2002 11:51:50 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g28GmBT8009155; Fri, 8 Mar 2002 11:48:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20135; Fri, 8 Mar 2002 11:51:03 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20124 for ; Fri, 8 Mar 2002 11:50:42 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g28GoCJ06710; Fri, 8 Mar 2002 11:50:12 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG44475; Fri, 8 Mar 2002 11:53:05 -0500 (EST) Message-ID: <3C88EBAF.A823F391@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-winfo-format-01.txt References: <200203081200.HAA00180@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 08 Mar 2002 11:49:51 -0500 Content-Transfer-Encoding: 7bit I have a question about: duration: The amount of time, in seconds, that the subscription was in the previous state before transitioning to the state described in the status parameter. I can see how this can be useful when receiving a notification containing only changes. But it is less useful when doing a fetch, or when receiving the initial notification following a subscription. In those cases there is no way to know how long the subscription has been in the current state. One solution would be to provide two values. But I think it is sufficient to provide only the duration in the current state. This is clearly the value needed when you have no prior information about the subscription. If you have a prior value, then the total time in the prior state, if desired, can be computed using the prior duration value, the time the last notification was sent, and the time the current notification was sent. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 11:57:43 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16480 for ; Fri, 8 Mar 2002 11:57:42 -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 g28Gs7T8009295; Fri, 8 Mar 2002 11:54:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20178; Fri, 8 Mar 2002 11:57:03 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20166 for ; Fri, 8 Mar 2002 11:56:52 -0500 (EST) Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA28304; Fri, 8 Mar 2002 11:56:04 -0500 (EST) Received: (from petkos@localhost) by dynasty.cs.columbia.edu (8.9.3/8.9.3) id LAA27135; Fri, 8 Mar 2002 11:56:04 -0500 (EST) From: "Petri K. Koskelainen" Message-Id: <200203081656.LAA27135@dynasty.cs.columbia.edu> Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Cc: petkos@cs.columbia.edu (Petri K. Koskelainen), simple@mailman.dynamicsoft.com In-Reply-To: <3C885999.CC029951@dynamicsoft.com> from "Jonathan Rosenberg" at Mar 08, 2002 01:26:33 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 8 Mar 2002 11:56:04 -0500 (EST) Content-Transfer-Encoding: 7bit > A discussion we REALLY need to have, is whether we think that the paging > model even makes sense for multiparty. I am really not convinced. It > seems that multiparty paging model is really more like email, and that > is not what IM is supposed to be. If group IM is supposed to be real > time, It just works so much better in the session model. So many > problems (like this one above) just evaporate. > > Can anyone suggest a reason why the paging model is preferrable for > group chat? Simplicity is one, but that simplicity might be elusive as > you try to fill in all the missing pieces. There are one-shot scenarios which require realtime delivery to a group. It is quite heavy operation to set up a session, send one IM, and then close the session. Example usage might be an urgent realtime announcement to a pre-defined group. BR, -- Petri _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 12:58:52 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20696 for ; Fri, 8 Mar 2002 12:58:51 -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 g28Ht8T8010096; Fri, 8 Mar 2002 12:55:08 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20414; Fri, 8 Mar 2002 12:58:03 -0500 (EST) Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA20403 for ; Fri, 8 Mar 2002 12:57:44 -0500 (EST) Message-ID: <20020308175649.73567.qmail@web11607.mail.yahoo.com> Received: from [131.107.3.70] by web11607.mail.yahoo.com via HTTP; Fri, 08 Mar 2002 09:56:49 PST From: Sean Olson Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) To: "Petri K. Koskelainen" , Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com In-Reply-To: <200203081656.LAA27135@dynasty.cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 8 Mar 2002 09:56:49 -0800 (PST) Group chat is of course a better fit for the session model. One-time delivery of messages to a group is a better fit for paging as Petri points out. How common is this? I can think of a TON of applications that fit this scenario. What features of group messaging can't be implemented in a paging mode? /sean --- "Petri K. Koskelainen" wrote: > > > A discussion we REALLY need to have, is whether we > think that the paging > > model even makes sense for multiparty. I am really > not convinced. It > > seems that multiparty paging model is really more > like email, and that > > is not what IM is supposed to be. If group IM is > supposed to be real > > time, It just works so much better in the session > model. So many > > problems (like this one above) just evaporate. > > > > Can anyone suggest a reason why the paging model > is preferrable for > > group chat? Simplicity is one, but that simplicity > might be elusive as > > you try to fill in all the missing pieces. > > There are one-shot scenarios which require realtime > delivery > to a group. It is quite heavy operation to set up a > session, > send one IM, and then close the session. > Example usage might be an urgent realtime > announcement to a > pre-defined group. > > > BR, > -- > Petri > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple ===== Sean Olson __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 16:38:07 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05565 for ; Fri, 8 Mar 2002 16:38:07 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g28LYCT8012371; Fri, 8 Mar 2002 16:34:12 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21120; Fri, 8 Mar 2002 16:37:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21109 for ; Fri, 8 Mar 2002 16:36:22 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g28LZqd11484; Fri, 8 Mar 2002 16:35:52 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG46817; Fri, 8 Mar 2002 16:38:44 -0500 (EST) Message-ID: <3C892EA2.A90EA0AC@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: "Petri K. Koskelainen" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) References: <20020308175649.73567.qmail@web11607.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 08 Mar 2002 16:35:30 -0500 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > Group chat is of course a better fit for the > session model. One-time delivery of messages to > a group is a better fit for paging as Petri points > out. How common is this? I can think of a TON of > applications that fit this scenario. What features > of group messaging can't be implemented in a paging > mode? - combining different media in the same group/conference - floor control _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 17:25:50 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07834 for ; Fri, 8 Mar 2002 17:25:49 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g28MM7T8012846; Fri, 8 Mar 2002 17:22:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21298; Fri, 8 Mar 2002 17:25:04 -0500 (EST) Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA21284 for ; Fri, 8 Mar 2002 17:24:06 -0500 (EST) Message-ID: <20020308222318.46835.qmail@web11608.mail.yahoo.com> Received: from [131.107.3.92] by web11608.mail.yahoo.com via HTTP; Fri, 08 Mar 2002 14:23:18 PST From: Sean Olson Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) To: Paul Kyzivat Cc: "Petri K. Koskelainen" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com In-Reply-To: <3C892EA2.A90EA0AC@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 8 Mar 2002 14:23:18 -0800 (PST) --- Paul Kyzivat wrote: > Sean Olson wrote: > > > > Group chat is of course a better fit for the > > session model. One-time delivery of messages to > > a group is a better fit for paging as Petri points > > out. How common is this? I can think of a TON of > > applications that fit this scenario. What features > > of group messaging can't be implemented in a > paging > > mode? > > - combining different media in the same > group/conference I don't see this limitation. What about entity headers? > - floor control This is a bit odd for IM > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple ===== Sean Olson __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 17:42:16 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08834 for ; Fri, 8 Mar 2002 17:42:15 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g28Mc7T8013011; Fri, 8 Mar 2002 17:38:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21369; Fri, 8 Mar 2002 17:41:03 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21358 for ; Fri, 8 Mar 2002 17:40:57 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g28MeQV18241; Fri, 8 Mar 2002 17:40:26 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG47321; Fri, 8 Mar 2002 17:43:20 -0500 (EST) Message-ID: <3C893DC6.FF2E0214@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: "Petri K. Koskelainen" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) References: <20020308222318.46835.qmail@web11608.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 08 Mar 2002 17:40:06 -0500 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > --- Paul Kyzivat wrote: > > Sean Olson wrote: > > > > > > Group chat is of course a better fit for the > > > session model. One-time delivery of messages to > > > a group is a better fit for paging as Petri points > > > out. How common is this? I can think of a TON of > > > applications that fit this scenario. What features > > > of group messaging can't be implemented in a > > paging > > > mode? > > > > - combining different media in the same > > group/conference > > I don't see this limitation. What about entity > headers? I don't understand what you mean. What I meant is that session oriented messaging is needed if you want to have a conference that includes messaging as well as other media, like voice or video. That way they are associated with one another via a common INVITE, with multiple m= lines in the SDP. If you use page mode messaging, you have to invent an entirely new mechanism to tie it to the session for the other media. > > > - floor control > This is a bit odd for IM Perhaps so if it is text mode IM. But suppose you are using this for some other purpose, like gaming, or pushing URLs that are to be rendered in a window. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 8 18:30:29 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11027 for ; Fri, 8 Mar 2002 18:30:29 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g28NQ6T8013369; Fri, 8 Mar 2002 18:26:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21531; Fri, 8 Mar 2002 18:29:02 -0500 (EST) Received: from web11601.mail.yahoo.com (web11601.mail.yahoo.com [216.136.172.53]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA21519 for ; Fri, 8 Mar 2002 18:28:38 -0500 (EST) Message-ID: <20020308232749.63992.qmail@web11601.mail.yahoo.com> Received: from [131.107.3.83] by web11601.mail.yahoo.com via HTTP; Fri, 08 Mar 2002 15:27:49 PST From: Sean Olson Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) To: Paul Kyzivat Cc: "Petri K. Koskelainen" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com In-Reply-To: <3C893DC6.FF2E0214@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 8 Mar 2002 15:27:49 -0800 (PST) > I don't understand what you mean. I was referring to mixing media within an IM "session" -- not the problem you were referring to :) > What I meant is that session oriented messaging is > needed if you want to have a conference that > includes messaging as well as other media, like > voice or video. That way > they are associated with one another via a common > INVITE, with multiple m= lines in the SDP. Absolutely. And for a group conference that makes a lot of sense. For ad-hoc groups which are essentially a collection of point-to-point connections, there may not be a need or occassion to use a INVITE-based session. An example is a IM sidebar to a regular group conference. You don't want to re-negotiate (via INVITE) the overall conference, but instead what to exchange a few simple IMs among an ad-hoc group. [I'm not against the session model for multiparty IM. If the WG would prefer to focus only on session model for multiparty scenarios, that's fine. But I expect this will only mean people will go off and implement their own paging model for multiparty IM. It's just too intuitive to pass up.] > > If you use page mode messaging, you have to invent > an entirely new mechanism to tie it to the session > for the other media. In-Reply-To would not work? > > > > > - floor control > > This is a bit odd for IM > > Perhaps so if it is text mode IM. But suppose you > are using this for some other purpose, like gaming, > or pushing URLs that are to be rendered in a window. Floor control would be useful here if the group accepts a moderator/floor notion of control. Chaotic as it may seem, there may be good reason to not have floor control in a multiparty IM environment. The social dynamics seem to argue for it for one. Note that I am not including "group chat" or chatroom scenarios. I am talking more about ad-hoc scenarios. > Paul /sean ===== Sean Olson __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Mar 9 16:46:26 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17352 for ; Sat, 9 Mar 2002 16:46:25 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g29LgIT8015508; Sat, 9 Mar 2002 16:42:19 -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 QAA25525; Sat, 9 Mar 2002 16:45:07 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25512 for ; Sat, 9 Mar 2002 16:44:16 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g29Lgll04584; Sat, 9 Mar 2002 15:42:47 -0600 Message-ID: <009501c1c7b3$4f356fa0$133fed0c@C1893415A> From: "Dean Willis" To: "Jonathan Rosenberg" , "Petri K. Koskelainen" Cc: References: <200202281724.MAA04612@dynasty.cs.columbia.edu> <3C885999.CC029951@dynamicsoft.com> Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sat, 9 Mar 2002 15:42:27 -0600 Content-Transfer-Encoding: 7bit Jonathan asked: > A discussion we REALLY need to have, is whether we think that the paging > model even makes sense for multiparty. I am really not convinced. It > seems that multiparty paging model is really more like email, and that > is not what IM is supposed to be. If group IM is supposed to be real > time, It just works so much better in the session model. So many > problems (like this one above) just evaporate. > > Can anyone suggest a reason why the paging model is preferrable for > group chat? Simplicity is one, but that simplicity might be elusive as > you try to fill in all the missing pieces. Well, if some of your participants are coming and going, you have an open question about whether store-and-forward delivery to those paticipants is appropriate. If we do store-and-forward, then it really IS like fast email, and I would posit that the paging model makes excellent sense. If on the other hand the model is a "chat room" where unless you are in the room, you never see the message, then a session model makes more sense. So I suggest that we may wish to consider distinguishing these two models from a requirements analysis perspective. I believe if we follow this to a logical conclusion that we'll end up with two very different implementations serving the different modalities, and a couple of logical "transition points" where messaging sequence move from one mode to the other. -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 11 09:02:33 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08330 for ; Mon, 11 Mar 2002 09:02:32 -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 g2BDwOMb001112; Mon, 11 Mar 2002 08:58:24 -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 JAA01107; Mon, 11 Mar 2002 09:01:08 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01096 for ; Mon, 11 Mar 2002 09:00:27 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2BDxu424924; Mon, 11 Mar 2002 08:59:56 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG51874; Mon, 11 Mar 2002 09:02:49 -0500 (EST) Message-ID: <3C8CB847.D9C0FA9B@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: "Petri K. Koskelainen" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) References: <20020308232749.63992.qmail@web11601.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 08:59:35 -0500 Content-Transfer-Encoding: 7bit I am not opposed to page-mode conferences. I was simply responding to your message that implied (I thought) that page-mode might be sufficient, without session-mode. The other problem with page-mode conferences is of course the issue of sending them over the SIP signalling channel. There is the general objection to doing this for fear of saturating the channel. Paul Sean Olson wrote: > > > > I don't understand what you mean. > > I was referring to mixing media within an IM > "session" -- not the problem you were referring to :) > > > What I meant is that session oriented messaging is > > needed if you want to have a conference that > > includes messaging as well as other media, like > > voice or video. That way > > they are associated with one another via a common > > INVITE, with multiple m= lines in the SDP. > > Absolutely. And for a group conference that makes > a lot of sense. For ad-hoc groups which are > essentially a collection of point-to-point > connections, there may not be a need or occassion > to use a INVITE-based session. An example is a > IM sidebar to a regular group conference. You don't > want to re-negotiate (via INVITE) the overall > conference, but instead what to exchange a few simple > IMs among an ad-hoc group. > > [I'm not against the session model for multiparty IM. > If the WG would prefer to focus only on session model > for multiparty scenarios, that's fine. But I expect > this will only mean people will go off and implement > their own paging model for multiparty IM. It's just > too intuitive to pass up.] > > > > > If you use page mode messaging, you have to invent > > an entirely new mechanism to tie it to the session > > for the other media. > > In-Reply-To would not work? > > > > > > > > - floor control > > > This is a bit odd for IM > > > > Perhaps so if it is text mode IM. But suppose you > > are using this for some other purpose, like gaming, > > or pushing URLs that are to be rendered in a window. > > Floor control would be useful here if the group > accepts a moderator/floor notion of control. Chaotic > as it may seem, there may be good reason to not have > floor control in a multiparty IM environment. The > social dynamics seem to argue for it for one. Note > that I am not including "group chat" or chatroom > scenarios. I am talking more about ad-hoc scenarios. > > > Paul > > /sean > > ===== > Sean Olson > > __________________________________________________ > Do You Yahoo!? > Try FREE Yahoo! Mail - the world's greatest free email! > http://mail.yahoo.com/ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 11 14:44:31 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20512 for ; Mon, 11 Mar 2002 14:44:31 -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 g2BJeKMb004401; Mon, 11 Mar 2002 14:40:20 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02176; Mon, 11 Mar 2002 14:43:04 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02165 for ; Mon, 11 Mar 2002 14:42:13 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2BJeOl26223; Mon, 11 Mar 2002 13:40:24 -0600 From: "Dean Willis" To: "'Paul Kyzivat'" , "'Sean Olson'" Cc: "'Petri K. Koskelainen'" , "'Jonathan Rosenberg'" , Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) Message-ID: <000401c1c934$960a62f0$bb036e3f@TXDWILLIS2> 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.3416 In-Reply-To: <3C8CB847.D9C0FA9B@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 13:40:22 -0600 Content-Transfer-Encoding: 7bit Paul wrote: > The other problem with page-mode conferences is of course > the issue of sending them over the SIP signalling channel. > There is the general objection to doing this for fear of > saturating the channel. Of course, meeting the European (and probably elsewhere) regulatory requirements for privacy is going to require running EVERYTHING over the signaling chanel or through an intermediary "anonymizer" box anyhow, so I fail to see this as a real issue. One simply has to design one's signaling network appropriately. One also has to design the business model in such a way that the costs can be accounted for and offset by revenue . . . I keep seeing this "Oh no, they're asking us to actually carry TRAFFIC on our network!" response from mobile operators that are still stuck in GSM circuit mindsets. What they fail to realize is that it is the value-added service (such as privacy management) built into that carriage that provides the value-add which distinguishes the service operator from a commodity bit-pipe provider. At the "most protective" end of the spectrum (I get this from people in Germany building wireless systems), the communication between two users cannot be allowed to reveal the actual IP address of any user, nor can it reveal anything about the geographic location or business relationships (who's your carrier?) of any user. The ONLY piece of information that can be revealed is the "identity" of a user as indicated by a network "address of record", and then only to the extent thet the user has specifically requested dislcosure of that mechanism AND a contractual relationship between operators provides for the controlled release of only that information. This means that each service operator has to operate a bidirectional anonymization service. For short sequences of messages, the SIP proxy network (with a few "hiding" tweaks) seems to be an efficient mechanism for doing this, certainly more efficient than allocating two session-level anonymizer boxes and using INVITE session signaling semantics to instantiate a protected session. -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 11 15:16:11 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21660 for ; Mon, 11 Mar 2002 15:16:11 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2BKC6Mb004765; Mon, 11 Mar 2002 15:12:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02301; Mon, 11 Mar 2002 15:15:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02288 for ; Mon, 11 Mar 2002 15:14:01 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2BKDUf21110; Mon, 11 Mar 2002 15:13:30 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG55424; Mon, 11 Mar 2002 15:16:24 -0500 (EST) Message-ID: <3C8D0FD5.3098EA25@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: "'Sean Olson'" , "'Petri K. Koskelainen'" , "'Jonathan Rosenberg'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) References: <000401c1c934$960a62f0$bb036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 15:13:09 -0500 Content-Transfer-Encoding: 7bit Dean Willis wrote: > > At the "most protective" end of the spectrum (I get this from people in > Germany building wireless systems), the communication between two users > cannot be allowed to reveal the actual IP address of any user, nor can > it reveal anything about the geographic location or business > relationships (who's your carrier?) of any user. The ONLY piece of > information that can be revealed is the "identity" of a user as > indicated by a network "address of record", and then only to the extent > thet the user has specifically requested dislcosure of that mechanism > AND a contractual relationship between operators provides for the > controlled release of only that information. Ugh! Seems nasty to require such by default. Providing that level of anonymity is costly. Ought not to be mandated. While I may want it, I often don't need it. Nevertheless, this seems to be largely irrelevant to the subject at hand. > Of course, meeting the European (and probably elsewhere) regulatory > requirements for privacy is going to require running EVERYTHING over the > signaling chanel or through an intermediary "anonymizer" box anyhow, so > I fail to see this as a real issue. One simply has to design one's > signaling network appropriately. One also has to design the business > model in such a way that the costs can be accounted for and offset by > revenue . . . > > I keep seeing this "Oh no, they're asking us to actually carry TRAFFIC > on our network!" response from mobile operators that are still stuck in > GSM circuit mindsets. What they fail to realize is that it is the > value-added service (such as privacy management) built into that > carriage that provides the value-add which distinguishes the service > operator from a commodity bit-pipe provider. My impression is that the force behind keeping IM off of the SIP signalling channel is IETF rather than regulatory agencies or mobile operators. I thought it had to do with UDP not be flow controlled. The proposals to use a SIP-like protocol over TCP or TLS resolves that problem. And if it transits a proxy then it can handle the anonymization as well. But I believe doing those things will require session oriented messaging. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 11 17:21:15 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27593 for ; Mon, 11 Mar 2002 17:21:15 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2BMHEMb005954; Mon, 11 Mar 2002 17:17:14 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02734; Mon, 11 Mar 2002 17:20:05 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02721 for ; Mon, 11 Mar 2002 17:19:56 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2BMIDl27114; Mon, 11 Mar 2002 16:18:13 -0600 From: "Dean Willis" To: "'Paul Kyzivat'" Cc: "'Sean Olson'" , "'Petri K. Koskelainen'" , "'Jonathan Rosenberg'" , Message-ID: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2> 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.3416 Importance: Normal In-Reply-To: <3C8D0FD5.3098EA25@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 16:18:11 -0600 Content-Transfer-Encoding: 7bit Paul said: > My impression is that the force behind keeping IM off of the > SIP signalling channel is IETF rather than regulatory > agencies or mobile operators. I thought it had to do with UDP > not be flow controlled. > > The proposals to use a SIP-like protocol over TCP or TLS > resolves that problem. And if it transits a proxy then it can > handle the anonymization as well. But I believe doing those > things will require session oriented messaging. Well, there are serveral forces toward keeping user messages off of the "signaling" path. 1) We've justified use of questionable flow control techniques for SIP by calling it "signaling", which implies a requirement for low-latency transmission using relative short messages delivered in an independently atomic fashion (no head-of-line blocking). Since this is somehow different than "bulk data", i.e. emails, etc. it is "sort of" ok, although SCTP is seen as the direction-of-choice for compliance with proper Internet architecture. The odd thing is that "pager" mode messages have exactly the same sort of requirements. 2) Some people have a "purity of model" approach and are offended by mixing information with meta-information. That is, the putting of any information into SIP besides that needed for the negotiation of sessions external to SIP offends them. Of course, they also find the REGISTER message, the INFO message, user-supplied bodies that are not SDP, and other such mechanisms offensive in the same way. They may be right, but SIP already mixes user and session-description information. 3) Some operators are concerned about a re-occurrence of the fundamental signaling problem with SMS. As currently implemented, wireless short-message-service transits user datagrams over SS7 links which also transport the signaling for circuit-switced call establishement and teardown. SS7 links are also very expensive and have to be highly protected. As a result, these scarce resources get overloaded and congest, and there's not efficient way to do prioritization between SMS and other signaling over those links. Newer research in SMS has sought a means to allocate transport outside of the primary SS7 path for moving message bodies. Some people see an an analog between the SS7 network and the role of SIP proxies as signaling elements. Since the SIP proxies get mixed up in the transference of SIP messages, they are seen as roughly similar to the STPs and SMSCs in the SS7 network. Warning: Philosophical Rant Follows The key issue is buried deep in the underlying business model. In the Internet world, you pay the same for the bits used to signal a multimedia session as for the bits used by the multimedia session itself. In the PSTN, the carriers pay for the signaling used to set up the multimedia session. In other words, there is NO signaling, as signaling is used in the PSTN sense, on the Internet -- just application traffic. There might be messaging applications, routing applications, management applications, or multimedia applications, but they're just all applications as far as the underlying network in concerned. In the PSTN, signaling actually traverses a separate, specialized network, driven by its own economic laws. In the Internet world view, if an application generates profits and adding more servers allows it to generate more profit, then the application gets more servers. But in the PSTN model, signaling is COST and never actually generates profit -- it merely allows the establishment of sessions or the delivery of messages, and it is the sessions or messages which generate the profit. Signaling is just a cost of doing business, and there's no good way to pass it directly on to the consumer or even charge it back to the application, so it always gets shorted. Given the fundamental laws of economics, the shortage of a useful resource increases its value, so signaling traffic becomes much more highly-protected and the efficiency of the signaling paramount. Running on its separate, tightly-controlled and carefully managed network, PSTN signaling takes on an almost religious significance. It's DIFFERENT from user or application data, and SPECIAL. I seem to remember from my days in PSTN design that it took "two years and two million dollars" to get clearance to connect to the core SS7 network. Of course, this mean that no new applications git built, but it's the model the phone-types understand. But there's really a deep fundamental difference between PSTN and Internet models. In a pure SIP network, we expect Internet-like end-to-end routability at layer 3. Once I know your contact information, I can send messages directly to you. This doesn't really exist in SS7. SIP proxies provide "layer 4 routing" functions like STPs, but only if needed by the endpoints. However, circuit-switched mindsets are leading to the development of SS7-like networks using SIP and IP, where the end-to-end- path at layer 3 is established ONLY if authorized by higher-layer (SIP) traffic which has transited the "trunking points" of operator proxies operating from within "walled gardens". In other words, they're insisting on reinventing the entire SS7 problem, and shouldn't be at all surprised when the issues that were so constraining in the SS7 world strike again. One of the issues that comes out is that PSTN types don't know how to charge for signaling -- they only know how to charge for the RESULTS of signaling. Therefore, it is important to them to tightly control the sorts of signaling that a user can do, because if a user does some kind of signaling that does something besides set up a session that they know how to charge for, that user is "stealing resources". As a consequence, PSTN-logic requires that the operator UNDERSTAND all signaling, and anything that isn't understood signaling needs to be relegated to transport controlled-by-signaling or just plain blocked. I'm continually approached by phone operators who start out by saying something like "We'll never implement the SIP MESSAGE method. Since it goes over our proxy network with user-supplied data, we have no way to charge for it and it allows users to steal network resources." I respond with something like "Well, the charging model of 3GPP/3GPP2 allows us to write a charging record indicating who sent the message, who received it, and how big it was. Given that, you should be able to charge for each one of these messages at whatever rate the business will bear." The first response is something like "We can't do that, this is the SIGNALING network. What if we run out of capacity?" Then they stop and think about it. Sometimes, virtual dollar signs ($^$) light up in their eyes. Other times they wander off mumbling at/about me. But it's clearly an alien philosophy. -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 11 17:47:00 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28390 for ; Mon, 11 Mar 2002 17:47:00 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2BMg7Mb006258; Mon, 11 Mar 2002 17:42:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02832; Mon, 11 Mar 2002 17:45:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02819 for ; Mon, 11 Mar 2002 17:44:28 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2BMhvM10772; Mon, 11 Mar 2002 17:43:57 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG56797; Mon, 11 Mar 2002 17:46:51 -0500 (EST) Message-ID: <3C8D3318.965F0CF2@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: "'Sean Olson'" , "'Petri K. Koskelainen'" , "'Jonathan Rosenberg'" , simple@mailman.dynamicsoft.com References: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Messages: Signaling, Data, or Theft (Was something to do wit message threading) Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 17:43:36 -0500 Content-Transfer-Encoding: 7bit Dean, Thank you for the informative "Philosophical Rant". What you say makes a lot of sense to me. But in the end I don't much care, as long as the people who do care settle their differences so we can decide on *something*. My need is for session oriented IM, in the sense that it can be negotiated as one of possibly many media in a call, that may or may not be conferenced. What channel it gets transmitted over is not important to me as long as it works and has reasonable latency. I have no objection to the presence of page mode IM as well, and have some uses in mind for it too. I also have no objection to page mode and session mode IM using the same paths, if all the flow control issues can be resolved. To me the main problem is having some closure on how session mode IM is specified in SDP. Paul Dean Willis wrote: > > Paul said: > > My impression is that the force behind keeping IM off of the > > SIP signalling channel is IETF rather than regulatory > > agencies or mobile operators. I thought it had to do with UDP > > not be flow controlled. > > > > The proposals to use a SIP-like protocol over TCP or TLS > > resolves that problem. And if it transits a proxy then it can > > handle the anonymization as well. But I believe doing those > > things will require session oriented messaging. > > Well, there are serveral forces toward keeping user messages off of the > "signaling" path. > > 1) We've justified use of questionable flow control techniques for SIP > by calling it "signaling", which implies a requirement for low-latency > transmission using relative short messages delivered in an independently > atomic fashion (no head-of-line blocking). Since this is somehow > different than "bulk data", i.e. emails, etc. it is "sort of" ok, > although SCTP is seen as the direction-of-choice for compliance with > proper Internet architecture. The odd thing is that "pager" mode > messages have exactly the same sort of requirements. > > 2) Some people have a "purity of model" approach and are offended by > mixing information with meta-information. That is, the putting of any > information into SIP besides that needed for the negotiation of sessions > external to SIP offends them. Of course, they also find the REGISTER > message, the INFO message, user-supplied bodies that are not SDP, and > other such mechanisms offensive in the same way. They may be right, but > SIP already mixes user and session-description information. > > 3) Some operators are concerned about a re-occurrence of the fundamental > signaling problem with SMS. As currently implemented, wireless > short-message-service transits user datagrams over SS7 links which also > transport the signaling for circuit-switced call establishement and > teardown. SS7 links are also very expensive and have to be highly > protected. As a result, these scarce resources get overloaded and > congest, and there's not efficient way to do prioritization between SMS > and other signaling over those links. Newer research in SMS has sought a > means to allocate transport outside of the primary SS7 path for moving > message bodies. > > Some people see an an analog between the SS7 network and the role of SIP > proxies as signaling elements. Since the SIP proxies get mixed up in the > transference of SIP messages, they are seen as roughly similar to the > STPs and SMSCs in the SS7 network. > > Warning: Philosophical Rant Follows > > The key issue is buried deep in the underlying business model. In the > Internet world, you pay the same for the bits used to signal a > multimedia session as for the bits used by the multimedia session > itself. In the PSTN, the carriers pay for the signaling used to set up > the multimedia session. In other words, there is NO signaling, as > signaling is used in the PSTN sense, on the Internet -- just application > traffic. There might be messaging applications, routing applications, > management applications, or multimedia applications, but they're just > all applications as far as the underlying network in concerned. In the > PSTN, signaling actually traverses a separate, specialized network, > driven by its own economic laws. > > In the Internet world view, if an application generates profits and > adding more servers allows it to generate more profit, then the > application gets more servers. But in the PSTN model, signaling is COST > and never actually generates profit -- it merely allows the > establishment of sessions or the delivery of messages, and it is the > sessions or messages which generate the profit. Signaling is just a cost > of doing business, and there's no good way to pass it directly on to the > consumer or even charge it back to the application, so it always gets > shorted. Given the fundamental laws of economics, the shortage of a > useful resource increases its value, so signaling traffic becomes much > more highly-protected and the efficiency of the signaling paramount. > Running on its separate, tightly-controlled and carefully managed > network, PSTN signaling takes on an almost religious significance. It's > DIFFERENT from user or application data, and SPECIAL. I seem to remember > from my days in PSTN design that it took "two years and two million > dollars" to get clearance to connect to the core SS7 network. Of course, > this mean that no new applications git built, but it's the model the > phone-types understand. > > But there's really a deep fundamental difference between PSTN and > Internet models. In a pure SIP network, we expect Internet-like > end-to-end routability at layer 3. Once I know your contact information, > I can send messages directly to you. This doesn't really exist in SS7. > SIP proxies provide "layer 4 routing" functions like STPs, but only if > needed by the endpoints. However, circuit-switched mindsets are leading > to the development of SS7-like networks using SIP and IP, where the > end-to-end- path at layer 3 is established ONLY if authorized by > higher-layer (SIP) traffic which has transited the "trunking points" of > operator proxies operating from within "walled gardens". In other words, > they're insisting on reinventing the entire SS7 problem, and shouldn't > be at all surprised when the issues that were so constraining in the SS7 > world strike again. > > One of the issues that comes out is that PSTN types don't know how to > charge for signaling -- they only know how to charge for the RESULTS of > signaling. Therefore, it is important to them to tightly control the > sorts of signaling that a user can do, because if a user does some kind > of signaling that does something besides set up a session that they know > how to charge for, that user is "stealing resources". As a consequence, > PSTN-logic requires that the operator UNDERSTAND all signaling, and > anything that isn't understood signaling needs to be relegated to > transport controlled-by-signaling or just plain blocked. > > I'm continually approached by phone operators who start out by saying > something like "We'll never implement the SIP MESSAGE method. Since it > goes over our proxy network with user-supplied data, we have no way to > charge for it and it allows users to steal network resources." I respond > with something like "Well, the charging model of 3GPP/3GPP2 allows us to > write a charging record indicating who sent the message, who received > it, and how big it was. Given that, you should be able to charge for > each one of these messages at whatever rate the business will bear." The > first response is something like "We can't do that, this is the > SIGNALING network. What if we run out of capacity?" Then they stop and > think about it. Sometimes, virtual dollar signs ($^$) light up in their > eyes. Other times they wander off mumbling at/about me. But it's clearly > an alien philosophy. > > -- > Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 11 23:29:56 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06177 for ; Mon, 11 Mar 2002 23:29:56 -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 g2C4R8Mb007582; Mon, 11 Mar 2002 23:27:08 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03912; Mon, 11 Mar 2002 23:30:05 -0500 (EST) Received: from oe-mp2.bizmailsrvcs.net (oe-mp2pub.managedmail.com [206.46.164.23]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03897 for ; Mon, 11 Mar 2002 23:29:07 -0500 (EST) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with ESMTP id <20020312042817.VZVZ7425.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Mon, 11 Mar 2002 22:28:17 -0600 Received: from Openwave.com ([206.35.147.89]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with ESMTP id <20020312042816.CHDQ939.oe-ismta2.bizmailsrvcs.net@Openwave.com>; Mon, 11 Mar 2002 22:28:16 -0600 Message-ID: <3C8D83DE.929A3FDD@Openwave.com> From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: "'Paul Kyzivat'" , "'Sean Olson'" , "'Petri K. Koskelainen'" , "'Jonathan Rosenberg'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) References: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2> Content-Type: multipart/alternative; boundary="------------CF7EAF9D3135AFEED988043F" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 20:28:14 -0800 --------------CF7EAF9D3135AFEED988043F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Dean, I would have agreed with your thinking if: 1. buying a SIP proxy costs as much as to buy a HTTP proxy 2. messaging traffic had the same Quality of Service (QOS) requirements and signaling (setting up IP calls). Since none of the above statements are true I do not agree with your thinking. For example in order to guarantee that you get 0.1% blocking on IP call signaling you will have to over provision your SIP proxies in order to handle the additional messaging traffic. However since the messaging traffic does not require the same QOS as signaling you will be wasting a lot of capacity. In other words your cost for transporting messaging data will be the same as the signaling one. Another example: Since SIP proxies and especially CSCFs (3GPP term for specialized SIP proxies) costs more than plain HTTP proxies (for the conferencing case) or IP routers (for the end to end case) then IM service providers will have to incur all this extra cost for doing IM via SIP proxies. There are no philosophical differences here just basic engineering and economics. -Vasilis Dean Willis wrote: > Paul said: > > My impression is that the force behind keeping IM off of the > > SIP signalling channel is IETF rather than regulatory > > agencies or mobile operators. I thought it had to do with UDP > > not be flow controlled. > > > > The proposals to use a SIP-like protocol over TCP or TLS > > resolves that problem. And if it transits a proxy then it can > > handle the anonymization as well. But I believe doing those > > things will require session oriented messaging. > > Well, there are serveral forces toward keeping user messages off of the > "signaling" path. > > 1) We've justified use of questionable flow control techniques for SIP > by calling it "signaling", which implies a requirement for low-latency > transmission using relative short messages delivered in an independently > atomic fashion (no head-of-line blocking). Since this is somehow > different than "bulk data", i.e. emails, etc. it is "sort of" ok, > although SCTP is seen as the direction-of-choice for compliance with > proper Internet architecture. The odd thing is that "pager" mode > messages have exactly the same sort of requirements. > > 2) Some people have a "purity of model" approach and are offended by > mixing information with meta-information. That is, the putting of any > information into SIP besides that needed for the negotiation of sessions > external to SIP offends them. Of course, they also find the REGISTER > message, the INFO message, user-supplied bodies that are not SDP, and > other such mechanisms offensive in the same way. They may be right, but > SIP already mixes user and session-description information. > > 3) Some operators are concerned about a re-occurrence of the fundamental > signaling problem with SMS. As currently implemented, wireless > short-message-service transits user datagrams over SS7 links which also > transport the signaling for circuit-switced call establishement and > teardown. SS7 links are also very expensive and have to be highly > protected. As a result, these scarce resources get overloaded and > congest, and there's not efficient way to do prioritization between SMS > and other signaling over those links. Newer research in SMS has sought a > means to allocate transport outside of the primary SS7 path for moving > message bodies. > > Some people see an an analog between the SS7 network and the role of SIP > proxies as signaling elements. Since the SIP proxies get mixed up in the > transference of SIP messages, they are seen as roughly similar to the > STPs and SMSCs in the SS7 network. > > Warning: Philosophical Rant Follows > > The key issue is buried deep in the underlying business model. In the > Internet world, you pay the same for the bits used to signal a > multimedia session as for the bits used by the multimedia session > itself. In the PSTN, the carriers pay for the signaling used to set up > the multimedia session. In other words, there is NO signaling, as > signaling is used in the PSTN sense, on the Internet -- just application > traffic. There might be messaging applications, routing applications, > management applications, or multimedia applications, but they're just > all applications as far as the underlying network in concerned. In the > PSTN, signaling actually traverses a separate, specialized network, > driven by its own economic laws. > > In the Internet world view, if an application generates profits and > adding more servers allows it to generate more profit, then the > application gets more servers. But in the PSTN model, signaling is COST > and never actually generates profit -- it merely allows the > establishment of sessions or the delivery of messages, and it is the > sessions or messages which generate the profit. Signaling is just a cost > of doing business, and there's no good way to pass it directly on to the > consumer or even charge it back to the application, so it always gets > shorted. Given the fundamental laws of economics, the shortage of a > useful resource increases its value, so signaling traffic becomes much > more highly-protected and the efficiency of the signaling paramount. > Running on its separate, tightly-controlled and carefully managed > network, PSTN signaling takes on an almost religious significance. It's > DIFFERENT from user or application data, and SPECIAL. I seem to remember > from my days in PSTN design that it took "two years and two million > dollars" to get clearance to connect to the core SS7 network. Of course, > this mean that no new applications git built, but it's the model the > phone-types understand. > > But there's really a deep fundamental difference between PSTN and > Internet models. In a pure SIP network, we expect Internet-like > end-to-end routability at layer 3. Once I know your contact information, > I can send messages directly to you. This doesn't really exist in SS7. > SIP proxies provide "layer 4 routing" functions like STPs, but only if > needed by the endpoints. However, circuit-switched mindsets are leading > to the development of SS7-like networks using SIP and IP, where the > end-to-end- path at layer 3 is established ONLY if authorized by > higher-layer (SIP) traffic which has transited the "trunking points" of > operator proxies operating from within "walled gardens". In other words, > they're insisting on reinventing the entire SS7 problem, and shouldn't > be at all surprised when the issues that were so constraining in the SS7 > world strike again. > > One of the issues that comes out is that PSTN types don't know how to > charge for signaling -- they only know how to charge for the RESULTS of > signaling. Therefore, it is important to them to tightly control the > sorts of signaling that a user can do, because if a user does some kind > of signaling that does something besides set up a session that they know > how to charge for, that user is "stealing resources". As a consequence, > PSTN-logic requires that the operator UNDERSTAND all signaling, and > anything that isn't understood signaling needs to be relegated to > transport controlled-by-signaling or just plain blocked. > > I'm continually approached by phone operators who start out by saying > something like "We'll never implement the SIP MESSAGE method. Since it > goes over our proxy network with user-supplied data, we have no way to > charge for it and it allows users to steal network resources." I respond > with something like "Well, the charging model of 3GPP/3GPP2 allows us to > write a charging record indicating who sent the message, who received > it, and how big it was. Given that, you should be able to charge for > each one of these messages at whatever rate the business will bear." The > first response is something like "We can't do that, this is the > SIGNALING network. What if we run out of capacity?" Then they stop and > think about it. Sometimes, virtual dollar signs ($^$) light up in their > eyes. Other times they wander off mumbling at/about me. But it's clearly > an alien philosophy. > > -- > Dean > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple --------------CF7EAF9D3135AFEED988043F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Dean,
I would have agreed with your thinking if:
1. buying a SIP proxy costs as much as to buy a HTTP proxy
2. messaging traffic had the same Quality of Service (QOS) requirements and signaling (setting up IP calls).
Since none of the above statements are true I do not agree with your thinking.

For example in order to guarantee that you get 0.1% blocking on IP call signaling you will have to over provision
your SIP proxies in order to handle the additional messaging traffic. However since the messaging traffic does not
require the same QOS as signaling you will be wasting a lot of capacity.
In other words your cost for transporting messaging data will be the same as the signaling one.

Another example: Since SIP proxies and especially CSCFs (3GPP term for specialized SIP proxies) costs more than
plain HTTP proxies (for the conferencing case) or IP routers (for the end to end case) then IM service providers will
have to incur all this extra cost for doing IM via SIP proxies.

There are no philosophical differences here just basic engineering and economics.

-Vasilis

Dean Willis wrote:

Paul said:
> My impression is that the force behind keeping IM off of the
> SIP signalling channel is IETF rather than regulatory
> agencies or mobile operators. I thought it had to do with UDP
> not be flow controlled.
>
> The proposals to use a SIP-like protocol over TCP or TLS
> resolves that problem. And if it transits a proxy then it can
> handle the anonymization as well. But I believe doing those
> things will require session oriented messaging.

Well, there are serveral forces toward keeping user messages off of the
"signaling" path.

1) We've justified use of questionable flow control techniques for SIP
by calling it "signaling", which implies a requirement for low-latency
transmission using relative short messages delivered in an independently
atomic fashion (no head-of-line blocking).  Since this is somehow
different than "bulk data", i.e. emails, etc. it is "sort of" ok,
although SCTP is seen as the direction-of-choice for compliance with
proper Internet architecture. The odd thing is that "pager" mode
messages have exactly the same sort of requirements.

2) Some people have a "purity of model" approach and are offended by
mixing information with meta-information. That is, the putting of any
information into SIP besides that needed for the negotiation of sessions
external to SIP offends them. Of course, they also find the REGISTER
message, the INFO message, user-supplied bodies that are not SDP, and
other such mechanisms offensive in the same way. They may be right, but
SIP already mixes user and session-description information.

3) Some operators are concerned about a re-occurrence of the fundamental
signaling problem with SMS. As currently implemented, wireless
short-message-service transits user datagrams over SS7 links which also
transport the signaling for circuit-switced call establishement and
teardown. SS7 links are also very expensive and have to be highly
protected. As a result, these scarce resources get overloaded and
congest, and there's not efficient way to do prioritization between SMS
and other signaling over those links. Newer research in SMS has sought a
means to allocate transport outside of the primary SS7 path for moving
message bodies.

Some people see an an analog between the SS7 network and the role of SIP
proxies as signaling elements. Since the SIP proxies get mixed up in the
transference of SIP messages, they are seen as roughly similar to the
STPs and SMSCs in the SS7 network.

Warning: Philosophical Rant Follows

The key issue is buried deep in the underlying business model. In the
Internet world, you pay the same for the bits used to signal a
multimedia session as for the bits used by the multimedia session
itself. In the PSTN, the carriers pay for the signaling used to set up
the multimedia session. In other words, there is NO signaling, as
signaling is used in the PSTN sense, on the Internet -- just application
traffic. There might be messaging applications, routing applications,
management applications, or multimedia applications, but they're just
all applications as far as the underlying network in concerned. In the
PSTN, signaling actually traverses a separate, specialized network,
driven by its own economic laws.

In the Internet world view, if an application generates profits and
adding more servers allows it to generate more profit, then the
application gets more servers. But in the PSTN model, signaling is COST
and never actually generates profit -- it merely allows the
establishment of sessions or the delivery of messages, and it is the
sessions or messages which generate the profit. Signaling is just a cost
of doing business, and there's no good way to pass it directly on to the
consumer or even charge it back to the application, so it always gets
shorted. Given the fundamental laws of economics, the shortage of a
useful resource increases its value, so signaling traffic becomes much
more highly-protected and the efficiency of the signaling paramount.
Running on its separate, tightly-controlled and carefully managed
network, PSTN signaling takes on an almost religious significance. It's
DIFFERENT from user or application data, and SPECIAL. I seem to remember
from my days in PSTN design that it took "two years and two million
dollars" to get clearance to connect to the core SS7 network. Of course,
this mean that no new applications git built, but it's the model the
phone-types understand.

But there's really a deep fundamental difference between PSTN and
Internet models. In a pure SIP network, we expect Internet-like
end-to-end routability at layer 3. Once I know your contact information,
I can send messages directly to you. This doesn't really exist in SS7.
SIP proxies provide "layer 4 routing" functions like STPs, but only if
needed by the endpoints. However, circuit-switched mindsets are leading
to the development of SS7-like networks using SIP and IP, where the
end-to-end- path at layer 3 is established ONLY if authorized by
higher-layer (SIP) traffic which has transited the "trunking points" of
operator proxies operating from within "walled gardens". In other words,
they're insisting on reinventing the entire SS7 problem, and shouldn't
be at all surprised when the issues that were so constraining in the SS7
world strike again.

One of the issues that comes out is that PSTN types don't know how to
charge for signaling -- they only know how to charge for the RESULTS of
signaling. Therefore, it is important to them to tightly control the
sorts of signaling that a user can do, because if a user does some kind
of signaling that does something besides set up a session that they know
how to charge for, that user is "stealing resources". As a consequence,
PSTN-logic requires that the operator UNDERSTAND all signaling, and
anything that isn't understood signaling needs to be relegated to
transport controlled-by-signaling or just plain blocked.

I'm continually approached by phone operators who start out by saying
something like "We'll never implement the SIP MESSAGE method. Since it
goes over our proxy network with user-supplied data, we have no way to
charge for it and it allows users to steal network resources." I respond
with something like "Well, the charging model of 3GPP/3GPP2 allows us to
write a charging record indicating who sent the message, who received
it, and how big it was. Given that, you should be able to charge for
each one of these messages at whatever rate the business will bear." The
first response is something like "We can't do that, this is the
SIGNALING network. What if we run out of capacity?" Then they stop and
think about it. Sometimes, virtual dollar signs ($^$) light up in their
eyes. Other times they wander off mumbling at/about me. But it's clearly
an alien philosophy.

--
Dean

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple

--------------CF7EAF9D3135AFEED988043F-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 12 01:13:05 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08042 for ; Tue, 12 Mar 2002 01:13:04 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2C6A7Mb007898; Tue, 12 Mar 2002 01:10:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04280; Tue, 12 Mar 2002 01:13:04 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04269 for ; Tue, 12 Mar 2002 01:12:10 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2C6ANl29473; Tue, 12 Mar 2002 00:10:24 -0600 Message-ID: <002701c1c98c$9725dd10$133fed0c@C1893415A> From: "Dean Willis" To: "Vasilis Polychronidis" Cc: "'Paul Kyzivat'" , "'Sean Olson'" , "'Petri K. Koskelainen'" , "'Jonathan Rosenberg'" , References: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2> <3C8D83DE.929A3FDD@Openwave.com> Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C1C95A.4BDD52C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 12 Mar 2002 00:10:20 -0600 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C1C95A.4BDD52C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey, it's not MY fault that 3GPP made their proxies too complicated and = therefore expensive. Do you have a better answer for meeting the European privacy = requirements? -- Dean ----- Original Message -----=20 From: Vasilis Polychronidis=20 To: Dean Willis=20 Cc: 'Paul Kyzivat' ; 'Sean Olson' ; 'Petri K. Koskelainen' ; 'Jonathan = Rosenberg' ; simple@mailman.dynamicsoft.com=20 Sent: Monday, March 11, 2002 10:28 PM Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was = something to do wit message threading) Dear Dean,=20 I would have agreed with your thinking if:=20 1. buying a SIP proxy costs as much as to buy a HTTP proxy=20 2. messaging traffic had the same Quality of Service (QOS) = requirements and signaling (setting up IP calls).=20 Since none of the above statements are true I do not agree with your = thinking.=20 For example in order to guarantee that you get 0.1% blocking on IP = call signaling you will have to over provision=20 your SIP proxies in order to handle the additional messaging traffic. = However since the messaging traffic does not=20 require the same QOS as signaling you will be wasting a lot of = capacity.=20 In other words your cost for transporting messaging data will be the = same as the signaling one.=20 Another example: Since SIP proxies and especially CSCFs (3GPP term for = specialized SIP proxies) costs more than=20 plain HTTP proxies (for the conferencing case) or IP routers (for the = end to end case) then IM service providers will=20 have to incur all this extra cost for doing IM via SIP proxies.=20 There are no philosophical differences here just basic engineering and = economics.=20 -Vasilis=20 Dean Willis wrote:=20 Paul said:=20 > My impression is that the force behind keeping IM off of the=20 > SIP signalling channel is IETF rather than regulatory=20 > agencies or mobile operators. I thought it had to do with UDP=20 > not be flow controlled.=20 >=20 > The proposals to use a SIP-like protocol over TCP or TLS=20 > resolves that problem. And if it transits a proxy then it can=20 > handle the anonymization as well. But I believe doing those=20 > things will require session oriented messaging.=20 Well, there are serveral forces toward keeping user messages off of = the=20 "signaling" path.=20 1) We've justified use of questionable flow control techniques for = SIP=20 by calling it "signaling", which implies a requirement for = low-latency=20 transmission using relative short messages delivered in an = independently=20 atomic fashion (no head-of-line blocking). Since this is somehow=20 different than "bulk data", i.e. emails, etc. it is "sort of" ok,=20 although SCTP is seen as the direction-of-choice for compliance with = proper Internet architecture. The odd thing is that "pager" mode=20 messages have exactly the same sort of requirements.=20 2) Some people have a "purity of model" approach and are offended by = mixing information with meta-information. That is, the putting of = any=20 information into SIP besides that needed for the negotiation of = sessions=20 external to SIP offends them. Of course, they also find the REGISTER = message, the INFO message, user-supplied bodies that are not SDP, = and=20 other such mechanisms offensive in the same way. They may be right, = but=20 SIP already mixes user and session-description information.=20 3) Some operators are concerned about a re-occurrence of the = fundamental=20 signaling problem with SMS. As currently implemented, wireless=20 short-message-service transits user datagrams over SS7 links which = also=20 transport the signaling for circuit-switced call establishement and=20 teardown. SS7 links are also very expensive and have to be highly=20 protected. As a result, these scarce resources get overloaded and=20 congest, and there's not efficient way to do prioritization between = SMS=20 and other signaling over those links. Newer research in SMS has = sought a=20 means to allocate transport outside of the primary SS7 path for = moving=20 message bodies.=20 Some people see an an analog between the SS7 network and the role of = SIP=20 proxies as signaling elements. Since the SIP proxies get mixed up in = the=20 transference of SIP messages, they are seen as roughly similar to = the=20 STPs and SMSCs in the SS7 network.=20 Warning: Philosophical Rant Follows=20 The key issue is buried deep in the underlying business model. In = the=20 Internet world, you pay the same for the bits used to signal a=20 multimedia session as for the bits used by the multimedia session=20 itself. In the PSTN, the carriers pay for the signaling used to set = up=20 the multimedia session. In other words, there is NO signaling, as=20 signaling is used in the PSTN sense, on the Internet -- just = application=20 traffic. There might be messaging applications, routing = applications,=20 management applications, or multimedia applications, but they're = just=20 all applications as far as the underlying network in concerned. In = the=20 PSTN, signaling actually traverses a separate, specialized network,=20 driven by its own economic laws.=20 In the Internet world view, if an application generates profits and=20 adding more servers allows it to generate more profit, then the=20 application gets more servers. But in the PSTN model, signaling is = COST=20 and never actually generates profit -- it merely allows the=20 establishment of sessions or the delivery of messages, and it is the = sessions or messages which generate the profit. Signaling is just a = cost=20 of doing business, and there's no good way to pass it directly on to = the=20 consumer or even charge it back to the application, so it always = gets=20 shorted. Given the fundamental laws of economics, the shortage of a=20 useful resource increases its value, so signaling traffic becomes = much=20 more highly-protected and the efficiency of the signaling paramount. = Running on its separate, tightly-controlled and carefully managed=20 network, PSTN signaling takes on an almost religious significance. = It's=20 DIFFERENT from user or application data, and SPECIAL. I seem to = remember=20 from my days in PSTN design that it took "two years and two million=20 dollars" to get clearance to connect to the core SS7 network. Of = course,=20 this mean that no new applications git built, but it's the model the = phone-types understand.=20 But there's really a deep fundamental difference between PSTN and=20 Internet models. In a pure SIP network, we expect Internet-like=20 end-to-end routability at layer 3. Once I know your contact = information,=20 I can send messages directly to you. This doesn't really exist in = SS7.=20 SIP proxies provide "layer 4 routing" functions like STPs, but only = if=20 needed by the endpoints. However, circuit-switched mindsets are = leading=20 to the development of SS7-like networks using SIP and IP, where the=20 end-to-end- path at layer 3 is established ONLY if authorized by=20 higher-layer (SIP) traffic which has transited the "trunking points" = of=20 operator proxies operating from within "walled gardens". In other = words,=20 they're insisting on reinventing the entire SS7 problem, and = shouldn't=20 be at all surprised when the issues that were so constraining in the = SS7=20 world strike again.=20 One of the issues that comes out is that PSTN types don't know how = to=20 charge for signaling -- they only know how to charge for the RESULTS = of=20 signaling. Therefore, it is important to them to tightly control the = sorts of signaling that a user can do, because if a user does some = kind=20 of signaling that does something besides set up a session that they = know=20 how to charge for, that user is "stealing resources". As a = consequence,=20 PSTN-logic requires that the operator UNDERSTAND all signaling, and=20 anything that isn't understood signaling needs to be relegated to=20 transport controlled-by-signaling or just plain blocked.=20 I'm continually approached by phone operators who start out by = saying=20 something like "We'll never implement the SIP MESSAGE method. Since = it=20 goes over our proxy network with user-supplied data, we have no way = to=20 charge for it and it allows users to steal network resources." I = respond=20 with something like "Well, the charging model of 3GPP/3GPP2 allows = us to=20 write a charging record indicating who sent the message, who = received=20 it, and how big it was. Given that, you should be able to charge for = each one of these messages at whatever rate the business will bear." = The=20 first response is something like "We can't do that, this is the=20 SIGNALING network. What if we run out of capacity?" Then they stop = and=20 think about it. Sometimes, virtual dollar signs ($^$) light up in = their=20 eyes. Other times they wander off mumbling at/about me. But it's = clearly=20 an alien philosophy.=20 --=20 Dean=20 _______________________________________________=20 simple mailing list=20 simple@mailman.dynamicsoft.com=20 http://mailman.dynamicsoft.com/mailman/listinfo/simple ------=_NextPart_000_0024_01C1C95A.4BDD52C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hey, it's not MY fault that 3GPP made = their proxies=20 too complicated and therefore expensive.
 
Do you have a better answer for meeting = the=20 European privacy requirements?
 
--
Dean
----- Original Message -----
From:=20 Vasilis = Polychronidis=20
Cc: 'Paul Kyzivat' ; 'Sean Olson'=20 ; 'Petri=20 K. Koskelainen' ; 'Jonathan Rosenberg' ; simple@mailman.dynamicsoft= .com=20
Sent: Monday, March 11, 2002 = 10:28=20 PM
Subject: Re: [Simple] Messages: = Signaling, Data, or Theft (Was something to do wit message = threading)

Dear Dean,
I = would have=20 agreed with your thinking if:
1. buying a SIP proxy costs as much = as to=20 buy a HTTP proxy
2. messaging traffic had the same Quality of = Service=20 (QOS) requirements and signaling (setting up IP calls).
Since none = of the=20 above statements are true I do not agree with your thinking.=20

For example in order to guarantee that you get 0.1% blocking on IP = call=20 signaling you will have to over provision
your SIP proxies in = order to=20 handle the additional messaging traffic. However since the messaging = traffic=20 does not
require the same QOS as signaling you will be wasting a = lot of=20 capacity.
In other words your cost for transporting messaging data = will be=20 the same as the signaling one.=20

Another example: Since SIP proxies and especially CSCFs (3GPP term = for=20 specialized SIP proxies) costs more than
plain HTTP proxies = (for=20 the conferencing case) or IP routers (for the end to end case) then IM = service=20 providers will
have to incur all this extra cost for doing IM via = SIP=20 proxies.=20

There are no philosophical differences here just basic engineering = and=20 economics.=20

-Vasilis=20

Dean Willis wrote:=20

Paul said:
> My impression is that = the force=20 behind keeping IM off of the
> SIP signalling channel is IETF = rather=20 than regulatory
> agencies or mobile operators. I thought it = had to=20 do with UDP
> not be flow controlled.
>
> The = proposals=20 to use a SIP-like protocol over TCP or TLS
> resolves that = problem.=20 And if it transits a proxy then it can
> handle the = anonymization as=20 well. But I believe doing those
> things will require session = oriented messaging.=20

Well, there are serveral forces toward keeping user messages off = of the=20
"signaling" path.=20

1) We've justified use of questionable flow control techniques = for SIP=20
by calling it "signaling", which implies a requirement for = low-latency=20
transmission using relative short messages delivered in an = independently=20
atomic fashion (no head-of-line blocking).  Since this is = somehow=20
different than "bulk data", i.e. emails, etc. it is "sort of" = ok,=20
although SCTP is seen as the direction-of-choice for compliance = with=20
proper Internet architecture. The odd thing is that "pager" mode =
messages have exactly the same sort of requirements.=20

2) Some people have a "purity of model" approach and are offended = by=20
mixing information with meta-information. That is, the putting = of any=20
information into SIP besides that needed for the negotiation of = sessions=20
external to SIP offends them. Of course, they also find the = REGISTER=20
message, the INFO message, user-supplied bodies that are not = SDP, and=20
other such mechanisms offensive in the same way. They may be = right, but=20
SIP already mixes user and session-description information.=20

3) Some operators are concerned about a re-occurrence of the = fundamental=20
signaling problem with SMS. As currently implemented, wireless=20
short-message-service transits user datagrams over SS7 links = which also=20
transport the signaling for circuit-switced call establishement = and=20
teardown. SS7 links are also very expensive and have to be = highly=20
protected. As a result, these scarce resources get overloaded = and=20
congest, and there's not efficient way to do prioritization = between SMS=20
and other signaling over those links. Newer research in SMS has = sought a=20
means to allocate transport outside of the primary SS7 path for = moving=20
message bodies.=20

Some people see an an analog between the SS7 network and the role = of SIP=20
proxies as signaling elements. Since the SIP proxies get mixed = up in the=20
transference of SIP messages, they are seen as roughly similar = to the=20
STPs and SMSCs in the SS7 network.=20

Warning: Philosophical Rant Follows=20

The key issue is buried deep in the underlying business model. In = the=20
Internet world, you pay the same for the bits used to signal a=20
multimedia session as for the bits used by the multimedia = session=20
itself. In the PSTN, the carriers pay for the signaling used to = set up=20
the multimedia session. In other words, there is NO signaling, = as=20
signaling is used in the PSTN sense, on the Internet -- just = application=20
traffic. There might be messaging applications, routing = applications,=20
management applications, or multimedia applications, but they're = just=20
all applications as far as the underlying network in concerned. = In the=20
PSTN, signaling actually traverses a separate, specialized = network,=20
driven by its own economic laws.=20

In the Internet world view, if an application generates profits = and=20
adding more servers allows it to generate more profit, then the=20
application gets more servers. But in the PSTN model, signaling = is COST=20
and never actually generates profit -- it merely allows the=20
establishment of sessions or the delivery of messages, and it is = the=20
sessions or messages which generate the profit. Signaling is = just a cost=20
of doing business, and there's no good way to pass it directly = on to the=20
consumer or even charge it back to the application, so it always = gets=20
shorted. Given the fundamental laws of economics, the shortage = of a=20
useful resource increases its value, so signaling traffic = becomes much=20
more highly-protected and the efficiency of the signaling = paramount.=20
Running on its separate, tightly-controlled and carefully = managed=20
network, PSTN signaling takes on an almost religious = significance. It's=20
DIFFERENT from user or application data, and SPECIAL. I seem to = remember=20
from my days in PSTN design that it took "two years and two = million=20
dollars" to get clearance to connect to the core SS7 network. Of = course,=20
this mean that no new applications git built, but it's the model = the=20
phone-types understand.=20

But there's really a deep fundamental difference between PSTN and =
Internet models. In a pure SIP network, we expect Internet-like=20
end-to-end routability at layer 3. Once I know your contact = information,=20
I can send messages directly to you. This doesn't really exist = in SS7.=20
SIP proxies provide "layer 4 routing" functions like STPs, but = only if=20
needed by the endpoints. However, circuit-switched mindsets are = leading=20
to the development of SS7-like networks using SIP and IP, where = the=20
end-to-end- path at layer 3 is established ONLY if authorized by =
higher-layer (SIP) traffic which has transited the "trunking = points" of=20
operator proxies operating from within "walled gardens". In = other words,=20
they're insisting on reinventing the entire SS7 problem, and = shouldn't=20
be at all surprised when the issues that were so constraining in = the SS7=20
world strike again.=20

One of the issues that comes out is that PSTN types don't know = how to=20
charge for signaling -- they only know how to charge for the = RESULTS of=20
signaling. Therefore, it is important to them to tightly control = the=20
sorts of signaling that a user can do, because if a user does = some kind=20
of signaling that does something besides set up a session that = they know=20
how to charge for, that user is "stealing resources". As a = consequence,=20
PSTN-logic requires that the operator UNDERSTAND all signaling, = and=20
anything that isn't understood signaling needs to be relegated = to=20
transport controlled-by-signaling or just plain blocked.=20

I'm continually approached by phone operators who start out by = saying=20
something like "We'll never implement the SIP MESSAGE method. = Since it=20
goes over our proxy network with user-supplied data, we have no = way to=20
charge for it and it allows users to steal network resources." I = respond=20
with something like "Well, the charging model of 3GPP/3GPP2 = allows us to=20
write a charging record indicating who sent the message, who = received=20
it, and how big it was. Given that, you should be able to charge = for=20
each one of these messages at whatever rate the business will = bear." The=20
first response is something like "We can't do that, this is the=20
SIGNALING network. What if we run out of capacity?" Then they = stop and=20
think about it. Sometimes, virtual dollar signs ($^$) light up = in their=20
eyes. Other times they wander off mumbling at/about me. But it's = clearly=20
an alien philosophy.=20

--
Dean=20

_______________________________________________
simple = mailing list=20
simple@mailman.dynamicsoft.com
http://ma= ilman.dynamicsoft.com/mailman/listinfo/simple

------=_NextPart_000_0024_01C1C95A.4BDD52C0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 12 15:40:01 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06121 for ; Tue, 12 Mar 2002 15:40:00 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2CKaFMb013410; Tue, 12 Mar 2002 15:36:15 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06987; Tue, 12 Mar 2002 15:39:08 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06976 for ; Tue, 12 Mar 2002 15:38:43 -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.1.0/Switch-2.1.0) with ESMTP id g2CKbD319269 for ; Tue, 12 Mar 2002 22:37:13 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 12 Mar 2002 22:37:51 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 22:37:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again) Message-ID: Thread-Topic: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again) Thread-Index: AcHGbgf5fPKVe+7GTEq1R2Cd8URVAwDlD5Mg To: , Cc: X-OriginalArrivalTime: 12 Mar 2002 20:37:51.0747 (UTC) FILETIME=[C7B83530:01C1CA05] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA06976 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 12 Mar 2002 22:37:51 +0200 Content-Transfer-Encoding: 8bit Hi, Just to inform you that 3GPP is stepping into this territory too (believe it or not). Their presence architecture is basically starting to look SIMPLE-based, but some requirements, such as presence publishing or managing presence ACLs, is beyond the scope of current SIMPLE specs. 3GPP will also shortly start work on the evolution of messaging and something called group management. So, now is certainly the time for the IETF to charter these kind of things if a unified solution for the _Internet_ is wanted. Otherwise e.g. wireless domain may diverge into some solution of their own. I think this is something for the IESG to consider when evaluating the possible rechartering proposals. However, if IETF will go forward, 3GPP's role might be to write a requirements (maybe this time with real requirements, distinct from solutions :-) draft from 3G wireless point of view, and then apply the results in their architecture. Obviously timing is important, I'm not sure if the IETF could realistically be expected to finish these kind of things in 12 months etc. So, there might be again guys on the mic telling that 3GPP needs this and this draft by this and this date for Release X... Note that standardizing something like provisioning or data manipulation interface may not make sense in the PC-centric world, where web-browser interfaces are OK. However, in 2*2 inch handset screen with numerical keyboard it may not be feasible to leave it that open. And 400+ million handsets a year can't be wrong :-) So, I vote for discussion in Minneapolis, preferably leading to a rechartering proposal with a quick decision schedule. I'm also willing to work on this, and I know a couple of other guys who would be too. Regards, Markus > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 08 March, 2002 8:53 > To: Tony Hansen > Cc: SIMPLE list > Subject: Re: [Simple] IM Service Profile? (was Re: Mobility of Buddy > List, Again) > > > > > Tony Hansen wrote: > > > > Here are some ideas on how this could play out within the IETF. > > > > One of the documents being put out in the SIP WG is SIP Call Flow > > Examples. It shows how the SIP protocol should be used in an IP > > Telephony service. > > > > Another effort in the IETF is the Voice Profile for > Internet Messaging > > (VPIM) working group. That group has been figuring out how > to do voice > > messaging (for voice mailboxes) using existing protocols, > such as SMTP > > and IMAP. Where the existing protocols were lacking, they > also worked on > > filling in the gaps, either within the VPIM WG or in > conjunction with > > other working groups (e.g., imap-ext). Note: the VPIM WG > was originally > > formed due to input from an external organization, the EMA, > but the work > > has all been done here in the IETF. > > > > The problem we're facing here in SIMPLE seems to be in the same > > category, and the solution may be similar. It appears that what is > > required is a profile for an instant messaging service saying how it > > should pull together the different piece parts to form a > coherent whole. > > Well, there are two parts. > > Part one, is to specify the pieces, and to make sure they are > all there. > Part two, is to specify an architecture that puts them together as a > whole. > > Part one is definitely an IETF activity. We really have most of the > pieces, and the few that remain, are easy. I have written an > I-D on this > subject, which discusess the pieces needed for a consumer > IM/buddy-list > application: > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-components-00.txt I'd really like to get group input on whether there is interest/agreement on which aspects of my proposed plan. The second piece, part two, is to specify an architecture that pulls it all together. If such a thing were done here, it would need to be informational to say the least. There is precendent for publication of informational architecture docs generated by other bodies (the DCS architecture). I think SOMEONE needs to put this together, that is for certain. If no one else is stepping up to the plate, I'd prefer IETF to nobody, thats for sure. > > I'm convinced we can solve this problem. Getting feedback from the > industry is absolutely useful in the process, but I think the work needs > to happen here, in the IETF. And I'm willing to work on it. > > Comments? Should something like this go on the SIMPLE agenda for > Minneapolis? I'd like to discuss it, yes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 12 17:32:50 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10543 for ; Tue, 12 Mar 2002 17:32:50 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2CMT8Mb014650; Tue, 12 Mar 2002 17:29:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07401; Tue, 12 Mar 2002 17:32:04 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07388 for ; Tue, 12 Mar 2002 17:31:31 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2CMU7U02899; Tue, 12 Mar 2002 16:30:07 -0600 From: "Dean Willis" To: "'Dean Willis'" , "'Paul Kyzivat'" Cc: Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) Message-ID: <000001c1ca15$71a9ec50$bb036e3f@TXDWILLIS2> 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.3416 Importance: Normal In-Reply-To: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 12 Mar 2002 16:29:58 -0600 Content-Transfer-Encoding: 7bit > Warning: Philosophical Rant Follows > > The key issue is buried deep in the underlying business > model. In the Internet world, you pay the same for the bits > used to signal a multimedia session as for the bits used by > the multimedia session itself. In the PSTN, the carriers pay > for the signaling used to set up the multimedia session. In > other words, there is NO signaling, as signaling is used in > the PSTN sense, on the Internet -- just application traffic. > There might be messaging applications, routing applications, > management applications, or multimedia applications, but > they're just all applications as far as the underlying > network in concerned. In the PSTN, signaling actually > traverses a separate, specialized network, driven by its own > economic laws. > Reference remaining rant elsewhere. Here's an example. ----------- From last year's Next Steps in Signaling BOF: 6.5 James Kempf Radio access networks - air is expensive. Optimize by using less bandwidth and more (for example) CPU cycles. Whatever the signaling protocol is, it must be very efficient for mobility. Providers pay big $$ for the airwaves, they don't want to use it for signaling, but for user data. Best: do the signaling through the backbone, and not over the air if possible. The signaling must be efficient for mobility to minimize signaling while moving from area to area. Mobility signalling should be directly coupled to the traffic. ------------- See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt Clearly from the provider perspective, user data and signaling are two different things. Therein lies the debate. For if a user were to do something that "looks like" signaling, they would intrude on the territory of the operator. The problem here: is Messaging the same as signaling? Is Presence the same as signaling? Is anything we do with SIP really "signaling" or is it user data? -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 10:42:21 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08515 for ; Wed, 13 Mar 2002 10:42:20 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2DFdAMb018647; Wed, 13 Mar 2002 10:39:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10546; Wed, 13 Mar 2002 10:42:03 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10535 for ; Wed, 13 Mar 2002 10:41:36 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2DFf4D04816; Wed, 13 Mar 2002 10:41:04 -0500 (EST) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAR72113; Wed, 13 Mar 2002 10:35:36 -0500 (EST) Message-Id: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Dean Willis" From: Michael Hammer Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) Cc: "'Dean Willis'" , "'Paul Kyzivat'" , In-Reply-To: <000001c1ca15$71a9ec50$bb036e3f@TXDWILLIS2> References: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 10:40:40 -0500 Dean,

There are some things users care about and will pay for, and other things they won't.  For connection oriented services, they consider the "air time" when they have full cut-through to when they get disconnected to be the value.  In connectionless services, they care about data packets getting through, not overhead signaling packets.

You seem to be suggesting that the customer pay for the time they spend waiting for the signaling to complete the call.  Or, you expect them to pay for signaling as well as data-bearing messages.  This is analogous to making customers pay for packaging, when all they want is the handful of tablets in the little bottle inside the big box.

Near where I live there is an ice-skating rink that charges by the hour.  Most people won't put up including in that hour the time taken to fill out forms and select skates.  Nor would they pay for time where they are standing in line for that process.  Not standing in line, getting to the rink sooner, and skating a full hour have value.

This is not just the service provider perspective, but the customer perspective.

It's OK to get philosophical, just keep it real. :)

Mike


At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:

> Warning: Philosophical Rant Follows
>
> The key issue is buried deep in the underlying business
> model. In the Internet world, you pay the same for the bits
> used to signal a multimedia session as for the bits used by
> the multimedia session itself. In the PSTN, the carriers pay
> for the signaling used to set up the multimedia session. In
> other words, there is NO signaling, as signaling is used in
> the PSTN sense, on the Internet -- just application traffic.
> There might be messaging applications, routing applications,
> management applications, or multimedia applications, but
> they're just all applications as far as the underlying
> network in concerned. In the PSTN, signaling actually
> traverses a separate, specialized network, driven by its own
> economic laws.
>

Reference remaining rant elsewhere.

Here's an example.

-----------
From last year's Next Steps in Signaling BOF:

6.5 James Kempf
   Radio access networks - air is expensive.  Optimize by using less
   bandwidth and more (for example) CPU cycles. Whatever the signaling
   protocol is, it must be very efficient for mobility. Providers pay
   big $$ for the airwaves, they don't want  to use it for signaling,
   but for user data.  Best: do the signaling through the backbone, and
   not over the air if possible.  The signaling must be efficient for
   mobility to minimize signaling while moving from area to area.
   Mobility signalling should be directly coupled to the traffic.
-------------

See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt

Clearly from the provider perspective, user data and signaling are two
different things. Therein lies the debate. For if a user were to do
something that "looks like" signaling, they would intrude on the
territory of the operator.

The problem here: is Messaging the same as signaling? Is Presence the
same as signaling? Is anything we do with SIP really "signaling" or is
it user data?

--
Dean

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple
_______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 10:58:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09118 for ; Wed, 13 Mar 2002 10:58:56 -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 g2DFu4Mb018869; Wed, 13 Mar 2002 10:56:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10627; Wed, 13 Mar 2002 10:59:03 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10616 for ; Wed, 13 Mar 2002 10:58:53 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g2DFuXI22686 for ; Wed, 13 Mar 2002 10:56:33 -0500 (EST) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g2DFuX622676 for ; Wed, 13 Mar 2002 10:56:33 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) Message-ID: <8CA1128D59AD27429985B397118CEDDF78FEB7@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) Thread-Index: AcHGyu9Rpl8M1KvNTA+ZYSDNHhAELgD3KRIw From: "Boyer, David G (Dave)" To: "Sean Olson" , "Petri K. Koskelainen" , "Jonathan Rosenberg" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA10616 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 10:58:37 -0500 Content-Transfer-Encoding: 8bit We consistently use group "persistent" chat where I work. When a user arrives after a discussion has begun he/she can see what has been said. If you use the one-shoot pager model this will not be possible. This is useful for many reasons - a CRM example is a supervisor might need to join in a chat that has been going on between an agent and a customer. He/she will need to see what has been said. Dave Boyer > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Friday, March 08, 2002 12:57 PM > To: Petri K. Koskelainen; Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt > (threading) > > > Group chat is of course a better fit for the > session model. One-time delivery of messages to > a group is a better fit for paging as Petri points > out. How common is this? I can think of a TON of > applications that fit this scenario. What features > of group messaging can't be implemented in a paging > mode? > > /sean > > --- "Petri K. Koskelainen" > wrote: > > > > > A discussion we REALLY need to have, is whether we > > think that the paging > > > model even makes sense for multiparty. I am really > > not convinced. It > > > seems that multiparty paging model is really more > > like email, and that > > > is not what IM is supposed to be. If group IM is > > supposed to be real > > > time, It just works so much better in the session > > model. So many > > > problems (like this one above) just evaporate. > > > > > > Can anyone suggest a reason why the paging model > > is preferrable for > > > group chat? Simplicity is one, but that simplicity > > might be elusive as > > > you try to fill in all the missing pieces. > > > > There are one-shot scenarios which require realtime > > delivery > > to a group. It is quite heavy operation to set up a > > session, > > send one IM, and then close the session. > > Example usage might be an urgent realtime > > announcement to a > > pre-defined group. > > > > > > BR, > > -- > > Petri > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > ===== > Sean Olson > > __________________________________________________ > Do You Yahoo!? > Try FREE Yahoo! Mail - the world's greatest free email! > http://mail.yahoo.com/ > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 11:15:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09772 for ; Wed, 13 Mar 2002 11:15:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2DGC5Mb019041; Wed, 13 Mar 2002 11:12:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10712; Wed, 13 Mar 2002 11:15:04 -0500 (EST) Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10699 for ; Wed, 13 Mar 2002 11:14:16 -0500 (EST) From: duncan.mills@vf.vodafone.co.uk Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id QAA16425; Wed, 13 Mar 2002 16:13:16 GMT Received: from mimesweeper1.vfl.vodafone (mimesweeper1 [10.33.32.67]) by mailguard1 (4.6.1.91) with ESMTP id for ; Wed, 13 Mar 2002 17:11:23 +0100 Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 13 Mar 2002 16:10:51 +0000 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Mar 2002 16:10:50 -0000 Message-Id: To: mhammer@cisco.com, dean.willis@softarmor.com Cc: dean.willis@softarmor.com, pkyzivat@cisco.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something t o do wit message threading) X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.109) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 16:10:44 -0000 Michael, The signalling (packaging in your analogy) costs the operator x. The operator cannot realistically charge the customer for the signalling (packaging), as the customer is unaware of and gets no value from most of it. So the operator is x out of pocket. The operator can charge the customer for the services (the tablets). The services (tablets) cost y. Most operators will charge y+x for services and keep the signalling 'free' for the users. Of course, this is more likely to be x + y + p, where p=profit ;-) Ultimately, the signalling costs operators (especially across the radio interface) and that cost should be kept at a minimum. We have to be careful with things like instant messaging. If I were able to initiate a voice call towards you with some display text that appears on your terminal as "Duncan is calling and wants to know if you still want to meet him for a drink tonight," you could simply ignore the call. So I have passed a message to you that cost me nothing. You then initiate a voice call towards me. This appears on my terminal as "Michael is calling and yes, I'll meet you in the local bar at 8p.m." I don't answer. You have replied to me free of charge. Both of those call set-ups have cost the operator dearly, and he can't really charge for it... Regards, Duncan -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com] Sent: 13 March 2002 15:41 To: Dean Willis Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) Dean, There are some things users care about and will pay for, and other things they won't. For connection oriented services, they consider the "air time" when they have full cut-through to when they get disconnected to be the value. In connectionless services, they care about data packets getting through, not overhead signaling packets. You seem to be suggesting that the customer pay for the time they spend waiting for the signaling to complete the call. Or, you expect them to pay for signaling as well as data-bearing messages. This is analogous to making customers pay for packaging, when all they want is the handful of tablets in the little bottle inside the big box. Near where I live there is an ice-skating rink that charges by the hour. Most people won't put up including in that hour the time taken to fill out forms and select skates. Nor would they pay for time where they are standing in line for that process. Not standing in line, getting to the rink sooner, and skating a full hour have value. This is not just the service provider perspective, but the customer perspective. It's OK to get philosophical, just keep it real. :) Mike At 04:29 PM 3/12/2002 -0600, Dean Willis wrote: > Warning: Philosophical Rant Follows > > The key issue is buried deep in the underlying business > model. In the Internet world, you pay the same for the bits > used to signal a multimedia session as for the bits used by > the multimedia session itself. In the PSTN, the carriers pay > for the signaling used to set up the multimedia session. In > other words, there is NO signaling, as signaling is used in > the PSTN sense, on the Internet -- just application traffic. > There might be messaging applications, routing applications, > management applications, or multimedia applications, but > they're just all applications as far as the underlying > network in concerned. In the PSTN, signaling actually > traverses a separate, specialized network, driven by its own > economic laws. > Reference remaining rant elsewhere. Here's an example. ----------- From last year's Next Steps in Signaling BOF: 6.5 James Kempf Radio access networks - air is expensive. Optimize by using less bandwidth and more (for example) CPU cycles. Whatever the signaling protocol is, it must be very efficient for mobility. Providers pay big $$ for the airwaves, they don't want to use it for signaling, but for user data. Best: do the signaling through the backbone, and not over the air if possible. The signaling must be efficient for mobility to minimize signaling while moving from area to area. Mobility signalling should be directly coupled to the traffic. ------------- See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt Clearly from the provider perspective, user data and signaling are two different things. Therein lies the debate. For if a user were to do something that "looks like" signaling, they would intrude on the territory of the operator. The problem here: is Messaging the same as signaling? Is Presence the same as signaling? Is anything we do with SIP really "signaling" or is it user data? -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 12:09:49 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11512 for ; Wed, 13 Mar 2002 12:09:49 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2DH67Mb019711; Wed, 13 Mar 2002 12:06:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10928; Wed, 13 Mar 2002 12:09:03 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10917 for ; Wed, 13 Mar 2002 12:08:23 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2DH7QU09309; Wed, 13 Mar 2002 11:07:26 -0600 Message-ID: <014e01c1cab1$8ce4c6b0$133fed0c@C1893415A> From: "Dean Willis" To: "Boyer, David G \(Dave\)" , "Sean Olson" , "Petri K. Koskelainen" , "Jonathan Rosenberg" Cc: References: <8CA1128D59AD27429985B397118CEDDF78FEB7@nj7460avexu1.global.avaya.com> Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 11:07:25 -0600 Content-Transfer-Encoding: 7bit > We consistently use group "persistent" chat where I work. > When a user arrives after a discussion has begun he/she > can see what has been said. If you use the one-shoot > pager model this will not be possible. > This is useful for many reasons - a CRM example is a > supervisor might need to join in a chat that has been > going on between an agent and a customer. He/she will > need to see what has been said. That seems to me to be a function of the application server hosting the chat and independent of the message transport used, although it does raise interesting questions for both transport models we've commonly discussed. -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 12:21:42 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11929 for ; Wed, 13 Mar 2002 12:21:41 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2DHI6Mb019853; Wed, 13 Mar 2002 12:18:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10991; Wed, 13 Mar 2002 12:21:03 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10980 for ; Wed, 13 Mar 2002 12:20:23 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2DHIvU09377; Wed, 13 Mar 2002 11:18:57 -0600 Message-ID: <015501c1cab3$28ccc630$133fed0c@C1893415A> From: "Dean Willis" To: "Michael Hammer" Cc: References: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2> <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 11:18:57 -0600 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Michael Hammer ... There are some things users care about and will pay for, and other things they won't. For connection oriented services, they consider the "air time" when they have full cut-through to when they get disconnected to be the value. In connectionless services, they care about data packets getting through, not overhead signaling packets. You seem to be suggesting that the customer pay for the time they spend waiting for the signaling to complete the call. Or, you expect them to pay for signaling as well as data-bearing messages. This is analogous to making customers pay for packaging, when all they want is the handful of tablets in the little bottle inside the big box. -------------------------- No. Actually, I think time-based services, especially in a messaging context, are a silly idea. This is the Internet. People CHOOSE what applications they are going to run. One of the reasons they choose A over B might be that A is more efficient in the way it signals. In your model, people are still paying for the packaging (it's ALWAYS wrapped up in the cost of the product) but since you're hiding it from them and mandating the format, they have no incentive and no mechanism to encourage efficiency. Here's an example. I read my mail frequently over GSM circuit-switched data at 9600 bps. This is expensive. So I use SSH with compression, which beefs up the security immensely and generally saves me about 25%. Now, what part of that traffic was signaling, and what part application? I'd say only the GSM control traffic that set up the call was "signaling" and everything I sent over the circuit, i.e. all my IP data, was application.How is this different from what we're talking about with SIMPLE? The INTERNET is not a circuit switched phone network, and it's not so simple as phone people assume to differentiate signaling from application data. But this has gotten rather far afield for this list. -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 12:35:59 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12420 for ; Wed, 13 Mar 2002 12:35:58 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2DHW4Mb020121; Wed, 13 Mar 2002 12:32:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11069; Wed, 13 Mar 2002 12:35:04 -0500 (EST) Received: from web11601.mail.yahoo.com (web11601.mail.yahoo.com [216.136.172.53]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA11054 for ; Wed, 13 Mar 2002 12:34:56 -0500 (EST) Message-ID: <20020313173406.68306.qmail@web11601.mail.yahoo.com> Received: from [131.107.3.86] by web11601.mail.yahoo.com via HTTP; Wed, 13 Mar 2002 09:34:06 PST From: Sean Olson Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) To: "Boyer, David G \(Dave\)" , "Petri K. Koskelainen" , Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com In-Reply-To: <8CA1128D59AD27429985B397118CEDDF78FEB7@nj7460avexu1.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 09:34:06 -0800 (PST) There is no reason this cannot be achieved with the paging model. In fact neither model directly provides support for what you are talking about -- and neither prevents building what you want. I can see the usefulness of this feature, but I expect you will need/want a separate channel to look at the history of a chat "session". If nothing else, you would want to be able to separate past messages from live chat without mistakenly discarding a "past" message as being out of context. /sean --- "Boyer, David G (Dave)" wrote: > We consistently use group "persistent" chat where I > work. > When a user arrives after a discussion has begun > he/she > can see what has been said. If you use the > one-shoot > pager model this will not be possible. > This is useful for many reasons - a CRM example is a > > supervisor might need to join in a chat that has > been > going on between an agent and a customer. He/she > will > need to see what has been said. > > Dave Boyer ===== Sean Olson __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 14:09:58 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15369 for ; Wed, 13 Mar 2002 14:09:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2DJ4ZMb020916; Wed, 13 Mar 2002 14:04:38 -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 OAA11366; Wed, 13 Mar 2002 14:07:10 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11355 for ; Wed, 13 Mar 2002 14:06:29 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2DJ5vJ02580; Wed, 13 Mar 2002 14:05:57 -0500 (EST) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAR74509; Wed, 13 Mar 2002 14:00:29 -0500 (EST) Message-Id: <4.3.2.7.2.20020313135918.00b65b48@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Dean Willis" From: Michael Hammer Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) Cc: In-Reply-To: <015501c1cab3$28ccc630$133fed0c@C1893415A> References: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2> <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 14:05:35 -0500 Dean,

Agree with the general sentiment of your reply.  But, inherent in your previous emails was the idea that the service provider could somehow get revenue from the IMs intermingled with the session setup messages to cover the cost of over-provisioning the proxies to cover peak IM storms, yet keep signaling message delay low.

This lead to the thought that you must charge per message for both IM (data) and for SIP messages (signaling).  All I was questioning was whether the user will see the value in paying for the signaling, that for the most part is invisible to him, and perhaps beyond his control to account for.  I see that as problematic.

Simply redesigning to make something that once was network internal to be user-provided does not mean the user will appreciate why he pays more.

Mike



At 11:18 AM 3/13/2002 -0600, Dean Willis wrote:
----- Original Message -----
From: Michael Hammer
...
There are some things users care about and will pay for, and other
things they won't.  For connection oriented services, they consider the
"air time" when they have full cut-through to when they get disconnected
to be the value.  In connectionless services, they care about data
packets getting through, not overhead signaling packets.

You seem to be suggesting that the customer pay for the time they spend
waiting for the signaling to complete the call.  Or, you expect them to
pay for signaling as well as data-bearing messages.  This is analogous
to making customers pay for packaging, when all they want is the handful
of tablets in the little bottle inside the big box.
--------------------------

No. Actually, I think time-based services, especially in a messaging
context, are a silly idea.

This is the Internet. People CHOOSE what applications they are going to
run. One of the reasons they choose A over B might be that A is more
efficient in the way it signals.

In your model, people are still paying for the packaging (it's ALWAYS
wrapped up in the cost of the product) but since you're hiding it from
them and mandating the format, they have no incentive and no mechanism
to encourage efficiency.

Here's an example. I read my mail frequently over GSM circuit-switched
data at 9600 bps. This is expensive. So I use SSH with compression,
which beefs up the security immensely and generally saves me about 25%.
Now, what part of that traffic was signaling, and what part application?
I'd say only the GSM control traffic that set up the call was
"signaling" and everything I sent over the circuit, i.e. all my IP data,
was application.How is this different from what we're talking about with
SIMPLE?

The INTERNET is not a circuit switched phone network, and it's not so
simple as phone people assume to differentiate signaling from
application data.

But this has gotten rather far afield for this list.

--
Dean
_______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 15:51:02 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19012 for ; Wed, 13 Mar 2002 15:51:01 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2DKlEMb021992; Wed, 13 Mar 2002 15:47:14 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11722; Wed, 13 Mar 2002 15:50:05 -0500 (EST) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11709 for ; Wed, 13 Mar 2002 15:49:47 -0500 (EST) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2DKmW207339; Wed, 13 Mar 2002 14:48:32 -0600 (CST) From: "Ben Campbell" To: "Michael Hammer" , "Dean Willis" Cc: "'Dean Willis'" , "'Paul Kyzivat'" , Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 14:47:15 -0600 Content-Transfer-Encoding: 7bit You example only works when you apply a billing model (per minute billing) to a medium (IP applications) where it doesn't make sense. Indeed, I think the per-minute model is not so much expected by users--it is just the carriers don't know how to bill any other way. If you applied a more IP Centric billing model (charge per byte), then you can easily charge for signal and user data the same way. My GPRS service provider charges for GPRS data in exactly this manner--if I run a SIMPLE service across it, they just see bytes. A signal byte and a user byte are indistinguishable. My personal nightmare is hearing that carriers want to charge X per byte, except for bytes that were in SIP messages. -----Original Message----- From: simple-admin@mailman.dynamicsoft.com [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer Sent: Wednesday, March 13, 2002 9:41 AM To: Dean Willis Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) Dean, There are some things users care about and will pay for, and other things they won't. For connection oriented services, they consider the "air time" when they have full cut-through to when they get disconnected to be the value. In connectionless services, they care about data packets getting through, not overhead signaling packets. You seem to be suggesting that the customer pay for the time they spend waiting for the signaling to complete the call. Or, you expect them to pay for signaling as well as data-bearing messages. This is analogous to making customers pay for packaging, when all they want is the handful of tablets in the little bottle inside the big box. Near where I live there is an ice-skating rink that charges by the hour. Most people won't put up including in that hour the time taken to fill out forms and select skates. Nor would they pay for time where they are standing in line for that process. Not standing in line, getting to the rink sooner, and skating a full hour have value. This is not just the service provider perspective, but the customer perspective. It's OK to get philosophical, just keep it real. :) Mike At 04:29 PM 3/12/2002 -0600, Dean Willis wrote: > Warning: Philosophical Rant Follows > > The key issue is buried deep in the underlying business > model. In the Internet world, you pay the same for the bits > used to signal a multimedia session as for the bits used by > the multimedia session itself. In the PSTN, the carriers pay > for the signaling used to set up the multimedia session. In > other words, there is NO signaling, as signaling is used in > the PSTN sense, on the Internet -- just application traffic. > There might be messaging applications, routing applications, > management applications, or multimedia applications, but > they're just all applications as far as the underlying > network in concerned. In the PSTN, signaling actually > traverses a separate, specialized network, driven by its own > economic laws. > Reference remaining rant elsewhere. Here's an example. ----------- From last year's Next Steps in Signaling BOF: 6.5 James Kempf Radio access networks - air is expensive. Optimize by using less bandwidth and more (for example) CPU cycles. Whatever the signaling protocol is, it must be very efficient for mobility. Providers pay big $$ for the airwaves, they don't want to use it for signaling, but for user data. Best: do the signaling through the backbone, and not over the air if possible. The signaling must be efficient for mobility to minimize signaling while moving from area to area. Mobility signalling should be directly coupled to the traffic. ------------- See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt Clearly from the provider perspective, user data and signaling are two different things. Therein lies the debate. For if a user were to do something that "looks like" signaling, they would intrude on the territory of the operator. The problem here: is Messaging the same as signaling? Is Presence the same as signaling? Is anything we do with SIP really "signaling" or is it user data? -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 16:04:13 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19382 for ; Wed, 13 Mar 2002 16:04:11 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2DKx8Mb022190; Wed, 13 Mar 2002 15:59:08 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11781; Wed, 13 Mar 2002 16:02:05 -0500 (EST) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11770 for ; Wed, 13 Mar 2002 16:01:03 -0500 (EST) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2DKxh208292; Wed, 13 Mar 2002 14:59:43 -0600 (CST) From: "Ben Campbell" To: "Dean Willis" , "Jonathan Rosenberg" , "Petri K. Koskelainen" Cc: Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <009501c1c7b3$4f356fa0$133fed0c@C1893415A> Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 14:58:26 -0600 Content-Transfer-Encoding: 7bit I think think I agree with Dean in that it is not so much the _group_ aspect as the _chat_ aspect that indicates the use of a session. There are perfectly good page mode applications for groups. It is the _conference_ aspects that make sessions interesting--things like knowing who is participating at any time, association with other media streams, etc. If all I want to do is send a quick, short message to multiple people, I rather hope I do not have to set up a session to do it. > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Dean Willis > Sent: Saturday, March 09, 2002 3:42 PM > To: Jonathan Rosenberg; Petri K. Koskelainen > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt > (threading) > > > Jonathan asked: > > A discussion we REALLY need to have, is whether we think that the paging > > model even makes sense for multiparty. I am really not convinced. It > > seems that multiparty paging model is really more like email, and that > > is not what IM is supposed to be. If group IM is supposed to be real > > time, It just works so much better in the session model. So many > > problems (like this one above) just evaporate. > > > > Can anyone suggest a reason why the paging model is preferrable for > > group chat? Simplicity is one, but that simplicity might be elusive as > > you try to fill in all the missing pieces. > > Well, if some of your participants are coming and going, you have an open > question about whether store-and-forward delivery to those paticipants is > appropriate. > > If we do store-and-forward, then it really IS like fast email, and I would > posit that the paging model makes excellent sense. If on the > other hand the > model is a "chat room" where unless you are in the room, you never see the > message, then a session model makes more sense. > > So I suggest that we may wish to consider distinguishing these two models > from a requirements analysis perspective. > > I believe if we follow this to a logical conclusion that we'll end up with > two very different implementations serving the different modalities, and a > couple of logical "transition points" where messaging sequence > move from one > mode to the other. > > -- > Dean > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 17:45:12 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22905 for ; Wed, 13 Mar 2002 17:45:11 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2DMf6Mb023334; Wed, 13 Mar 2002 17:41:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12166; Wed, 13 Mar 2002 17:44:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12155 for ; Wed, 13 Mar 2002 17:43:24 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2DMgqo02044; Wed, 13 Mar 2002 17:42:52 -0500 (EST) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAR77007; Wed, 13 Mar 2002 17:37:23 -0500 (EST) Message-Id: <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ben Campbell" From: Michael Hammer Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) Cc: "Dean Willis" , "'Dean Willis'" , "'Paul Kyzivat'" , In-Reply-To: References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 17:42:28 -0500 Ben, When you consider RTP over IP, which fits your "IP application" definition, whether you charge per packet or realize that statistically X packets and Y minutes is "six of one, half a dozen of the other" then there are some models where per minute works out to be the same value. How do you reconcile volume charging with the two things that I noticed about my two services: ISP: Bills me a flat monthly fee for data service. Mobile phone: Bills me flat monthly fee for phone service, with per minute charges above an agreed on number of "free" minutes. It didn't used to be like that. Seems you are suggesting a trend-reversal or at least an exception to the rule. The earlier models of charging per data connection minute or per minute of call did not encourage usage and therefore generate enough revenue. Per byte charges can generate revenue, but only if it doesn't discourage use. Will the per-byte prices be low enough to encourage use, yet still cover the cost of over-provisioning the network to keep setup delay low? Will connection-less IM users pay a premium to make sure that connection-oriented RTP-flow users don't experience setup delays? Tell me, who pays for excess capacity? This could be a competitive discriminator. Mike At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote: >You example only works when you apply a billing model (per minute billing) >to a medium (IP applications) where it doesn't make sense. Indeed, I think >the per-minute model is not so much expected by users--it is just the >carriers don't know how to bill any other way. > >If you applied a more IP Centric billing model (charge per byte), then you >can easily charge for signal and user data the same way. My GPRS service >provider charges for GPRS data in exactly this manner--if I run a SIMPLE >service across it, they just see bytes. A signal byte and a user byte are >indistinguishable. > >My personal nightmare is hearing that carriers want to charge X per byte, >except for bytes that were in SIP messages. > > >-----Original Message----- >From: simple-admin@mailman.dynamicsoft.com >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer >Sent: Wednesday, March 13, 2002 9:41 AM >To: Dean Willis >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com >Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to >do wit message threading) > > >Dean, > >There are some things users care about and will pay for, and other things >they won't. For connection oriented services, they consider the "air time" >when they have full cut-through to when they get disconnected to be the >value. In connectionless services, they care about data packets getting >through, not overhead signaling packets. > >You seem to be suggesting that the customer pay for the time they spend >waiting for the signaling to complete the call. Or, you expect them to pay >for signaling as well as data-bearing messages. This is analogous to making >customers pay for packaging, when all they want is the handful of tablets in >the little bottle inside the big box. > >Near where I live there is an ice-skating rink that charges by the hour. >Most people won't put up including in that hour the time taken to fill out >forms and select skates. Nor would they pay for time where they are >standing in line for that process. Not standing in line, getting to the >rink sooner, and skating a full hour have value. > >This is not just the service provider perspective, but the customer >perspective. > >It's OK to get philosophical, just keep it real. :) > >Mike > > >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote: > > > > Warning: Philosophical Rant Follows > > > > The key issue is buried deep in the underlying business > > model. In the Internet world, you pay the same for the bits > > used to signal a multimedia session as for the bits used by > > the multimedia session itself. In the PSTN, the carriers pay > > for the signaling used to set up the multimedia session. In > > other words, there is NO signaling, as signaling is used in > > the PSTN sense, on the Internet -- just application traffic. > > There might be messaging applications, routing applications, > > management applications, or multimedia applications, but > > they're just all applications as far as the underlying > > network in concerned. In the PSTN, signaling actually > > traverses a separate, specialized network, driven by its own > > economic laws. > > > >Reference remaining rant elsewhere. > >Here's an example. > >----------- > From last year's Next Steps in Signaling BOF: > >6.5 James Kempf > Radio access networks - air is expensive. Optimize by using less > bandwidth and more (for example) CPU cycles. Whatever the signaling > protocol is, it must be very efficient for mobility. Providers pay > big $$ for the airwaves, they don't want to use it for signaling, > but for user data. Best: do the signaling through the backbone, and > not over the air if possible. The signaling must be efficient for > mobility to minimize signaling while moving from area to area. > Mobility signalling should be directly coupled to the traffic. >------------- > >See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt > >Clearly from the provider perspective, user data and signaling are two >different things. Therein lies the debate. For if a user were to do >something that "looks like" signaling, they would intrude on the >territory of the operator. > >The problem here: is Messaging the same as signaling? Is Presence the >same as signaling? Is anything we do with SIP really "signaling" or is >it user data? > >-- >Dean > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple >_______________________________________________ simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 18:07:42 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23888 for ; Wed, 13 Mar 2002 18:07:42 -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 g2DN46Mb023602; Wed, 13 Mar 2002 18:04:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12265; Wed, 13 Mar 2002 18:07:04 -0500 (EST) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12254 for ; Wed, 13 Mar 2002 18:06:23 -0500 (EST) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2DN5M218984; Wed, 13 Mar 2002 17:05:23 -0600 (CST) From: "Ben Campbell" To: "Michael Hammer" Cc: "Dean Willis" , "'Dean Willis'" , "'Paul Kyzivat'" , Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com> Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 17:04:06 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, March 13, 2002 4:42 PM > To: Ben Campbell > Cc: Dean Willis; 'Dean Willis'; 'Paul Kyzivat'; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something > to do wit message threading) > > > Ben, > > When you consider RTP over IP, which fits your "IP application" > definition, > whether you charge per packet or realize that statistically X > packets and Y > minutes is "six of one, half a dozen of the other" then there are some > models where per minute works out to be the same value. But this only works for rtp type applications, and I fully expect to run other IP applications as well. You very quickly fall into the twilight zone of cross-layer usage counting, where you charge per minute for RTP traffic, but per byte for others. > > How do you reconcile volume charging with the two things that I noticed > about my two services: ISP: Bills me a flat monthly fee for data > service. Mobile phone: Bills me flat monthly fee for phone > service, with > per minute charges above an agreed on number of "free" minutes. > It didn't > used to be like that. Seems you are suggesting a trend-reversal or at > least an exception to the rule. Yes, it is a trend reversal. Your ISP charges you flat rate because that is what the market pretty much requires. But, if you have a residential level of service, they probably also have policies that let them harrass you if, in their sole opinion, you are using to many bytes in your so-called unlimited flat rate service--creating a whole new class of double-speak about limited unlimited service. A per-byte usage, where the per byte cost for the average user added up to the same as the flat rate price would do much to rationalize these plans. (And of course, flat rate plans are a bit of a red-herring in this discussion--if you aren't billing for bytes _or_minutes_ then who cares if they are user data or signal data?) As for the mobile phone, they are charging per-minute for holding up wireless network resources. I am glad to see that the GPRS carriers in the US are _not_ trying to shoehorn per-minute billing for GPRS data. (Their per-byte charges are rediculously high, but that is another problem) > > The earlier models of charging per data connection minute or per > minute of > call did not encourage usage and therefore generate enough revenue. Per > byte charges can generate revenue, but only if it doesn't discourage use. > > Will the per-byte prices be low enough to encourage use, yet still cover > the cost of over-provisioning the network to keep setup delay low? Will > connection-less IM users pay a premium to make sure that > connection-oriented RTP-flow users don't experience setup delays? > Tell me, > who pays for excess capacity? This could be a competitive discriminator. These are all business model issues that are equally true in flat-rate and per-minute models. I assert that an IP carrier that can figure out how to price and market a per-byte service will have a significant competitive advantage over an IP carrier that tries to perserve a legacy per-minute model--even if the average revenue per subscriber is identical. This is due to simpler network accounting and management if for no other reason. Figuring out how to price and market it such a service is business magic, not engineering magic. > > Mike > > > At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote: > >You example only works when you apply a billing model (per > minute billing) > >to a medium (IP applications) where it doesn't make sense. > Indeed, I think > >the per-minute model is not so much expected by users--it is just the > >carriers don't know how to bill any other way. > > > >If you applied a more IP Centric billing model (charge per > byte), then you > >can easily charge for signal and user data the same way. My GPRS service > >provider charges for GPRS data in exactly this manner--if I run a SIMPLE > >service across it, they just see bytes. A signal byte and a user byte are > >indistinguishable. > > > >My personal nightmare is hearing that carriers want to charge X per byte, > >except for bytes that were in SIP messages. > > > > > >-----Original Message----- > >From: simple-admin@mailman.dynamicsoft.com > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer > >Sent: Wednesday, March 13, 2002 9:41 AM > >To: Dean Willis > >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com > >Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was > something to > >do wit message threading) > > > > > >Dean, > > > >There are some things users care about and will pay for, and other things > >they won't. For connection oriented services, they consider the > "air time" > >when they have full cut-through to when they get disconnected to be the > >value. In connectionless services, they care about data packets getting > >through, not overhead signaling packets. > > > >You seem to be suggesting that the customer pay for the time they spend > >waiting for the signaling to complete the call. Or, you expect > them to pay > >for signaling as well as data-bearing messages. This is > analogous to making > >customers pay for packaging, when all they want is the handful > of tablets in > >the little bottle inside the big box. > > > >Near where I live there is an ice-skating rink that charges by the hour. > >Most people won't put up including in that hour the time taken > to fill out > >forms and select skates. Nor would they pay for time where they are > >standing in line for that process. Not standing in line, getting to the > >rink sooner, and skating a full hour have value. > > > >This is not just the service provider perspective, but the customer > >perspective. > > > >It's OK to get philosophical, just keep it real. :) > > > >Mike > > > > > >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote: > > > > > > > Warning: Philosophical Rant Follows > > > > > > The key issue is buried deep in the underlying business > > > model. In the Internet world, you pay the same for the bits > > > used to signal a multimedia session as for the bits used by > > > the multimedia session itself. In the PSTN, the carriers pay > > > for the signaling used to set up the multimedia session. In > > > other words, there is NO signaling, as signaling is used in > > > the PSTN sense, on the Internet -- just application traffic. > > > There might be messaging applications, routing applications, > > > management applications, or multimedia applications, but > > > they're just all applications as far as the underlying > > > network in concerned. In the PSTN, signaling actually > > > traverses a separate, specialized network, driven by its own > > > economic laws. > > > > > > >Reference remaining rant elsewhere. > > > >Here's an example. > > > >----------- > > From last year's Next Steps in Signaling BOF: > > > >6.5 James Kempf > > Radio access networks - air is expensive. Optimize by using less > > bandwidth and more (for example) CPU cycles. Whatever the signaling > > protocol is, it must be very efficient for mobility. Providers pay > > big $$ for the airwaves, they don't want to use it for signaling, > > but for user data. Best: do the signaling through the backbone, and > > not over the air if possible. The signaling must be efficient for > > mobility to minimize signaling while moving from area to area. > > Mobility signalling should be directly coupled to the traffic. > >------------- > > > >See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt > > > >Clearly from the provider perspective, user data and signaling are two > >different things. Therein lies the debate. For if a user were to do > >something that "looks like" signaling, they would intrude on the > >territory of the operator. > > > >The problem here: is Messaging the same as signaling? Is Presence the > >same as signaling? Is anything we do with SIP really "signaling" or is > >it user data? > > > >-- > >Dean > > > >_______________________________________________ > >simple mailing list > >simple@mailman.dynamicsoft.com > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > >_______________________________________________ simple mailing list > >simple@mailman.dynamicsoft.com > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 18:11:50 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24056 for ; Wed, 13 Mar 2002 18:11:45 -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 g2DN83Mb023714; Wed, 13 Mar 2002 18:08:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12322; Wed, 13 Mar 2002 18:11:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12311 for ; Wed, 13 Mar 2002 18:10:28 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2DN9uJ04667; Wed, 13 Mar 2002 18:09:56 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG72673; Wed, 13 Mar 2002 18:12:49 -0500 (EST) Message-ID: <3C8FDC2F.939FBDE2@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Hammer CC: Ben Campbell , Dean Willis , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 18:09:35 -0500 Content-Transfer-Encoding: 7bit While it is nice to get something for nothing, in the long term somebody has to pay for the infrastructure that provides the bandwidth. Personally, I would not mind paying for usage based on a fair metric. Charging per byte makes sense, while charging for elapsed time does not. Charging for guaranteed bandwidth over some time period might make sense, but more likely it would make sense to charge more per byte for higher priority bytes. What would be really unfair would be to use the same channel, with the same bandwidth guarantees and charge one price for IM bytes and a different price for voice bytes. If you are charging by the byte, people have an incentive to balance better quality against the cost of the extra bytes needed to deliver that quality. Charged by the byte, IM won't be free, but may seem to be because it uses vastly fewer bytes than even a short voice message, and can get by with with lower priority service as well. As long as signalling bytes used for call setup travel the same network as the voice bytes, and are billed at the same rate, it is unlikely that callers would notice much effect on their bills because the quantities are so much smaller than for voice content. The most noticable factor might be due to roundoff - an unsuccessful call might be charged at $0.01 rather than being free. The excess capacity required to provide good service can hopefully be recovered in the surcharge for priority service. Paul Michael Hammer wrote: > > Ben, > > When you consider RTP over IP, which fits your "IP application" definition, > whether you charge per packet or realize that statistically X packets and Y > minutes is "six of one, half a dozen of the other" then there are some > models where per minute works out to be the same value. > > How do you reconcile volume charging with the two things that I noticed > about my two services: ISP: Bills me a flat monthly fee for data > service. Mobile phone: Bills me flat monthly fee for phone service, with > per minute charges above an agreed on number of "free" minutes. It didn't > used to be like that. Seems you are suggesting a trend-reversal or at > least an exception to the rule. > > The earlier models of charging per data connection minute or per minute of > call did not encourage usage and therefore generate enough revenue. Per > byte charges can generate revenue, but only if it doesn't discourage use. > > Will the per-byte prices be low enough to encourage use, yet still cover > the cost of over-provisioning the network to keep setup delay low? Will > connection-less IM users pay a premium to make sure that > connection-oriented RTP-flow users don't experience setup delays? Tell me, > who pays for excess capacity? This could be a competitive discriminator. > > Mike > > At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote: > >You example only works when you apply a billing model (per minute billing) > >to a medium (IP applications) where it doesn't make sense. Indeed, I think > >the per-minute model is not so much expected by users--it is just the > >carriers don't know how to bill any other way. > > > >If you applied a more IP Centric billing model (charge per byte), then you > >can easily charge for signal and user data the same way. My GPRS service > >provider charges for GPRS data in exactly this manner--if I run a SIMPLE > >service across it, they just see bytes. A signal byte and a user byte are > >indistinguishable. > > > >My personal nightmare is hearing that carriers want to charge X per byte, > >except for bytes that were in SIP messages. > > > > > >-----Original Message----- > >From: simple-admin@mailman.dynamicsoft.com > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer > >Sent: Wednesday, March 13, 2002 9:41 AM > >To: Dean Willis > >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com > >Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to > >do wit message threading) > > > > > >Dean, > > > >There are some things users care about and will pay for, and other things > >they won't. For connection oriented services, they consider the "air time" > >when they have full cut-through to when they get disconnected to be the > >value. In connectionless services, they care about data packets getting > >through, not overhead signaling packets. > > > >You seem to be suggesting that the customer pay for the time they spend > >waiting for the signaling to complete the call. Or, you expect them to pay > >for signaling as well as data-bearing messages. This is analogous to making > >customers pay for packaging, when all they want is the handful of tablets in > >the little bottle inside the big box. > > > >Near where I live there is an ice-skating rink that charges by the hour. > >Most people won't put up including in that hour the time taken to fill out > >forms and select skates. Nor would they pay for time where they are > >standing in line for that process. Not standing in line, getting to the > >rink sooner, and skating a full hour have value. > > > >This is not just the service provider perspective, but the customer > >perspective. > > > >It's OK to get philosophical, just keep it real. :) > > > >Mike > > > > > >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote: > > > > > > > Warning: Philosophical Rant Follows > > > > > > The key issue is buried deep in the underlying business > > > model. In the Internet world, you pay the same for the bits > > > used to signal a multimedia session as for the bits used by > > > the multimedia session itself. In the PSTN, the carriers pay > > > for the signaling used to set up the multimedia session. In > > > other words, there is NO signaling, as signaling is used in > > > the PSTN sense, on the Internet -- just application traffic. > > > There might be messaging applications, routing applications, > > > management applications, or multimedia applications, but > > > they're just all applications as far as the underlying > > > network in concerned. In the PSTN, signaling actually > > > traverses a separate, specialized network, driven by its own > > > economic laws. > > > > > > >Reference remaining rant elsewhere. > > > >Here's an example. > > > >----------- > > From last year's Next Steps in Signaling BOF: > > > >6.5 James Kempf > > Radio access networks - air is expensive. Optimize by using less > > bandwidth and more (for example) CPU cycles. Whatever the signaling > > protocol is, it must be very efficient for mobility. Providers pay > > big $$ for the airwaves, they don't want to use it for signaling, > > but for user data. Best: do the signaling through the backbone, and > > not over the air if possible. The signaling must be efficient for > > mobility to minimize signaling while moving from area to area. > > Mobility signalling should be directly coupled to the traffic. > >------------- > > > >See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt > > > >Clearly from the provider perspective, user data and signaling are two > >different things. Therein lies the debate. For if a user were to do > >something that "looks like" signaling, they would intrude on the > >territory of the operator. > > > >The problem here: is Messaging the same as signaling? Is Presence the > >same as signaling? Is anything we do with SIP really "signaling" or is > >it user data? > > > >-- > >Dean > > > >_______________________________________________ > >simple mailing list > >simple@mailman.dynamicsoft.com > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > >_______________________________________________ simple mailing list > >simple@mailman.dynamicsoft.com > >http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 18:22:48 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24371 for ; Wed, 13 Mar 2002 18:22:48 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2DNJ4Mb023861; Wed, 13 Mar 2002 18:19:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12404; Wed, 13 Mar 2002 18:22:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12393 for ; Wed, 13 Mar 2002 18:21:20 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2DNKmZ05538; Wed, 13 Mar 2002 18:20:49 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG72735; Wed, 13 Mar 2002 18:23:42 -0500 (EST) Message-ID: <3C8FDEBC.884C4FE7@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: Michael Hammer , Dean Willis , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 18:20:28 -0500 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > These are all business model issues that are equally true in flat-rate and > per-minute models. I assert that an IP carrier that can figure out how to > price and market a per-byte service will have a significant competitive > advantage over an IP carrier that tries to perserve a legacy per-minute > model--even if the average revenue per subscriber is identical. This is due > to simpler network accounting and management if for no other reason. > > Figuring out how to price and market it such a service is business magic, > not engineering magic. To me the attractiveness of this model is that it is a fairer model - more consistent with resources consumed. The trick is that this has to be perceived as fair by the people purchasing the service. I can be comfortable with per-byte billing once I figure out how much a typical phone call will cost me. But my mother will probably never perceive per-byte billing as fair because she will never understand what it means. I can imagine two pricing models coexisting. Some people might simply have per-byte network access charges, and be free to run voice, data, whatever over them using equipment of their choice. Others might contract for by-the-minute or flat-rate phone service, with the service provider providing the network access and the devices that use it. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 19:06:01 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25302 for ; Wed, 13 Mar 2002 19:05:56 -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 g2E027Mb024305; Wed, 13 Mar 2002 19:02:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12566; Wed, 13 Mar 2002 19:05:06 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12551 for ; Wed, 13 Mar 2002 19:04:57 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2E04PY08322; Wed, 13 Mar 2002 19:04:25 -0500 (EST) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAR77666; Wed, 13 Mar 2002 18:58:57 -0500 (EST) Message-Id: <4.3.2.7.2.20020313190133.03dc97b8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Paul Kyzivat From: Michael Hammer Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) Cc: Ben Campbell , Dean Willis , simple@mailman.dynamicsoft.com In-Reply-To: <3C8FDC2F.939FBDE2@cisco.com> References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 19:04:02 -0500 Paul, As long as signaling gets priority over IM and doing session setup doesn't turn into a world wide wait, I can go along with running the packets over the same infrastructure. Mike At 06:09 PM 3/13/2002 -0500, Paul Kyzivat wrote: >While it is nice to get something for nothing, in the long term somebody >has to pay for the infrastructure that provides the bandwidth. Personally, >I would not mind paying >for usage based on a fair metric. Charging per byte makes sense, while >charging for elapsed time does not. Charging for guaranteed bandwidth over >some time period might >make sense, but more likely it would make sense to charge more per byte >for higher priority bytes. > >What would be really unfair would be to use the same channel, with the >same bandwidth guarantees and charge one price for IM bytes and a >different price for voice bytes. > >If you are charging by the byte, people have an incentive to balance >better quality against the cost of the extra bytes needed to deliver that >quality. > >Charged by the byte, IM won't be free, but may seem to be because it uses >vastly fewer bytes than even a short voice message, and can get by with >with lower priority >service as well. > >As long as signalling bytes used for call setup travel the same network as >the voice bytes, and are billed at the same rate, it is unlikely that >callers would notice much >effect on their bills because the quantities are so much smaller than for >voice content. The most noticable factor might be due to roundoff - an >unsuccessful call might be >charged at $0.01 rather than being free. > >The excess capacity required to provide good service can hopefully be >recovered in the surcharge for priority service. > > Paul > >Michael Hammer wrote: > > > > Ben, > > > > When you consider RTP over IP, which fits your "IP application" definition, > > whether you charge per packet or realize that statistically X packets and Y > > minutes is "six of one, half a dozen of the other" then there are some > > models where per minute works out to be the same value. > > > > How do you reconcile volume charging with the two things that I noticed > > about my two services: ISP: Bills me a flat monthly fee for data > > service. Mobile phone: Bills me flat monthly fee for phone service, with > > per minute charges above an agreed on number of "free" minutes. It didn't > > used to be like that. Seems you are suggesting a trend-reversal or at > > least an exception to the rule. > > > > The earlier models of charging per data connection minute or per minute of > > call did not encourage usage and therefore generate enough revenue. Per > > byte charges can generate revenue, but only if it doesn't discourage use. > > > > Will the per-byte prices be low enough to encourage use, yet still cover > > the cost of over-provisioning the network to keep setup delay low? Will > > connection-less IM users pay a premium to make sure that > > connection-oriented RTP-flow users don't experience setup delays? Tell me, > > who pays for excess capacity? This could be a competitive discriminator. > > > > Mike > > > > At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote: > > >You example only works when you apply a billing model (per minute billing) > > >to a medium (IP applications) where it doesn't make sense. Indeed, I think > > >the per-minute model is not so much expected by users--it is just the > > >carriers don't know how to bill any other way. > > > > > >If you applied a more IP Centric billing model (charge per byte), then you > > >can easily charge for signal and user data the same way. My GPRS service > > >provider charges for GPRS data in exactly this manner--if I run a SIMPLE > > >service across it, they just see bytes. A signal byte and a user byte are > > >indistinguishable. > > > > > >My personal nightmare is hearing that carriers want to charge X per byte, > > >except for bytes that were in SIP messages. > > > > > > > > >-----Original Message----- > > >From: simple-admin@mailman.dynamicsoft.com > > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer > > >Sent: Wednesday, March 13, 2002 9:41 AM > > >To: Dean Willis > > >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com > > >Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was > something to > > >do wit message threading) > > > > > > > > >Dean, > > > > > >There are some things users care about and will pay for, and other things > > >they won't. For connection oriented services, they consider the "air > time" > > >when they have full cut-through to when they get disconnected to be the > > >value. In connectionless services, they care about data packets getting > > >through, not overhead signaling packets. > > > > > >You seem to be suggesting that the customer pay for the time they spend > > >waiting for the signaling to complete the call. Or, you expect them > to pay > > >for signaling as well as data-bearing messages. This is analogous to > making > > >customers pay for packaging, when all they want is the handful of > tablets in > > >the little bottle inside the big box. > > > > > >Near where I live there is an ice-skating rink that charges by the hour. > > >Most people won't put up including in that hour the time taken to fill out > > >forms and select skates. Nor would they pay for time where they are > > >standing in line for that process. Not standing in line, getting to the > > >rink sooner, and skating a full hour have value. > > > > > >This is not just the service provider perspective, but the customer > > >perspective. > > > > > >It's OK to get philosophical, just keep it real. :) > > > > > >Mike > > > > > > > > >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote: > > > > > > > > > > Warning: Philosophical Rant Follows > > > > > > > > The key issue is buried deep in the underlying business > > > > model. In the Internet world, you pay the same for the bits > > > > used to signal a multimedia session as for the bits used by > > > > the multimedia session itself. In the PSTN, the carriers pay > > > > for the signaling used to set up the multimedia session. In > > > > other words, there is NO signaling, as signaling is used in > > > > the PSTN sense, on the Internet -- just application traffic. > > > > There might be messaging applications, routing applications, > > > > management applications, or multimedia applications, but > > > > they're just all applications as far as the underlying > > > > network in concerned. In the PSTN, signaling actually > > > > traverses a separate, specialized network, driven by its own > > > > economic laws. > > > > > > > > > >Reference remaining rant elsewhere. > > > > > >Here's an example. > > > > > >----------- > > > From last year's Next Steps in Signaling BOF: > > > > > >6.5 James Kempf > > > Radio access networks - air is expensive. Optimize by using less > > > bandwidth and more (for example) CPU cycles. Whatever the signaling > > > protocol is, it must be very efficient for mobility. Providers pay > > > big $$ for the airwaves, they don't want to use it for signaling, > > > but for user data. Best: do the signaling through the backbone, and > > > not over the air if possible. The signaling must be efficient for > > > mobility to minimize signaling while moving from area to area. > > > Mobility signalling should be directly coupled to the traffic. > > >------------- > > > > > >See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt > > > > > >Clearly from the provider perspective, user data and signaling are two > > >different things. Therein lies the debate. For if a user were to do > > >something that "looks like" signaling, they would intrude on the > > >territory of the operator. > > > > > >The problem here: is Messaging the same as signaling? Is Presence the > > >same as signaling? Is anything we do with SIP really "signaling" or is > > >it user data? > > > > > >-- > > >Dean > > > > > >_______________________________________________ > > >simple mailing list > > >simple@mailman.dynamicsoft.com > > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > > >_______________________________________________ simple mailing list > > >simple@mailman.dynamicsoft.com > > >http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 13 19:17:52 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25543 for ; Wed, 13 Mar 2002 19:17:52 -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 g2E0E4Mb024429; Wed, 13 Mar 2002 19:14:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12625; Wed, 13 Mar 2002 19:17:04 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12614 for ; Wed, 13 Mar 2002 19:16:46 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA20976; Wed, 13 Mar 2002 19:15:51 -0500 (EST) Received: from cs.columbia.edu (dyn-wireless-244-121.dyn.columbia.edu [160.39.244.121]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2E0FoNB007135 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Mar 2002 19:15:50 -0500 (EST) Message-ID: <3C8FEBA1.8054E72B@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Michael Hammer , Ben Campbell , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com> <3C8FDC2F.939FBDE2@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 19:15:29 -0500 Content-Transfer-Encoding: 7bit Talking about charging: cost-per-byte has very little relationship to real costs. After all, the incremental cost of sending a byte in a network that is not fully loaded is very close to zero, wireless or otherwise, since almost all the costs are fixed costs. From a provider perspective, you want to charge according to willingness to pay, not cost. There is a reason airlines don't charge per hour flight time or per mile flown. Paul Kyzivat wrote: > > While it is nice to get something for nothing, in the long term somebody has to pay for the infrastructure that provides the bandwidth. Personally, I would not mind paying > for usage based on a fair metric. Charging per byte makes sense, while charging for elapsed time does not. Charging for guaranteed bandwidth over some time period might > make sense, but more likely it would make sense to charge more per byte for higher priority bytes. > > What would be really unfair would be to use the same channel, with the same bandwidth guarantees and charge one price for IM bytes and a different price for voice bytes. > > If you are charging by the byte, people have an incentive to balance better quality against the cost of the extra bytes needed to deliver that quality. > > Charged by the byte, IM won't be free, but may seem to be because it uses vastly fewer bytes than even a short voice message, and can get by with with lower priority > service as well. > > As long as signalling bytes used for call setup travel the same network as the voice bytes, and are billed at the same rate, it is unlikely that callers would notice much > effect on their bills because the quantities are so much smaller than for voice content. The most noticable factor might be due to roundoff - an unsuccessful call might be > charged at $0.01 rather than being free. > > The excess capacity required to provide good service can hopefully be recovered in the surcharge for priority service. > > Paul > > Michael Hammer wrote: > > > > Ben, > > > > When you consider RTP over IP, which fits your "IP application" definition, > > whether you charge per packet or realize that statistically X packets and Y > > minutes is "six of one, half a dozen of the other" then there are some > > models where per minute works out to be the same value. > > > > How do you reconcile volume charging with the two things that I noticed > > about my two services: ISP: Bills me a flat monthly fee for data > > service. Mobile phone: Bills me flat monthly fee for phone service, with > > per minute charges above an agreed on number of "free" minutes. It didn't > > used to be like that. Seems you are suggesting a trend-reversal or at > > least an exception to the rule. > > > > The earlier models of charging per data connection minute or per minute of > > call did not encourage usage and therefore generate enough revenue. Per > > byte charges can generate revenue, but only if it doesn't discourage use. > > > > Will the per-byte prices be low enough to encourage use, yet still cover > > the cost of over-provisioning the network to keep setup delay low? Will > > connection-less IM users pay a premium to make sure that > > connection-oriented RTP-flow users don't experience setup delays? Tell me, > > who pays for excess capacity? This could be a competitive discriminator. > > > > Mike > > > > At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote: > > >You example only works when you apply a billing model (per minute billing) > > >to a medium (IP applications) where it doesn't make sense. Indeed, I think > > >the per-minute model is not so much expected by users--it is just the > > >carriers don't know how to bill any other way. > > > > > >If you applied a more IP Centric billing model (charge per byte), then you > > >can easily charge for signal and user data the same way. My GPRS service > > >provider charges for GPRS data in exactly this manner--if I run a SIMPLE > > >service across it, they just see bytes. A signal byte and a user byte are > > >indistinguishable. > > > > > >My personal nightmare is hearing that carriers want to charge X per byte, > > >except for bytes that were in SIP messages. > > > > > > > > >-----Original Message----- > > >From: simple-admin@mailman.dynamicsoft.com > > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer > > >Sent: Wednesday, March 13, 2002 9:41 AM > > >To: Dean Willis > > >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com > > >Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to > > >do wit message threading) > > > > > > > > >Dean, > > > > > >There are some things users care about and will pay for, and other things > > >they won't. For connection oriented services, they consider the "air time" > > >when they have full cut-through to when they get disconnected to be the > > >value. In connectionless services, they care about data packets getting > > >through, not overhead signaling packets. > > > > > >You seem to be suggesting that the customer pay for the time they spend > > >waiting for the signaling to complete the call. Or, you expect them to pay > > >for signaling as well as data-bearing messages. This is analogous to making > > >customers pay for packaging, when all they want is the handful of tablets in > > >the little bottle inside the big box. > > > > > >Near where I live there is an ice-skating rink that charges by the hour. > > >Most people won't put up including in that hour the time taken to fill out > > >forms and select skates. Nor would they pay for time where they are > > >standing in line for that process. Not standing in line, getting to the > > >rink sooner, and skating a full hour have value. > > > > > >This is not just the service provider perspective, but the customer > > >perspective. > > > > > >It's OK to get philosophical, just keep it real. :) > > > > > >Mike > > > > > > > > >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote: > > > > > > > > > > Warning: Philosophical Rant Follows > > > > > > > > The key issue is buried deep in the underlying business > > > > model. In the Internet world, you pay the same for the bits > > > > used to signal a multimedia session as for the bits used by > > > > the multimedia session itself. In the PSTN, the carriers pay > > > > for the signaling used to set up the multimedia session. In > > > > other words, there is NO signaling, as signaling is used in > > > > the PSTN sense, on the Internet -- just application traffic. > > > > There might be messaging applications, routing applications, > > > > management applications, or multimedia applications, but > > > > they're just all applications as far as the underlying > > > > network in concerned. In the PSTN, signaling actually > > > > traverses a separate, specialized network, driven by its own > > > > economic laws. > > > > > > > > > >Reference remaining rant elsewhere. > > > > > >Here's an example. > > > > > >----------- > > > From last year's Next Steps in Signaling BOF: > > > > > >6.5 James Kempf > > > Radio access networks - air is expensive. Optimize by using less > > > bandwidth and more (for example) CPU cycles. Whatever the signaling > > > protocol is, it must be very efficient for mobility. Providers pay > > > big $$ for the airwaves, they don't want to use it for signaling, > > > but for user data. Best: do the signaling through the backbone, and > > > not over the air if possible. The signaling must be efficient for > > > mobility to minimize signaling while moving from area to area. > > > Mobility signalling should be directly coupled to the traffic. > > >------------- > > > > > >See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt > > > > > >Clearly from the provider perspective, user data and signaling are two > > >different things. Therein lies the debate. For if a user were to do > > >something that "looks like" signaling, they would intrude on the > > >territory of the operator. > > > > > >The problem here: is Messaging the same as signaling? Is Presence the > > >same as signaling? Is anything we do with SIP really "signaling" or is > > >it user data? > > > > > >-- > > >Dean > > > > > >_______________________________________________ > > >simple mailing list > > >simple@mailman.dynamicsoft.com > > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > > >_______________________________________________ simple mailing list > > >simple@mailman.dynamicsoft.com > > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 14 00:46:45 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02638 for ; Thu, 14 Mar 2002 00:46:44 -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 g2E5hAMb025786; Thu, 14 Mar 2002 00:43:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA13714; Thu, 14 Mar 2002 00:46:07 -0500 (EST) Received: from obsoft.com (sdsl-64-139-4-113.dsl.sca.megapath.net [64.139.4.113]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA13703 for ; Thu, 14 Mar 2002 00:45:59 -0500 (EST) Received: from obsoft.com (localhost.localdomain [127.0.0.1]) by obsoft.com (8.11.6/8.11.6) with ESMTP id g2E5o3t22067; Wed, 13 Mar 2002 21:50:04 -0800 Message-ID: <3C903A0B.A7701E0A@obsoft.com> From: Bobby Sardana Organization: ObjectSoftware, Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Hammer CC: Paul Kyzivat , Ben Campbell , Dean Willis , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomething to do wit message threading) References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com> <4.3.2.7.2.20020313190133.03dc97b8@cia.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 21:50:03 -0800 Content-Transfer-Encoding: 7bit So does this imply that every SIP message that transpires the network will need introspection to check if it has an embedded mime type? I am sure this will be an issue with regards to signalling performance. regards, Bobby Sardana. sardana@obsoft.com Michael Hammer wrote: > Paul, > > As long as signaling gets priority over IM and doing session setup doesn't > turn into a world wide wait, I can go along with running the packets over > the same infrastructure. > > Mike > > At 06:09 PM 3/13/2002 -0500, Paul Kyzivat wrote: > >While it is nice to get something for nothing, in the long term somebody > >has to pay for the infrastructure that provides the bandwidth. Personally, > >I would not mind paying > >for usage based on a fair metric. Charging per byte makes sense, while > >charging for elapsed time does not. Charging for guaranteed bandwidth over > >some time period might > >make sense, but more likely it would make sense to charge more per byte > >for higher priority bytes. > > > >What would be really unfair would be to use the same channel, with the > >same bandwidth guarantees and charge one price for IM bytes and a > >different price for voice bytes. > > > >If you are charging by the byte, people have an incentive to balance > >better quality against the cost of the extra bytes needed to deliver that > >quality. > > > >Charged by the byte, IM won't be free, but may seem to be because it uses > >vastly fewer bytes than even a short voice message, and can get by with > >with lower priority > >service as well. > > > >As long as signalling bytes used for call setup travel the same network as > >the voice bytes, and are billed at the same rate, it is unlikely that > >callers would notice much > >effect on their bills because the quantities are so much smaller than for > >voice content. The most noticable factor might be due to roundoff - an > >unsuccessful call might be > >charged at $0.01 rather than being free. > > > >The excess capacity required to provide good service can hopefully be > >recovered in the surcharge for priority service. > > > > Paul > > > >Michael Hammer wrote: > > > > > > Ben, > > > > > > When you consider RTP over IP, which fits your "IP application" definition, > > > whether you charge per packet or realize that statistically X packets and Y > > > minutes is "six of one, half a dozen of the other" then there are some > > > models where per minute works out to be the same value. > > > > > > How do you reconcile volume charging with the two things that I noticed > > > about my two services: ISP: Bills me a flat monthly fee for data > > > service. Mobile phone: Bills me flat monthly fee for phone service, with > > > per minute charges above an agreed on number of "free" minutes. It didn't > > > used to be like that. Seems you are suggesting a trend-reversal or at > > > least an exception to the rule. > > > > > > The earlier models of charging per data connection minute or per minute of > > > call did not encourage usage and therefore generate enough revenue. Per > > > byte charges can generate revenue, but only if it doesn't discourage use. > > > > > > Will the per-byte prices be low enough to encourage use, yet still cover > > > the cost of over-provisioning the network to keep setup delay low? Will > > > connection-less IM users pay a premium to make sure that > > > connection-oriented RTP-flow users don't experience setup delays? Tell me, > > > who pays for excess capacity? This could be a competitive discriminator. > > > > > > Mike > > > > > > At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote: > > > >You example only works when you apply a billing model (per minute billing) > > > >to a medium (IP applications) where it doesn't make sense. Indeed, I think > > > >the per-minute model is not so much expected by users--it is just the > > > >carriers don't know how to bill any other way. > > > > > > > >If you applied a more IP Centric billing model (charge per byte), then you > > > >can easily charge for signal and user data the same way. My GPRS service > > > >provider charges for GPRS data in exactly this manner--if I run a SIMPLE > > > >service across it, they just see bytes. A signal byte and a user byte are > > > >indistinguishable. > > > > > > > >My personal nightmare is hearing that carriers want to charge X per byte, > > > >except for bytes that were in SIP messages. > > > > > > > > > > > >-----Original Message----- > > > >From: simple-admin@mailman.dynamicsoft.com > > > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer > > > >Sent: Wednesday, March 13, 2002 9:41 AM > > > >To: Dean Willis > > > >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com > > > >Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was > > something to > > > >do wit message threading) > > > > > > > > > > > >Dean, > > > > > > > >There are some things users care about and will pay for, and other things > > > >they won't. For connection oriented services, they consider the "air > > time" > > > >when they have full cut-through to when they get disconnected to be the > > > >value. In connectionless services, they care about data packets getting > > > >through, not overhead signaling packets. > > > > > > > >You seem to be suggesting that the customer pay for the time they spend > > > >waiting for the signaling to complete the call. Or, you expect them > > to pay > > > >for signaling as well as data-bearing messages. This is analogous to > > making > > > >customers pay for packaging, when all they want is the handful of > > tablets in > > > >the little bottle inside the big box. > > > > > > > >Near where I live there is an ice-skating rink that charges by the hour. > > > >Most people won't put up including in that hour the time taken to fill out > > > >forms and select skates. Nor would they pay for time where they are > > > >standing in line for that process. Not standing in line, getting to the > > > >rink sooner, and skating a full hour have value. > > > > > > > >This is not just the service provider perspective, but the customer > > > >perspective. > > > > > > > >It's OK to get philosophical, just keep it real. :) > > > > > > > >Mike > > > > > > > > > > > >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote: > > > > > > > > > > > > > Warning: Philosophical Rant Follows > > > > > > > > > > The key issue is buried deep in the underlying business > > > > > model. In the Internet world, you pay the same for the bits > > > > > used to signal a multimedia session as for the bits used by > > > > > the multimedia session itself. In the PSTN, the carriers pay > > > > > for the signaling used to set up the multimedia session. In > > > > > other words, there is NO signaling, as signaling is used in > > > > > the PSTN sense, on the Internet -- just application traffic. > > > > > There might be messaging applications, routing applications, > > > > > management applications, or multimedia applications, but > > > > > they're just all applications as far as the underlying > > > > > network in concerned. In the PSTN, signaling actually > > > > > traverses a separate, specialized network, driven by its own > > > > > economic laws. > > > > > > > > > > > > >Reference remaining rant elsewhere. > > > > > > > >Here's an example. > > > > > > > >----------- > > > > From last year's Next Steps in Signaling BOF: > > > > > > > >6.5 James Kempf > > > > Radio access networks - air is expensive. Optimize by using less > > > > bandwidth and more (for example) CPU cycles. Whatever the signaling > > > > protocol is, it must be very efficient for mobility. Providers pay > > > > big $$ for the airwaves, they don't want to use it for signaling, > > > > but for user data. Best: do the signaling through the backbone, and > > > > not over the air if possible. The signaling must be efficient for > > > > mobility to minimize signaling while moving from area to area. > > > > Mobility signalling should be directly coupled to the traffic. > > > >------------- > > > > > > > >See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt > > > > > > > >Clearly from the provider perspective, user data and signaling are two > > > >different things. Therein lies the debate. For if a user were to do > > > >something that "looks like" signaling, they would intrude on the > > > >territory of the operator. > > > > > > > >The problem here: is Messaging the same as signaling? Is Presence the > > > >same as signaling? Is anything we do with SIP really "signaling" or is > > > >it user data? > > > > > > > >-- > > > >Dean > > > > > > > >_______________________________________________ > > > >simple mailing list > > > >simple@mailman.dynamicsoft.com > > > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > >_______________________________________________ simple mailing list > > > >simple@mailman.dynamicsoft.com > > > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 14 10:05:46 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18690 for ; Thu, 14 Mar 2002 10:05:41 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2EF28Mb027911; Thu, 14 Mar 2002 10:02:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15418; Thu, 14 Mar 2002 10:05:05 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15405 for ; Thu, 14 Mar 2002 10:04:11 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2EF3ek27197; Thu, 14 Mar 2002 10:03:40 -0500 (EST) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAR81315; Thu, 14 Mar 2002 09:58:13 -0500 (EST) Message-Id: <4.3.2.7.2.20020314100137.047802a0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Henning Schulzrinne From: Michael Hammer Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) Cc: Paul Kyzivat , Ben Campbell , simple@mailman.dynamicsoft.com In-Reply-To: <3C8FEBA1.8054E72B@cs.columbia.edu> References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com> <3C8FDC2F.939FBDE2@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 10:03:18 -0500 Henning, Yes, but someone has to pay the debt schedule. Over what period are you amortizing the fixed cost of the network? 15 years like telephone switches? The balance sheet still has to make sense, even if the revenue and costs are not directly coupled. Mike At 07:15 PM 3/13/2002 -0500, Henning Schulzrinne wrote: >Talking about charging: cost-per-byte has very little relationship to >real costs. After all, the incremental cost of sending a byte in a >network that is not fully loaded is very close to zero, wireless or >otherwise, since almost all the costs are fixed costs. From a provider >perspective, you want to charge according to willingness to pay, not >cost. There is a reason airlines don't charge per hour flight time or >per mile flown. > > >Paul Kyzivat wrote: > > > > While it is nice to get something for nothing, in the long term > somebody has to pay for the infrastructure that provides the bandwidth. > Personally, I would not mind paying > > for usage based on a fair metric. Charging per byte makes sense, while > charging for elapsed time does not. Charging for guaranteed bandwidth > over some time period might > > make sense, but more likely it would make sense to charge more per byte > for higher priority bytes. > > > > What would be really unfair would be to use the same channel, with the > same bandwidth guarantees and charge one price for IM bytes and a > different price for voice bytes. > > > > If you are charging by the byte, people have an incentive to balance > better quality against the cost of the extra bytes needed to deliver that > quality. > > > > Charged by the byte, IM won't be free, but may seem to be because it > uses vastly fewer bytes than even a short voice message, and can get by > with with lower priority > > service as well. > > > > As long as signalling bytes used for call setup travel the same network > as the voice bytes, and are billed at the same rate, it is unlikely that > callers would notice much > > effect on their bills because the quantities are so much smaller than > for voice content. The most noticable factor might be due to roundoff - > an unsuccessful call might be > > charged at $0.01 rather than being free. > > > > The excess capacity required to provide good service can hopefully be > recovered in the surcharge for priority service. > > > > Paul > > > > Michael Hammer wrote: > > > > > > Ben, > > > > > > When you consider RTP over IP, which fits your "IP application" > definition, > > > whether you charge per packet or realize that statistically X packets > and Y > > > minutes is "six of one, half a dozen of the other" then there are some > > > models where per minute works out to be the same value. > > > > > > How do you reconcile volume charging with the two things that I noticed > > > about my two services: ISP: Bills me a flat monthly fee for data > > > service. Mobile phone: Bills me flat monthly fee for phone service, > with > > > per minute charges above an agreed on number of "free" minutes. It > didn't > > > used to be like that. Seems you are suggesting a trend-reversal or at > > > least an exception to the rule. > > > > > > The earlier models of charging per data connection minute or per > minute of > > > call did not encourage usage and therefore generate enough revenue. Per > > > byte charges can generate revenue, but only if it doesn't discourage use. > > > > > > Will the per-byte prices be low enough to encourage use, yet still cover > > > the cost of over-provisioning the network to keep setup delay low? Will > > > connection-less IM users pay a premium to make sure that > > > connection-oriented RTP-flow users don't experience setup > delays? Tell me, > > > who pays for excess capacity? This could be a competitive discriminator. > > > > > > Mike > > > > > > At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote: > > > >You example only works when you apply a billing model (per minute > billing) > > > >to a medium (IP applications) where it doesn't make sense. Indeed, I > think > > > >the per-minute model is not so much expected by users--it is just the > > > >carriers don't know how to bill any other way. > > > > > > > >If you applied a more IP Centric billing model (charge per byte), > then you > > > >can easily charge for signal and user data the same way. My GPRS service > > > >provider charges for GPRS data in exactly this manner--if I run a SIMPLE > > > >service across it, they just see bytes. A signal byte and a user > byte are > > > >indistinguishable. > > > > > > > >My personal nightmare is hearing that carriers want to charge X per > byte, > > > >except for bytes that were in SIP messages. > > > > > > > > > > > >-----Original Message----- > > > >From: simple-admin@mailman.dynamicsoft.com > > > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer > > > >Sent: Wednesday, March 13, 2002 9:41 AM > > > >To: Dean Willis > > > >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com > > > >Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was > something to > > > >do wit message threading) > > > > > > > > > > > >Dean, > > > > > > > >There are some things users care about and will pay for, and other > things > > > >they won't. For connection oriented services, they consider the > "air time" > > > >when they have full cut-through to when they get disconnected to be the > > > >value. In connectionless services, they care about data packets getting > > > >through, not overhead signaling packets. > > > > > > > >You seem to be suggesting that the customer pay for the time they spend > > > >waiting for the signaling to complete the call. Or, you expect them > to pay > > > >for signaling as well as data-bearing messages. This is analogous > to making > > > >customers pay for packaging, when all they want is the handful of > tablets in > > > >the little bottle inside the big box. > > > > > > > >Near where I live there is an ice-skating rink that charges by the hour. > > > >Most people won't put up including in that hour the time taken to > fill out > > > >forms and select skates. Nor would they pay for time where they are > > > >standing in line for that process. Not standing in line, getting to the > > > >rink sooner, and skating a full hour have value. > > > > > > > >This is not just the service provider perspective, but the customer > > > >perspective. > > > > > > > >It's OK to get philosophical, just keep it real. :) > > > > > > > >Mike > > > > > > > > > > > >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote: > > > > > > > > > > > > > Warning: Philosophical Rant Follows > > > > > > > > > > The key issue is buried deep in the underlying business > > > > > model. In the Internet world, you pay the same for the bits > > > > > used to signal a multimedia session as for the bits used by > > > > > the multimedia session itself. In the PSTN, the carriers pay > > > > > for the signaling used to set up the multimedia session. In > > > > > other words, there is NO signaling, as signaling is used in > > > > > the PSTN sense, on the Internet -- just application traffic. > > > > > There might be messaging applications, routing applications, > > > > > management applications, or multimedia applications, but > > > > > they're just all applications as far as the underlying > > > > > network in concerned. In the PSTN, signaling actually > > > > > traverses a separate, specialized network, driven by its own > > > > > economic laws. > > > > > > > > > > > > >Reference remaining rant elsewhere. > > > > > > > >Here's an example. > > > > > > > >----------- > > > > From last year's Next Steps in Signaling BOF: > > > > > > > >6.5 James Kempf > > > > Radio access networks - air is expensive. Optimize by using less > > > > bandwidth and more (for example) CPU cycles. Whatever the signaling > > > > protocol is, it must be very efficient for mobility. Providers pay > > > > big $$ for the airwaves, they don't want to use it for signaling, > > > > but for user data. Best: do the signaling through the backbone, and > > > > not over the air if possible. The signaling must be efficient for > > > > mobility to minimize signaling while moving from area to area. > > > > Mobility signalling should be directly coupled to the traffic. > > > >------------- > > > > > > > >See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt > > > > > > > >Clearly from the provider perspective, user data and signaling are two > > > >different things. Therein lies the debate. For if a user were to do > > > >something that "looks like" signaling, they would intrude on the > > > >territory of the operator. > > > > > > > >The problem here: is Messaging the same as signaling? Is Presence the > > > >same as signaling? Is anything we do with SIP really "signaling" or is > > > >it user data? > > > > > > > >-- > > > >Dean > > > > > > > >_______________________________________________ > > > >simple mailing list > > > >simple@mailman.dynamicsoft.com > > > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > >_______________________________________________ simple mailing list > > > >simple@mailman.dynamicsoft.com > > > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 14 10:14:33 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18910 for ; Thu, 14 Mar 2002 10:14:33 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2EFB4Mb028046; Thu, 14 Mar 2002 10:11:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15469; Thu, 14 Mar 2002 10:14:04 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15458 for ; Thu, 14 Mar 2002 10:13:21 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA06840; Thu, 14 Mar 2002 10:12:28 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-38-45.mad.east.verizon.net [138.89.38.45]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2EFCQNB007644 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 Mar 2002 10:12:27 -0500 (EST) Message-ID: <3C90BFAD.DCEEA9F6@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Hammer CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomething to do wit message threading) References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com> <3C8FDC2F.939FBDE2@cisco.com> <4.3.2.7.2.20020314100137.047802a0@cia.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 10:20:13 -0500 Content-Transfer-Encoding: 7bit Certainly - just like for airplanes. In both network and airline cases, you care about getting the most money from your customers. Basic economics tells you that you want to differentiate charging not just by volume, but by willingness to pay. If number of bytes used is a first-order approximation to willingness to pay, it may not be a bad thing. However, note all the weekend/evening plans that were (are?) popular for wireless to separate the business vs. consumer spending willingness, or the various business vs. consumer plans for DSL. An 'empty' byte on a wireless network has the same properties as an empty seat on an airplane - the owner of that byte or seat is going to do anything to sell it before it leaves base, as long as they can keep their existing customers that paid more from grabbing the better deal. (This has strayed far beyond SIMPLE; if you're interested in the analysis of this for QOS, I can point you to some papers we have written on this topic.) Michael Hammer wrote: > > Henning, > > Yes, but someone has to pay the debt schedule. Over what period are you > amortizing the fixed cost of the network? 15 years like telephone > switches? The balance sheet still has to make sense, even if the revenue > and costs are not directly coupled. > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 14 10:26:43 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19169 for ; Thu, 14 Mar 2002 10:26:42 -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 g2EFN6Mb028198; Thu, 14 Mar 2002 10:23:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15530; Thu, 14 Mar 2002 10:26:05 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15519 for ; Thu, 14 Mar 2002 10:25:58 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2EFP0325997; Thu, 14 Mar 2002 07:25:00 -0800 (PST) Received: from oranlt ([161.44.238.50]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACH90962; Thu, 14 Mar 2002 07:25:08 -0800 (PST) From: "David R. Oran" To: "'Michael Hammer'" , "'Ben Campbell'" Cc: "'Dean Willis'" , "'Dean Willis'" , "'Paul Kyzivat'" , Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) Organization: Cisco Systems Message-ID: <035701c1cb6c$4f992e70$32ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 10:24:10 -0500 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > Michael Hammer > Sent: Wednesday, March 13, 2002 5:42 PM > To: Ben Campbell > Cc: Dean Willis; 'Dean Willis'; 'Paul Kyzivat'; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Messages: Signaling, Data, or Theft > (Was something to do wit message threading) > > > Ben, > > When you consider RTP over IP, which fits your "IP > application" definition, > whether you charge per packet or realize that statistically X > packets and Y > minutes is "six of one, half a dozen of the other" then there > are some > models where per minute works out to be the same value. > Huh? What if I adaptively change my packetization perdiod based on changes in loss patterns an end-to-end delay? If you do that you have to count both bytes and packets and once you've done that minutes are irrelevant (unless you want to gouge the user for silence periods). The only time minutes might be relevant is if you want to charge for *reserved resources*. If you do that, then you have the converse situation - the only thing relevant to billing is the time the requested resources are reserved, and bytes and packets don't matter. The trap, as others have pointed out is to try to charge based on the color of the bits, as opposed to what (if anything) the network does with the bits. > How do you reconcile volume charging with the two things that > I noticed > about my two services: ISP: Bills me a flat monthly fee for data > service. Mobile phone: Bills me flat monthly fee for phone > service, with > per minute charges above an agreed on number of "free" > minutes. It didn't > used to be like that. Seems you are suggesting a > trend-reversal or at > least an exception to the rule. > > The earlier models of charging per data connection minute or > per minute of > call did not encourage usage and therefore generate enough > revenue. Per > byte charges can generate revenue, but only if it doesn't > discourage use. > > Will the per-byte prices be low enough to encourage use, yet > still cover > the cost of over-provisioning the network to keep setup delay > low? Will > connection-less IM users pay a premium to make sure that > connection-oriented RTP-flow users don't experience setup > delays? Tell me, > who pays for excess capacity? This could be a competitive > discriminator. > All of this completely confounds *accounting* with *billing*. If you don't account for anything other than the existence of a subscription, then all you can do is flat-rate bill. If you count something, you can certainly bill for it, but you don't HAVE to, and the discussion is no longer technical but marketing, sales, and macro-economics. As a side note, accounting (but not billing!) falls out of nearly any QoS capability, since you need to count things in order to police and shape traffic. Dave. > Mike > > > At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote: > >You example only works when you apply a billing model (per minute > >billing) to a medium (IP applications) where it doesn't make sense. > >Indeed, I think the per-minute model is not so much expected by > >users--it is just the carriers don't know how to bill any other way. > > > >If you applied a more IP Centric billing model (charge per > byte), then > >you can easily charge for signal and user data the same way. My GPRS > >service provider charges for GPRS data in exactly this > manner--if I run > >a SIMPLE service across it, they just see bytes. A signal byte and a > >user byte are indistinguishable. > > > >My personal nightmare is hearing that carriers want to charge X per > >byte, except for bytes that were in SIP messages. > > > > > >-----Original Message----- > >From: simple-admin@mailman.dynamicsoft.com > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael > >Hammer > >Sent: Wednesday, March 13, 2002 9:41 AM > >To: Dean Willis > >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com > >Subject: RE: [Simple] Messages: Signaling, Data, or Theft > (Was something to > >do wit message threading) > > > > > >Dean, > > > >There are some things users care about and will pay for, and other > >things they won't. For connection oriented services, they > consider the > >"air time" when they have full cut-through to when they get > >disconnected to be the value. In connectionless services, they care > >about data packets getting through, not overhead signaling packets. > > > >You seem to be suggesting that the customer pay for the time > they spend > >waiting for the signaling to complete the call. Or, you > expect them to > >pay for signaling as well as data-bearing messages. This is > analogous > >to making customers pay for packaging, when all they want is the > >handful of tablets in the little bottle inside the big box. > > > >Near where I live there is an ice-skating rink that charges by the > >hour. Most people won't put up including in that hour the > time taken to > >fill out forms and select skates. Nor would they pay for time where > >they are standing in line for that process. Not standing in line, > >getting to the rink sooner, and skating a full hour have value. > > > >This is not just the service provider perspective, but the customer > >perspective. > > > >It's OK to get philosophical, just keep it real. :) > > > >Mike > > > > > >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote: > > > > > > > Warning: Philosophical Rant Follows > > > > > > The key issue is buried deep in the underlying business model. In > > > the Internet world, you pay the same for the bits used to > signal a > > > multimedia session as for the bits used by the multimedia session > > > itself. In the PSTN, the carriers pay for the signaling > used to set > > > up the multimedia session. In other words, there is NO > signaling, as > > > signaling is used in the PSTN sense, on the Internet -- just > > > application traffic. There might be messaging > applications, routing > > > applications, management applications, or multimedia > applications, > > > but they're just all applications as far as the underlying > > > network in concerned. In the PSTN, signaling actually > > > traverses a separate, specialized network, driven by its own > > > economic laws. > > > > > > >Reference remaining rant elsewhere. > > > >Here's an example. > > > >----------- > > From last year's Next Steps in Signaling BOF: > > > >6.5 James Kempf > > Radio access networks - air is expensive. Optimize by using less > > bandwidth and more (for example) CPU cycles. Whatever > the signaling > > protocol is, it must be very efficient for mobility. > Providers pay > > big $$ for the airwaves, they don't want to use it for > signaling, > > but for user data. Best: do the signaling through the > backbone, and > > not over the air if possible. The signaling must be > efficient for > > mobility to minimize signaling while moving from area to area. > > Mobility signalling should be directly coupled to the traffic. > >------------- > > > >See > >http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt > > > >Clearly from the provider perspective, user data and > signaling are two > >different things. Therein lies the debate. For if a user were to do > >something that "looks like" signaling, they would intrude on the > >territory of the operator. > > > >The problem here: is Messaging the same as signaling? Is > Presence the > >same as signaling? Is anything we do with SIP really > "signaling" or is > >it user data? > > > >-- > >Dean > > > >_______________________________________________ > >simple mailing list > >simple@mailman.dynamicsoft.com > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > >_______________________________________________ simple mailing list > >simple@mailman.dynamicsoft.com > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinf> o/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 14 10:53:33 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20364 for ; Thu, 14 Mar 2002 10:53:33 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2EFo4Mb028792; Thu, 14 Mar 2002 10:50:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15665; Thu, 14 Mar 2002 10:53:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15653 for ; Thu, 14 Mar 2002 10:52:00 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2EFpSL04694; Thu, 14 Mar 2002 10:51:28 -0500 (EST) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAR82005; Thu, 14 Mar 2002 10:46:00 -0500 (EST) Message-Id: <4.3.2.7.2.20020314103901.00b95e28@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Henning Schulzrinne From: Michael Hammer Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomething to do wit message threading) Cc: simple@mailman.dynamicsoft.com In-Reply-To: <3C90BFAD.DCEEA9F6@cs.columbia.edu> References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com> <3C8FDC2F.939FBDE2@cisco.com> <4.3.2.7.2.20020314100137.047802a0@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 10:51:05 -0500 Henning, Dave is right once you get beyond accounting for the traffic, billing is more an arbitrary business issue. Back to what I perceive as the main technical question though: Will session setup (signaling) packets get priority (within proxy processing) over IM packets such that session setup time is not impacted? Or will users re-initiate after a second or two exacerbating the traffic load? Or as some have suggested, does SIP traffic get segregated and travel over different proxies? Does the protocol element exist to discriminate so? Mike At 10:20 AM 3/14/2002 -0500, Henning Schulzrinne wrote: >Certainly - just like for airplanes. In both network and airline cases, >you care about getting the most money from your customers. Basic >economics tells you that you want to differentiate charging not just by >volume, but by willingness to pay. If number of bytes used is a >first-order approximation to willingness to pay, it may not be a bad >thing. However, note all the weekend/evening plans that were (are?) >popular for wireless to separate the business vs. consumer spending >willingness, or the various business vs. consumer plans for DSL. An >'empty' byte on a wireless network has the same properties as an empty >seat on an airplane - the owner of that byte or seat is going to do >anything to sell it before it leaves base, as long as they can keep >their existing customers that paid more from grabbing the better deal. > >(This has strayed far beyond SIMPLE; if you're interested in the >analysis of this for QOS, I can point you to some papers we have written >on this topic.) > >Michael Hammer wrote: > > > > Henning, > > > > Yes, but someone has to pay the debt schedule. Over what period are you > > amortizing the fixed cost of the network? 15 years like telephone > > switches? The balance sheet still has to make sense, even if the revenue > > and costs are not directly coupled. > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 14 10:59:45 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20541 for ; Thu, 14 Mar 2002 10:59:44 -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 g2EFu5Mb028927; Thu, 14 Mar 2002 10:56:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15707; Thu, 14 Mar 2002 10:59:05 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15696 for ; Thu, 14 Mar 2002 10:58:56 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA12057; Thu, 14 Mar 2002 10:57:30 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2EFvUNB010060 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 Mar 2002 10:57:30 -0500 (EST) Message-ID: <3C90C856.CF763DA7@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Hammer CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do wit message threading) References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com> <3C8FDC2F.939FBDE2@cisco.com> <4.3.2.7.2.20020314100137.047802a0@cia.cisco.com> <4.3.2.7.2.20020314103901.00b95e28@cia.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 10:57:10 -0500 Content-Transfer-Encoding: 7bit There are a number of techniques, e.g., I vaguely remember work published recently related to web servers from folks at IBM, that allow prioritization for different classes of requests. Thus, I just don't see this as a protocol issue. Michael Hammer wrote: > > Henning, > > Dave is right once you get beyond accounting for the traffic, billing is > more an arbitrary business issue. > > Back to what I perceive as the main technical question though: Will > session setup (signaling) packets get priority (within proxy processing) > over IM packets such that session setup time is not impacted? Or will > users re-initiate after a second or two exacerbating the traffic load? Or > as some have suggested, does SIP traffic get segregated and travel over > different proxies? Does the protocol element exist to discriminate so? > > Mike _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 14 14:46:10 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27998 for ; Thu, 14 Mar 2002 14:46:10 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2EJg9Mb001769; Thu, 14 Mar 2002 14:42:10 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16495; Thu, 14 Mar 2002 14:45:05 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16482 for ; Thu, 14 Mar 2002 14:44:20 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2EJheZ14323 for ; Thu, 14 Mar 2002 21:43:40 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Mar 2002 21:43:28 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 14 Mar 2002 21:43:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do wit message threading) Message-ID: Thread-Topic: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do wit message threading) Thread-Index: AcHLcSnzUqPC4J2NTq+lvbtgh9OWuAAHcWgA To: , Cc: X-OriginalArrivalTime: 14 Mar 2002 19:43:28.0587 (UTC) FILETIME=[838D01B0:01C1CB90] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA16482 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 21:43:28 +0200 Content-Transfer-Encoding: 8bit Hi, Scheduling within proxies is one thing. Also important is how the IP packets carrying SIP are handled over low-capacity links. For example in wireless access, session setup maybe treated differently from regular traffic in order to meet the call setup times. On the other hand large MESSAGEs etc. could be treated as best-effort. DiffServ codepoints might be used to do the thing, but this requires the last hop proxy to set them based on some logic. Probably this is nothing to do with SIP protocol, though. Also a question: what if there is a single TCP connection between UA and proxy. Proxy starts to transmit a large MESSAGE toward UA. In the meanwhile an INVITE for a voice call arrives at the proxy to be delivered to the same UA. Is it possible to interleave it between the TCP segments carrying MESSAGE, or does MESSAGE block the transport? Markus > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 14 March, 2002 17:57 > To: Michael Hammer > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Messages: Signaling, Data, or Theft > (Wassomethingto do wit message threading) > > > There are a number of techniques, e.g., I vaguely remember work > published recently related to web servers from folks at IBM, > that allow > prioritization for different classes of requests. Thus, I > just don't see > this as a protocol issue. > > Michael Hammer wrote: > > > > Henning, > > > > Dave is right once you get beyond accounting for the > traffic, billing is > > more an arbitrary business issue. > > > > Back to what I perceive as the main technical question though: Will > > session setup (signaling) packets get priority (within > proxy processing) > > over IM packets such that session setup time is not > impacted? Or will > > users re-initiate after a second or two exacerbating the > traffic load? Or > > as some have suggested, does SIP traffic get segregated and > travel over > > different proxies? Does the protocol element exist to > discriminate so? > > > > Mike > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 14 15:20:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29283 for ; Thu, 14 Mar 2002 15:20:06 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2EKG4Mb002226; Thu, 14 Mar 2002 15:16:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16622; Thu, 14 Mar 2002 15:19:04 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16611 for ; Thu, 14 Mar 2002 15:18:48 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id PAA19602; Thu, 14 Mar 2002 15:17:28 -0500 (EST) Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) To: "David R. Oran" Cc: "'Michael Hammer'" , "'Ben Campbell'" , "'Dean Willis'" , "'Paul Kyzivat'" , Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 03/14/2002 03:17:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 15:17:27 -0500 For a survey and references consult http://www.comsoc.org/livepubs/surveys/public/2q00issue/pdf/DaSilva.pdf "David R. Oran" @mailman.dynamicsoft.com on 03/14/2002 10:24:10 AM Sent by: simple-admin@mailman.dynamicsoft.com To: "'Michael Hammer'" , "'Ben Campbell'" cc: "'Dean Willis'" , "'Dean Willis'" , "'Paul Kyzivat'" , Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading) > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > Michael Hammer > Sent: Wednesday, March 13, 2002 5:42 PM > To: Ben Campbell > Cc: Dean Willis; 'Dean Willis'; 'Paul Kyzivat'; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Messages: Signaling, Data, or Theft > (Was something to do wit message threading) > > > Ben, > > When you consider RTP over IP, which fits your "IP > application" definition, > whether you charge per packet or realize that statistically X > packets and Y > minutes is "six of one, half a dozen of the other" then there > are some > models where per minute works out to be the same value. > Huh? What if I adaptively change my packetization perdiod based on changes in loss patterns an end-to-end delay? If you do that you have to count both bytes and packets and once you've done that minutes are irrelevant (unless you want to gouge the user for silence periods). The only time minutes might be relevant is if you want to charge for *reserved resources*. If you do that, then you have the converse situation - the only thing relevant to billing is the time the requested resources are reserved, and bytes and packets don't matter. The trap, as others have pointed out is to try to charge based on the color of the bits, as opposed to what (if anything) the network does with the bits. > How do you reconcile volume charging with the two things that > I noticed > about my two services: ISP: Bills me a flat monthly fee for data > service. Mobile phone: Bills me flat monthly fee for phone > service, with > per minute charges above an agreed on number of "free" > minutes. It didn't > used to be like that. Seems you are suggesting a > trend-reversal or at > least an exception to the rule. > > The earlier models of charging per data connection minute or > per minute of > call did not encourage usage and therefore generate enough > revenue. Per > byte charges can generate revenue, but only if it doesn't > discourage use. > > Will the per-byte prices be low enough to encourage use, yet > still cover > the cost of over-provisioning the network to keep setup delay > low? Will > connection-less IM users pay a premium to make sure that > connection-oriented RTP-flow users don't experience setup > delays? Tell me, > who pays for excess capacity? This could be a competitive > discriminator. > All of this completely confounds *accounting* with *billing*. If you don't account for anything other than the existence of a subscription, then all you can do is flat-rate bill. If you count something, you can certainly bill for it, but you don't HAVE to, and the discussion is no longer technical but marketing, sales, and macro-economics. As a side note, accounting (but not billing!) falls out of nearly any QoS capability, since you need to count things in order to police and shape traffic. Dave. > Mike > > > At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote: > >You example only works when you apply a billing model (per minute > >billing) to a medium (IP applications) where it doesn't make sense. > >Indeed, I think the per-minute model is not so much expected by > >users--it is just the carriers don't know how to bill any other way. > > > >If you applied a more IP Centric billing model (charge per > byte), then > >you can easily charge for signal and user data the same way. My GPRS > >service provider charges for GPRS data in exactly this > manner--if I run > >a SIMPLE service across it, they just see bytes. A signal byte and a > >user byte are indistinguishable. > > > >My personal nightmare is hearing that carriers want to charge X per > >byte, except for bytes that were in SIP messages. > > > > > >-----Original Message----- > >From: simple-admin@mailman.dynamicsoft.com > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael > >Hammer > >Sent: Wednesday, March 13, 2002 9:41 AM > >To: Dean Willis > >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com > >Subject: RE: [Simple] Messages: Signaling, Data, or Theft > (Was something to > >do wit message threading) > > > > > >Dean, > > > >There are some things users care about and will pay for, and other > >things they won't. For connection oriented services, they > consider the > >"air time" when they have full cut-through to when they get > >disconnected to be the value. In connectionless services, they care > >about data packets getting through, not overhead signaling packets. > > > >You seem to be suggesting that the customer pay for the time > they spend > >waiting for the signaling to complete the call. Or, you > expect them to > >pay for signaling as well as data-bearing messages. This is > analogous > >to making customers pay for packaging, when all they want is the > >handful of tablets in the little bottle inside the big box. > > > >Near where I live there is an ice-skating rink that charges by the > >hour. Most people won't put up including in that hour the > time taken to > >fill out forms and select skates. Nor would they pay for time where > >they are standing in line for that process. Not standing in line, > >getting to the rink sooner, and skating a full hour have value. > > > >This is not just the service provider perspective, but the customer > >perspective. > > > >It's OK to get philosophical, just keep it real. :) > > > >Mike > > > > > >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote: > > > > > > > Warning: Philosophical Rant Follows > > > > > > The key issue is buried deep in the underlying business model. In > > > the Internet world, you pay the same for the bits used to > signal a > > > multimedia session as for the bits used by the multimedia session > > > itself. In the PSTN, the carriers pay for the signaling > used to set > > > up the multimedia session. In other words, there is NO > signaling, as > > > signaling is used in the PSTN sense, on the Internet -- just > > > application traffic. There might be messaging > applications, routing > > > applications, management applications, or multimedia > applications, > > > but they're just all applications as far as the underlying > > > network in concerned. In the PSTN, signaling actually > > > traverses a separate, specialized network, driven by its own > > > economic laws. > > > > > > >Reference remaining rant elsewhere. > > > >Here's an example. > > > >----------- > > From last year's Next Steps in Signaling BOF: > > > >6.5 James Kempf > > Radio access networks - air is expensive. Optimize by using less > > bandwidth and more (for example) CPU cycles. Whatever > the signaling > > protocol is, it must be very efficient for mobility. > Providers pay > > big $$ for the airwaves, they don't want to use it for > signaling, > > but for user data. Best: do the signaling through the > backbone, and > > not over the air if possible. The signaling must be > efficient for > > mobility to minimize signaling while moving from area to area. > > Mobility signalling should be directly coupled to the traffic. > >------------- > > > >See > >http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt > > > >Clearly from the provider perspective, user data and > signaling are two > >different things. Therein lies the debate. For if a user were to do > >something that "looks like" signaling, they would intrude on the > >territory of the operator. > > > >The problem here: is Messaging the same as signaling? Is > Presence the > >same as signaling? Is anything we do with SIP really > "signaling" or is > >it user data? > > > >-- > >Dean > > > >_______________________________________________ > >simple mailing list > >simple@mailman.dynamicsoft.com > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > >_______________________________________________ simple mailing list > >simple@mailman.dynamicsoft.com > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinf> o/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 14 16:46:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02067 for ; Thu, 14 Mar 2002 16:46:56 -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 g2ELh8Mb003195; Thu, 14 Mar 2002 16:43:08 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16905; Thu, 14 Mar 2002 16:46:05 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16894 for ; Thu, 14 Mar 2002 16:45:26 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2ELiXU28121; Thu, 14 Mar 2002 15:44:33 -0600 From: "Dean Willis" To: Cc: Subject: Message Interveleaving: was RE: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do wit message threading) Message-ID: <00e701c1cba1$6610ba30$bb036e3f@TXDWILLIS2> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-reply-to: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 15:44:19 -0600 Content-Transfer-Encoding: 7bit > Also a question: what if there is a single TCP connection > between UA and proxy. Proxy starts to transmit a large > MESSAGE toward UA. In the meanwhile an INVITE for a voice > call arrives at the proxy to be delivered to the same UA. Is > it possible to interleave it between the TCP segments > carrying MESSAGE, or does MESSAGE block the transport? That is transport dependent -- does your transport protocol provide for subpacketization and interleaving? There was a big push to provide this with PPP back when people thought they were going to be doing voice over IP over dialup, and we found that every large TCP packet blew the RTP jitter buffer due to serialization delay. Somebody who's brain works better than mine can probably produce a reference for the PPP variation, which I think was never widely deployed. One could hope that the wireless transport people provide something like that. I have the sneaking suspicion they didn't, at least yet. -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 14 17:10:56 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02626 for ; Thu, 14 Mar 2002 17:10:56 -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 g2EM75Mb003398; Thu, 14 Mar 2002 17:07:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17008; Thu, 14 Mar 2002 17:10:05 -0500 (EST) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16995 for ; Thu, 14 Mar 2002 17:09:50 -0500 (EST) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2EM8K232452; Thu, 14 Mar 2002 16:08:22 -0600 (CST) From: "Ben Campbell" To: , , Cc: Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do wit message threading) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 16:06:59 -0600 Content-Transfer-Encoding: 7bit > Also a question: what if there is a single TCP connection between > UA and proxy. Proxy starts to transmit a large MESSAGE toward UA. > In the meanwhile an INVITE for a voice call arrives at the proxy > to be delivered to the same UA. Is it possible to interleave it > between the TCP segments carrying MESSAGE, or does MESSAGE block > the transport? > That could be a problem in some scenarios. I think the real answer, though, is to limit the MESSAGE requests to some reasonable size. We have had talk about standardizing methods to send large data by reference--I think any real application that sends messages containing much bigger than an average text IM will eventually need to go that route. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 14 18:22:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04225 for ; Thu, 14 Mar 2002 18:22:56 -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 g2ENJ6Mb004043; Thu, 14 Mar 2002 18:19:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17246; Thu, 14 Mar 2002 18:22:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17235 for ; Thu, 14 Mar 2002 18:21:58 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2ENLPP07720; Thu, 14 Mar 2002 18:21:26 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG80013; Thu, 14 Mar 2002 18:24:18 -0500 (EST) Message-ID: <3C91305F.51007A32@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: Markus.Isomaki@nokia.com, hgs@cs.columbia.edu, mhammer@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do wit message threading) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 18:21:03 -0500 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > > Also a question: what if there is a single TCP connection between > > UA and proxy. Proxy starts to transmit a large MESSAGE toward UA. > > In the meanwhile an INVITE for a voice call arrives at the proxy > > to be delivered to the same UA. Is it possible to interleave it > > between the TCP segments carrying MESSAGE, or does MESSAGE block > > the transport? > > > > That could be a problem in some scenarios. I think the real answer, though, > is to limit the MESSAGE requests to some reasonable size. We have had talk > about standardizing methods to send large data by reference--I think any > real application that sends messages containing much bigger than an average > text IM will eventually need to go that route. This is probably reasonable for page mode IM, but less reasonable for session mode. Once you have gone to the trouble to establish a session, it should be ok to send bigger messages over it. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 14 18:50:51 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05015 for ; Thu, 14 Mar 2002 18:50:51 -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 g2ENl5Mb004254; Thu, 14 Mar 2002 18:47:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17358; Thu, 14 Mar 2002 18:50:05 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17345 for ; Thu, 14 Mar 2002 18:49:11 -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 g2ENmJh06809 for ; Thu, 14 Mar 2002 17:48:20 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 17:48:21 -0600 Message-ID: From: "Sriram Parameswar" To: simple@mailman.dynamicsoft.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CBB2.B896C3B0" Subject: [Simple] IMTP vs. IMXP Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 17:48:20 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CBB2.B896C3B0 Content-Type: text/plain; charset="iso-8859-1" Hi: Taking a look at the IMTP versus IMXP issue - I have evaluated them as follows: IMTP ----- 1. Is a subset of SIP - however what is the actual use of the 'To' header in IMTP? The From header has its uses - example chat rooms. 2. In the NAT/FW traversal discussion - when are the 'REGISTER' bindings with the IMTP relay freed? Typically we would expect the receipt of a BYE to free the bindings - what if we do not get that BYE? How do we handle extended/persistent sessions? 3. On the issue of re-negotiating the media (i.e. send a jpeg file in the IMTP bearer) - it should be made clear that a re-INVITE is necessary. 4. IMTP is basically forcing the routing decision up several layers (upto the Application Layer) and this "routing" would be much more efficient at lower layers. IMXP (IM Simple Exchange) ----- 1. Though BEEP is considered lightweight, it seems like overkill in that the negotiation and security seem redundant with what can be done with SIP. 2.BEEP does not currently support threading, but this could possibly be done using the message exchange identifier/content ID. However something along the lines of draft-koskelainen-imtpext-00.txt may need to be added. 3. I am not sure that the NAT/Firewall traversal issue has been solved - especially keeping the NAT bindings open for an extended session. Both the I-D's do not take up the issue of rendering Instant Messagig content - a feature that is available in existing IM systems. Are there other alternatives that we have not considered? CPIM with an XHTML payload over TCP could be a starting point. It solves rendering of Instant Messages - on UA's and the interoperability issue too. We could also consider using CC/PP to ensure that payloads are formatted correctly as per the recepients terminal characteristics. Thanks, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C1CBB2.B896C3B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IMTP vs. IMXP

Hi:

Taking a look at the IMTP versus IMXP issue - I have = evaluated them as follows:
IMTP
-----
1. Is a subset of SIP - however what is the actual = use of the 'To' header in IMTP? The From header has its uses - example = chat rooms.

2. In the NAT/FW traversal discussion - when are the = 'REGISTER' bindings with the IMTP relay freed? Typically we would = expect the receipt of a BYE to free the bindings - what if we do not = get that BYE? How do we handle extended/persistent sessions?

3. On the issue of re-negotiating the media (i.e. = send a jpeg file in the IMTP bearer) - it should be made clear that a = re-INVITE is necessary.

4. IMTP is basically forcing the routing decision up = several layers (upto the Application Layer) and this = "routing" would be much more efficient at lower = layers.

IMXP (IM Simple Exchange)
-----
1. Though BEEP is considered lightweight, it seems = like overkill in that the negotiation and security seem redundant with = what can be done with SIP.

2.BEEP does not currently support threading, but this = could possibly be done using the message exchange identifier/content = ID. However something along the lines of = draft-koskelainen-imtpext-00.txt may need to be added.

3. I am not sure that the NAT/Firewall traversal = issue has been solved - especially keeping the NAT bindings open for an = extended session.

Both the I-D's do not take up the issue of rendering = Instant Messagig content - a feature that is available in existing IM = systems.

Are there other alternatives that we have not = considered? CPIM with an XHTML payload over TCP could be a starting = point. It solves rendering of Instant Messages - on UA's and the = interoperability issue too. We could also consider using CC/PP to = ensure that payloads are formatted correctly as per the recepients = terminal characteristics.

Thanks,

Sriram
__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-684-3986
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com

------_=_NextPart_001_01C1CBB2.B896C3B0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 15 05:36:22 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25694 for ; Fri, 15 Mar 2002 05:36:22 -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 g2FAX7Mb006297; Fri, 15 Mar 2002 05:33:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19339; Fri, 15 Mar 2002 05:36:06 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19328 for ; Fri, 15 Mar 2002 05:35:40 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA10488; Fri, 15 Mar 2002 11:34:43 +0100 (MET) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA07191; Fri, 15 Mar 2002 11:34:28 +0100 (MET) Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 11:34:41 +0100 Message-ID: <5B4D0C5BA65ECA46969C1419122317E60EDEA4@mchh161e> From: Heil Franca Marcelo ICM N PG U ID A 2 To: "'Paul Kyzivat'" , Ben Campbell Cc: Markus.Isomaki@nokia.com, hgs@cs.columbia.edu, mhammer@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do wit message threading) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 15 Mar 2002 11:34:51 +0100 Comments below: > > > > > Ben Campbell wrote: > > > > > Also a question: what if there is a single TCP connection between > > > UA and proxy. Proxy starts to transmit a large MESSAGE toward UA. > > > In the meanwhile an INVITE for a voice call arrives at the proxy > > > to be delivered to the same UA. Is it possible to interleave it > > > between the TCP segments carrying MESSAGE, or does MESSAGE block > > > the transport? > > > > > > > That could be a problem in some scenarios. I think the real > answer, though, > > is to limit the MESSAGE requests to some reasonable size. > We have had talk > > about standardizing methods to send large data by > reference--I think any > > real application that sends messages containing much bigger > than an average > > text IM will eventually need to go that route. > > This is probably reasonable for page mode IM, but less > reasonable for session mode. Once you have gone to the > trouble to establish a session, it should be ok to send bigger > messages over it. > > Paul I support limiting the size of MESSAGE requests for page mode IM. Otherwise, network components (e. g. proxies) which are not really concerned with IM contents would be unnecessarily burdened. For example, intermediate proxies having to process, route and forward large MESSAGEs (with sizes in the order of megabytes) arriving frequently would quickly run out of memory resources. Session mode IMs should be expected to be transferred end-to-end using an appropriate transport protocol, so that intermediate proxies should not be in the path and therefore not directly involved in the IM transfer. Session mode seems, therefore, much more appropriate for tranferring large IMs than page mode. Marcelo _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 15 10:55:45 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02308 for ; Fri, 15 Mar 2002 10:55:39 -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 g2FFpFMb008043; Fri, 15 Mar 2002 10:51:15 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20292; Fri, 15 Mar 2002 10:54:05 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20281 for ; Fri, 15 Mar 2002 10:53:45 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2FFqpe00800; Fri, 15 Mar 2002 09:52:52 -0600 From: "Dean Willis" To: "'Heil Franca Marcelo ICM N PG U ID A 2'" Cc: Message-ID: <017301c1cc39$6e03ceb0$bb036e3f@TXDWILLIS2> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <5B4D0C5BA65ECA46969C1419122317E60EDEA4@mchh161e> Subject: [Simple] Message Sizes (was Messages: Signaling, Data, or Theft) Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 15 Mar 2002 09:52:36 -0600 Content-Transfer-Encoding: 7bit Marcelo wrote: > I support limiting the size of MESSAGE requests for page mode > IM. Otherwise, network components (e. g. proxies) which are > not really concerned with IM contents would be unnecessarily > burdened. For example, intermediate proxies having to > process, route and forward large MESSAGEs (with sizes in the > order of megabytes) arriving frequently would quickly run out > of memory resources. The genral approach that I believe has been agreed on is that MESSAGES should not exceed a size slightly smaller than a reasonable path MTU because there MAY bea a UDP link somewhere in between, and fragmenting over a UDP link increases the probability of a fragment loss (not to mention posing interesting issues for congestion management). Beyond this point, reducing them in size doesn't significantly affect the proxy performance, because the proxy load is driven by the forwarding logic and signaling state machines and not the I/O of the message body. > Session mode IMs should be expected to be transferred > end-to-end using an appropriate transport protocol, so that > intermediate proxies should not be in the path and therefore > not directly involved in the IM transfer. Session mode > seems, therefore, much more appropriate for tranferring large > IMs than page mode. Marcelo Page mode IMs don't necessarily transit the intermediate proxies. If the contact address of the destination is known, and the network topology has not been deliberately designed to prevent it, one can send the MESSAGE directly to the far end. Let's not let the fact that some people have deliberately obfuscated their networks with "required" proxies make us forget about the intended end-to-end nature of the Internet. The general idea of a proxy is as a "location service" aid -- if you don't know how to get directly to somoeone (or can't, due to topology), you can ask a proxy to help. In fact, one could use pager-mode MESSAGES over a persistent end-to-end TCP or TCP/TLS session, and get all the benefits of congestion control, retransmission, in-order delivery, and reassembly. This is most interesting because the intended nature of the "sips:" URI mechanism is that every link be TLS (which implies TCP or SCTP). So the use of sips: on MESSAGE requests most all of the UDP-related issues, esepcially when used directly with a sips: contact. Combine this with the use of redirection (302) messages instead of "proxying", and one can get e2e sessions (which transport pager-mode MESSAGES as well as other SIP) in a very nice end-to-end fashion. And there's probably something that could be done to optimize the flow by allowing intermediate proxies that absolutely MUST stay on the path to "cache" 302 responses and recurse on them to provide automatic MESSAGE path optimization. -- Dean -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 15 11:04:09 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02610 for ; Fri, 15 Mar 2002 11:04:08 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2FG03Mb008218; Fri, 15 Mar 2002 11:00:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20373; Fri, 15 Mar 2002 11:03:04 -0500 (EST) Received: from smtp01ffm.de.uu.net (smtp01ffm.de.uu.net [192.76.144.150]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20362 for ; Fri, 15 Mar 2002 11:02:40 -0500 (EST) Received: from penelope.materna.de (penelope.materna.de [193.96.115.65]) by smtp01ffm.de.uu.net (5.5.5/5.5.5) with ESMTP id RAA15639; Fri, 15 Mar 2002 17:02:23 +0100 (MET) Received: from ganymed (ganymed.materna.de [139.2.34.141]) by penelope.materna.de (Postfix) with ESMTP id 8C44B67F7; Fri, 15 Mar 2002 17:01:45 +0100 (MET) Received: from thurn.materna.de (actually localhost) by ganymed with Internet with ESMTP; Fri, 15 Mar 2002 17:01:36 +0100 Received: by thurn.materna.de with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 17:01:14 +0100 Message-ID: <73B855B4F72FD411A1CF009027B113C40199F739@taxis.materna.de> From: "Nagel, Thomas" To: "'Dean Willis'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: AW: [Simple] Message Sizes (was Messages: Signaling, Data, or The ft) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA20362 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 15 Mar 2002 17:01:14 +0100 Content-Transfer-Encoding: 8bit Hi Dean, > -----Ursprüngliche Nachricht----- > Von: Dean Willis [mailto:dean.willis@softarmor.com] > Gesendet: Freitag, 15. März 2002 16:53 > An: 'Heil Franca Marcelo ICM N PG U ID A 2' > Cc: simple@mailman.dynamicsoft.com > Betreff: [Simple] Message Sizes (was Messages: Signaling, Data, or > Theft) > > > Marcelo wrote: > > I support limiting the size of MESSAGE requests for page mode > > IM. Otherwise, network components (e. g. proxies) which are > > not really concerned with IM contents would be unnecessarily > > burdened. For example, intermediate proxies having to > > process, route and forward large MESSAGEs (with sizes in the > > order of megabytes) arriving frequently would quickly run out > > of memory resources. > > The genral approach that I believe has been agreed on is that MESSAGES > should not exceed a size slightly smaller than a reasonable path MTU > because there MAY bea a UDP link somewhere in between, and fragmenting > over a UDP link increases the probability of a fragment loss (not to > mention posing interesting issues for congestion management). Beyond > this point, reducing them in size doesn't significantly > affect the proxy > performance, because the proxy load is driven by the forwarding logic > and signaling state machines and not the I/O of the message body. > Question: Doesn't this (again) raise the (afaik. in IPv4 un-solvable) PATH MRU discovery problem? Thomas > -- > Dean > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 15 11:33:38 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03432 for ; Fri, 15 Mar 2002 11:33:38 -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 g2FGU4Mb008557; Fri, 15 Mar 2002 11:30:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20492; Fri, 15 Mar 2002 11:33:04 -0500 (EST) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20481 for ; Fri, 15 Mar 2002 11:32:27 -0500 (EST) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2FGVL216353; Fri, 15 Mar 2002 10:31:21 -0600 (CST) From: "Ben Campbell" To: "Dean Willis" , "'Heil Franca Marcelo ICM N PG U ID A 2'" Cc: Subject: RE: [Simple] Message Sizes (was Messages: Signaling, Data, or Theft) 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <017301c1cc39$6e03ceb0$bb036e3f@TXDWILLIS2> Importance: Normal Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 15 Mar 2002 10:28:56 -0600 Content-Transfer-Encoding: 7bit > Page mode IMs don't necessarily transit the intermediate proxies. If the > contact address of the destination is known, and the network topology > has not been deliberately designed to prevent it, one can send the > MESSAGE directly to the far end. Let's not let the fact that some people > have deliberately obfuscated their networks with "required" proxies make > us forget about the intended end-to-end nature of the Internet. > > The general idea of a proxy is as a "location service" aid -- if you > don't know how to get directly to somoeone (or can't, due to topology), > you can ask a proxy to help. In fact, one could use pager-mode MESSAGES > over a persistent end-to-end TCP or TCP/TLS session, and get all the > benefits of congestion control, retransmission, in-order delivery, and > reassembly. > > This is most interesting because the intended nature of the "sips:" URI > mechanism is that every link be TLS (which implies TCP or SCTP). So the > use of sips: on MESSAGE requests most all of the UDP-related issues, > esepcially when used directly with a sips: contact. > > Combine this with the use of redirection (302) messages instead of > "proxying", and one can get e2e sessions (which transport pager-mode > MESSAGES as well as other SIP) in a very nice end-to-end fashion. And > there's probably something that could be done to optimize the flow by > allowing intermediate proxies that absolutely MUST stay on the path to > "cache" 302 responses and recurse on them to provide automatic MESSAGE > path optimization. > Keep in mind though, that MESSAGE does not initiate a dialog. The affect here is that, in the absense of something like a "Moved Permantly" redirection, Each subsequent MESSAGE request to a given address of record will follow a similar path--that is, there is no real way _not_ to record route. That of course does not prevent the _initial_ route to end up e2e, with the use of redirect servers as you mention. But each subsequent message must also get redirected. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 15 12:20:42 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04975 for ; Fri, 15 Mar 2002 12:20:42 -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 g2FHH7Mb009123; Fri, 15 Mar 2002 12:17:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20694; Fri, 15 Mar 2002 12:20:05 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20680 for ; Fri, 15 Mar 2002 12:19:01 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2FHI0e01454; Fri, 15 Mar 2002 11:18:00 -0600 From: "Dean Willis" To: "'Ben Campbell'" , "'Heil Franca Marcelo ICM N PG U ID A 2'" Cc: Subject: RE: [Simple] Message Sizes (was Messages: Signaling, Data, or Theft) Message-ID: <040a01c1cc45$52a417e0$bb036e3f@TXDWILLIS2> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 15 Mar 2002 11:17:44 -0600 Content-Transfer-Encoding: 7bit Ben points out: > Keep in mind though, that MESSAGE does not initiate a dialog. > The affect here is that, in the absense of something like a > "Moved Permantly" redirection, Each subsequent MESSAGE > request to a given address of record will follow a similar > path--that is, there is no real way _not_ to record route. > > That of course does not prevent the _initial_ route to end up > e2e, with the use of redirect servers as you mention. But > each subsequent message must also get redirected. That's what I mean by "caching" redirections. Say we have: UA1--->P1--->LS | | UA2 Where the normal flow is something like: UA1->INVITE target@lS->P1 P1->INVITE target@ls->LS LS->302 target@UA2 -> P1 P1 -> INVITE target@ls -> UA2 Or UA1->MESSAGE target@lS->P1 P1->MESSAGE target@ls->LS LS->302 target@UA2 -> P1 P1 -> MESSAGE target@ls -> UA2 Now, the normal model is that for each subsequent INVITE or MESSAGE to go through the same process. But what if P1 "remembers" that it has been recently redirected for this request URI, and just keeps on using it, like: UA1->INVITE target@lS->P1 P1 -> INVITE target@ls -> UA2 Or UA1->MESSAGE target@lS->P1 P1 -> MESSAGE target@ls -> UA2 Certainly, this raises some questions: 1) How long to "remember" -- it's not permanent, but it's longer than 1 message . . . 2) What happens if we keep sending to the redirected contact "too long" and the user has already moved somewhere else? 3) the caching operation is clearly proxy stateful 4) we could implement this sort of 302 caching in a UA too A couple of possibilities spring to mind. 1) We could add something like a duration indicator to the 302 response, much like the TTL on DNS lookups. Or we could contrive to do something at the DNS level, although this really doesn't give us the message-type specific behavior potentially provided by the LS in this example. Or we could rely on a "bounce" from question 2 to let us know that the situation has changed and we need to reconsider the route. 2) If the contact that P1 is redirecting too stops responding (timeout or ICMP response) then P1 knows to flush the cache. This begs the question of what happens if the redirection policy at LS changes -- using this model, we'd continue talking to the original redirection contact until some other mechanism causes a transition, which might be acceptable. 3) Yes, all 302-recursions are at least transaction satteful at the proxy. 4) Actually, any point that does a 302-recursion could implement this sort of approach. -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 15 12:24:36 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05052 for ; Fri, 15 Mar 2002 12:24:35 -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 g2FHL3Mb009223; Fri, 15 Mar 2002 12:21:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20744; Fri, 15 Mar 2002 12:24:04 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20733 for ; Fri, 15 Mar 2002 12:23:27 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2FHMae01490; Fri, 15 Mar 2002 11:22:37 -0600 From: "Dean Willis" To: "'Nagel, Thomas'" Cc: Subject: RE: [Simple] Message Sizes (was Messages: Signaling, Data, or Theft) Message-ID: <040b01c1cc45$f756b8b0$bb036e3f@TXDWILLIS2> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <73B855B4F72FD411A1CF009027B113C40199F739@taxis.materna.de> Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 15 Mar 2002 11:22:21 -0600 Content-Transfer-Encoding: 7bit > Question: Doesn't this (again) raise the (afaik. in IPv4 un-solvable) > PATH MRU discovery problem? > > Thomas Yes. Actually, we could use a similar approach to TCP path MTU discovery (implemented from BSD 4.4 Tahoe on, I believe). Any proxy sending SIP messages UDP would set DF, and if the message is rejected by a router (indicated by returned ICMP response saying fragementation required, DF set), either kick the message back towards the source with a "message size exceeded" SIP response or switch to a more reasonable protocol. -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 15 14:02:48 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07269 for ; Fri, 15 Mar 2002 14:02:48 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2FIx4Mb010048; Fri, 15 Mar 2002 13:59:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21066; Fri, 15 Mar 2002 14:02:04 -0500 (EST) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21055 for ; Fri, 15 Mar 2002 14:01:39 -0500 (EST) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2FJ0e229939; Fri, 15 Mar 2002 13:00:40 -0600 (CST) From: "Ben Campbell" To: "Dean Willis" , "'Heil Franca Marcelo ICM N PG U ID A 2'" Cc: Subject: RE: [Simple] Message Sizes (was Messages: Signaling, Data, or Theft) 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <040a01c1cc45$52a417e0$bb036e3f@TXDWILLIS2> Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 15 Mar 2002 12:58:14 -0600 Content-Transfer-Encoding: 7bit > 1) We could add something like a duration indicator to the 302 response, > much like the TTL on DNS lookups. Or we could contrive to do something > at the DNS level, although this really doesn't give us the message-type > specific behavior potentially provided by the LS in this example. Or we > could rely on a "bounce" from question 2 to let us know that the > situation has changed and we need to reconsider the route. Actually, the current SIP spec officially supports the use of the Expires header in 302 responses for this purpose. > > 2) If the contact that P1 is redirecting too stops responding (timeout > or ICMP response) then P1 knows to flush the cache. This begs the > question of what happens if the redirection policy at LS changes -- > using this model, we'd continue talking to the original redirection > contact until some other mechanism causes a transition, which might be > acceptable. > > 3) Yes, all 302-recursions are at least transaction satteful at the > proxy. > > 4) Actually, any point that does a 302-recursion could implement this > sort of approach. > > -- > Dean > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 15 15:19:51 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09283 for ; Fri, 15 Mar 2002 15:19:51 -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 g2FKG5Mb010852; Fri, 15 Mar 2002 15:16:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21371; Fri, 15 Mar 2002 15:19:05 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21147 for ; Fri, 15 Mar 2002 14:17:21 -0500 (EST) Received: from there (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2FJFhe02317; Fri, 15 Mar 2002 13:15:43 -0600 Message-Id: <200203151915.g2FJFhe02317@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: "Ben Campbell" , , , Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do wit message threading) X-Mailer: KMail [version 1.3.2] Cc: References: In-Reply-To: Organization: dynamicsoft Inc. MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 15 Mar 2002 13:15:41 -0600 Content-Transfer-Encoding: 8bit Actually, if you do the math, you find that something like 64 bytes is the largest message size whose serialization delay doesn't break RTP at 9600 bps. That makes it a sub-IP interrleaving problem. -- Dean On Thursday 14 March 2002 04:06 pm, Ben Campbell wrote: > > Also a question: what if there is a single TCP connection between > > UA and proxy. Proxy starts to transmit a large MESSAGE toward UA. > > In the meanwhile an INVITE for a voice call arrives at the proxy > > to be delivered to the same UA. Is it possible to interleave it > > between the TCP segments carrying MESSAGE, or does MESSAGE block > > the transport? > > That could be a problem in some scenarios. I think the real answer, > though, is to limit the MESSAGE requests to some reasonable size. We > have had talk about standardizing methods to send large data by > reference--I think any real application that sends messages > containing much bigger than an average text IM will eventually need > to go that route. > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 15 17:35:48 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12584 for ; Fri, 15 Mar 2002 17:35:47 -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 g2FMWBMb011881; Fri, 15 Mar 2002 17:32:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21816; Fri, 15 Mar 2002 17:35:06 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21803 for ; Fri, 15 Mar 2002 17:34:19 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2FMXKe03638; Fri, 15 Mar 2002 16:33:20 -0600 From: "Dean Willis" To: "'Ben Campbell'" , "'Heil Franca Marcelo ICM N PG U ID A 2'" Cc: Subject: RE: [Simple] Message Sizes (was Messages: Signaling, Data, or Theft) Message-ID: <045f01c1cc71$5f4c2100$bb036e3f@TXDWILLIS2> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 15 Mar 2002 16:33:03 -0600 Content-Transfer-Encoding: 7bit > > 1) We could add something like a duration indicator to the 302 > > response, much like the TTL on DNS lookups. Or we could > contrive to do > > something at the DNS level, although this really doesn't > give us the > > message-type specific behavior potentially provided by the > LS in this > > example. Or we could rely on a "bounce" from question 2 to > let us know > > that the situation has changed and we need to reconsider the route. > > Actually, the current SIP spec officially supports the use of > the Expires header in 302 responses for this purpose. Ahah. So: By combining this with proxy-recursion on 302 responses, we have a way to optimally target MESSAGES (and other traffic) to a particular end point in such a way that proxies that MUS Tbe on the path are retained, and those that don't have to be aren't. All it takes are two rules: 1) A "proxy" node that does not want to stay in the loop 302 redirects to the next hop, rather than proxying 2) A "proxy" node which proxies recurses on 301/302 responses and MAY record-route if it wants to be in-the loop for all messages in a resulting dialog Actually, I think this solves a whole lot of things . . . -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Mar 17 22:17:12 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17197 for ; Sun, 17 Mar 2002 22:17:12 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2I3DCMb017639; Sun, 17 Mar 2002 22:13:13 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA01287; Sun, 17 Mar 2002 22:16:08 -0500 (EST) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA01270 for ; Sun, 17 Mar 2002 22:13:14 -0500 (EST) Received: from d23rh902.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g2I37ln330376 for ; Mon, 18 Mar 2002 13:07:47 +1000 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2I3D2675346 for ; Mon, 18 Mar 2002 14:13:03 +1100 To: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 18/03/2002 11:12:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] We need a clear description of Presence Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 10:35:47 +0800 Hi, all We need a clear description of Presence, not just described as online/offline/away... What is standardized in draft-ietf-impp-cpim-pidf-01 is not sufficient. Presence is defined in RFC2778 as the communication state of a user. In fact, it's a broad concept. The presence information can include following aspects: 1. online/offline/away status, 2. user willingness: do not disturb/willing to chat, 3. available communication device status: open/close, 4. geography location, 5. presence history is also very useful and more. How can we descibe all this information in a unified way? Your comments are welcome. Best regards, Tang Lihua Research Member, Infrastructure Technology IBM China Research Lab. Phone: (8610)62986677-542 Tie line: 905-542 Email: tanglih@cn.ibm.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 18 20:17:50 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28174 for ; Mon, 18 Mar 2002 20:17:50 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2J1E6gB007356; Mon, 18 Mar 2002 20:14:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03212; Mon, 18 Mar 2002 20:17:05 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03197 for ; Mon, 18 Mar 2002 20:16:37 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2J1G5k01593; Mon, 18 Mar 2002 20:16:06 -0500 (EST) Received: from cisco.com (rtp-vpn1-482.cisco.com [10.82.225.226]) by cannon.cisco.com (Mirapoint) with ESMTP id AAG96826; Mon, 18 Mar 2002 20:18:56 -0500 (EST) Message-ID: <3C96913C.F810071D@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Li Hua Tang CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] We need a clear description of Presence References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 20:15:40 -0500 Content-Transfer-Encoding: 7bit Comments below. Paul Li Hua Tang wrote: > > Hi, all > > We need a clear description of Presence, not just described as > online/offline/away... What is standardized in draft-ietf-impp-cpim-pidf-01 > is not sufficient. > > Presence is defined in RFC2778 as the communication state of a user. In > fact, it's a broad concept. The presence information can include following > aspects: > 1. online/offline/away status, > 2. user willingness: do not disturb/willing to chat, > 3. available communication device status: open/close, > 4. geography location, > 5. presence history is also very useful > and more. > > How can we descibe all this information in a unified way? It hasn't been discussed much, but there is considerable overlap between presence and callerprefs. Callerprefs provides a way to qualify the Contact addresses registered for an address-of-record. For instance, the media, classes of calls, and priorities that are acceptable. Also q-values permit prioritizing among alternative contact addresses, so that for instance voicemail can be ranked higher than direct connection for some types of calls. This hasn't been integrated into the default presence document, but it ought to be. The presence document as currently defined has the contact addresses and the q-values, but not the other qualifying information. This added information can be used to describe many, but not all,of the things mentioned above. For instance, suppose you have a device capable of both voice and chat. Normally you might register as: REGISTER ... ... Contact: sip:your@device;media="audio/*,message/*" If you receive a voice call, and want to indicate unavailability for voice, but continued availability to chat, you might reregister: REGISTER ... ... Contact: sip:your@device;media="message/*" They you would update this again at completion of your call when you are again willing to receive voice. Given a suitable linkage between the registrar and presence server, then these changes ought to be reported as presence changes. This isn't a complete solution to the issues you describe. It can be viewed as extra capability that reduces the problem, or it may be considered as making the problem larger. I think it is essential that presence and callerprefs be harmonized. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 19 00:16:45 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05576 for ; Tue, 19 Mar 2002 00:16:45 -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 g2J5DBgB008164; Tue, 19 Mar 2002 00:13:11 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03933; Tue, 19 Mar 2002 00:16:08 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03915 for ; Tue, 19 Mar 2002 00:15:11 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2J5EuTE010176; Tue, 19 Mar 2002 00:14:56 -0500 (EST) Message-ID: <3C96C912.6D26FF18@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Li Hua Tang , simple@mailman.dynamicsoft.com Subject: Re: [Simple] We need a clear description of Presence References: <3C96913C.F810071D@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 19 Mar 2002 00:13:54 -0500 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > If you receive a voice call, and want to indicate unavailability for > voice, > but continued availability to chat, you might reregister: > > REGISTER ... > ... > Contact: sip:your@device;media="message/*" > > They you would update this again at completion of your call when > you are again willing to receive voice. > > Given a suitable linkage between the registrar and presence server, > then these changes ought to be reported as presence changes. > > This isn't a complete solution to the issues you describe. It can be > viewed as extra capability that reduces the problem, or it may be > considered as making the problem larger. I think it is essential that > presence and callerprefs be harmonized. I think you want the presence document to be able to support the expressiveness which caller preferences has. However, I don't think you want a user to explicitly set their presence by registrations. Rather, the presence server would compose their registrations (including caller prefs data), with their uploaded presence docs (which provide explicit presence indications), to generate a final composed presence document. Using caller prefs for the UA to explicitly set presence is bad, since it depends on the UA knowing the policy of the presence server in its construction of the presence doc. By being explicit, i..e, "set my presence to available", that problem is avoided. That said, I think much work is needed to build upon PIDF and add status values and other parameters needed for a more expressive system. At the very least, we need some statuses for IM. I would really like to see such a work item picked up by SIMPLE. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 19 00:19:04 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05652 for ; Tue, 19 Mar 2002 00:19:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2J5FMgB008222; Tue, 19 Mar 2002 00:15:22 -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 AAA03958; Tue, 19 Mar 2002 00:18:26 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03920 for ; Tue, 19 Mar 2002 00:15:36 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2J5EtZ02581 for ; Tue, 19 Mar 2002 07:14:55 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Mar 2002 07:14:43 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Mar 2002 07:14:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do wit message threading) Message-ID: Thread-Topic: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do wit message threading) Thread-Index: AcHMVdK21bg/IsS/TGyKXdCK+61JgQCdLkpQ To: , , , Cc: X-OriginalArrivalTime: 19 Mar 2002 05:14:43.0129 (UTC) FILETIME=[FA6C1290:01C1CF04] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id AAA03920 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 19 Mar 2002 07:14:42 +0200 Content-Transfer-Encoding: 8bit Hi, Right. And fortunately there are some sub-IP mechanisms in place to separate RTP and SIP and even do L2 fragmentation so that a large SIP IP-packet won't block RTP. Mid-call signaling was also one of the reasons to start developing SigComp. What I'm more worried is the prioritization of SIP vs. SIP, i.e. handling of call setup signaling compared to messaging or presence or whatever SIP will be used next for. That logic needs to reside in the application layer, as for e.g. DiffServ classifiers all SIP looks the same. The list of reasons is this: - SIP call setup budget with manyfolks and resource reservation over low-capacity wireless will be tight even with SigComp. It must be possible to separate this traffic from other SIP traffic, e.g. messages. - This is especially true when thinking about emergency services. - Some operators want to separate call setup traffic from other traffic also for charging reasons (no volume-based charging for "signaling"). This is done by having counters on SIP traffic. It must be possible to separate SIP call setup signaling from other SIP traffic for this reason as well. I'm not sure if there is anything to standardize for SIP though. In the simplest case this could be seen as a policy issue for SIP UAs and proxies, so that they would mark different SIP packets differently (for example with different DS codepoints). These just need to be configured right in proxies and routers. So this may be an additional(?) requirement to SIP device configuration. But maybe someone has a clearer view. Markus > -----Original Message----- > From: ext Dean Willis [mailto:dwillis@dynamicsoft.com] > Sent: 15 March, 2002 21:16 > To: Ben Campbell; Isomaki Markus (NRC/Helsinki); hgs@cs.columbia.edu; > mhammer@cisco.com > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Messages: Signaling, Data, or Theft > (Wassomethingto do wit message threading) > > > > Actually, if you do the math, you find that something like 64 > bytes is > the largest message size whose serialization delay doesn't > break RTP at > 9600 bps. That makes it a sub-IP interrleaving problem. > > -- > Dean > > > On Thursday 14 March 2002 04:06 pm, Ben Campbell wrote: > > > Also a question: what if there is a single TCP connection between > > > UA and proxy. Proxy starts to transmit a large MESSAGE toward UA. > > > In the meanwhile an INVITE for a voice call arrives at the proxy > > > to be delivered to the same UA. Is it possible to interleave it > > > between the TCP segments carrying MESSAGE, or does MESSAGE block > > > the transport? > > > > That could be a problem in some scenarios. I think the real answer, > > though, is to limit the MESSAGE requests to some reasonable size. We > > have had talk about standardizing methods to send large data by > > reference--I think any real application that sends messages > > containing much bigger than an average text IM will eventually need > > to go that route. > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 19 09:33:46 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22809 for ; Tue, 19 Mar 2002 09:33:46 -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 g2JEU5gB010155; Tue, 19 Mar 2002 09:30:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05658; Tue, 19 Mar 2002 09:33:05 -0500 (EST) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05647 for ; Tue, 19 Mar 2002 09:32:44 -0500 (EST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16767 for ; Tue, 19 Mar 2002 09:30:18 -0500 (EST) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16753 for ; Tue, 19 Mar 2002 09:30:18 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] We need a clear description of Presence X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <8CA1128D59AD27429985B397118CEDDF78FEFE@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] We need a clear description of Presence Thread-Index: AcHPBXOcIZ/EK3gJRkKf+NiYpeKsYAATKgWw From: "Boyer, David G (Dave)" To: "Jonathan Rosenberg" , "Paul Kyzivat" Cc: "Li Hua Tang" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA05647 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 19 Mar 2002 09:32:26 -0500 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, March 19, 2002 12:14 AM > To: Paul Kyzivat > Cc: Li Hua Tang; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] We need a clear description of Presence > > > > > Paul Kyzivat wrote: > > > > > If you receive a voice call, and want to indicate unavailability for > > voice, > > but continued availability to chat, you might reregister: > > > > REGISTER ... > > ... > > Contact: sip:your@device;media="message/*" > > > > They you would update this again at completion of your call when > > you are again willing to receive voice. > > > > Given a suitable linkage between the registrar and presence server, > > then these changes ought to be reported as presence changes. Presence changes should also be reportable by non-communicative devices - video motion detection/face recognition, blue-tooth node registration, etc. Desiring presence information about someone does not necessarily imply the desire to communicate with that person. > > ... > > Using caller prefs for the UA to explicitly set presence is bad, since > it depends on the UA knowing the policy of the presence server in its > construction of the presence doc. By being explicit, i..e, "set my > presence to available", that problem is avoided. Shouldn't availability be expressible on a per user basis, not just globally? > > That said, I think much work is needed to build upon PIDF and > add status > values and other parameters needed for a more expressive > system. At the > very least, we need some statuses for IM. I would really like to see > such a work item picked up by SIMPLE. > > Thanks, > Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 19 11:19:51 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25792 for ; Tue, 19 Mar 2002 11:19:51 -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 g2JGG5gB011281; Tue, 19 Mar 2002 11:16:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06017; Tue, 19 Mar 2002 11:19:05 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06006 for ; Tue, 19 Mar 2002 11:18:14 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2JGHgs28216; Tue, 19 Mar 2002 11:17:42 -0500 (EST) Received: from cisco.com (rtp-vpn2-576.cisco.com [10.82.242.64]) by cannon.cisco.com (Mirapoint) with ESMTP id AAH00185; Tue, 19 Mar 2002 11:20:32 -0500 (EST) Message-ID: <3C97648B.D46001EB@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Li Hua Tang , simple@mailman.dynamicsoft.com Subject: Re: [Simple] We need a clear description of Presence References: <3C96913C.F810071D@cisco.com> <3C96C912.6D26FF18@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 19 Mar 2002 11:17:15 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > I think you want the presence document to be able to support the > expressiveness which caller preferences has. However, I don't think you > want a user to explicitly set their presence by registrations. Rather, > the presence server would compose their registrations (including caller > prefs data), with their uploaded presence docs (which provide explicit > presence indications), to generate a final composed presence document. > > Using caller prefs for the UA to explicitly set presence is bad, since > it depends on the UA knowing the policy of the presence server in its > construction of the presence doc. By being explicit, i..e, "set my > presence to available", that problem is avoided. Since there is no standard for uploading a presence document, a UA *always* has to know the policy the presence server uses to construct or acquire the presence document. Knowing that the presence server will construct the document in a way consistent with the registration is no worse than knowing that it gets it by ftp upload to a particular file, or by payload in a REGISTER message. Use of callerprefs requires registration. Requiring that the UA also format and upload a presence document each time simply adds to the burden on both it and the servers - at least in the case that presence server and registrar are colocated. It also can result in divergence of the two states, through error or negligence. > > That said, I think much work is needed to build upon PIDF and add status > values and other parameters needed for a more expressive system. At the > very least, we need some statuses for IM. I would really like to see > such a work item picked up by SIMPLE. agreed. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 19 11:38:41 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26393 for ; Tue, 19 Mar 2002 11:38:40 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2JGZ0gB011553; Tue, 19 Mar 2002 11:35:00 -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 LAA06114; Tue, 19 Mar 2002 11:38:04 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06103 for ; Tue, 19 Mar 2002 11:37:38 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2JGb6700981; Tue, 19 Mar 2002 11:37:06 -0500 (EST) Received: from cisco.com (rtp-vpn2-576.cisco.com [10.82.242.64]) by cannon.cisco.com (Mirapoint) with ESMTP id AAH00388; Tue, 19 Mar 2002 11:39:57 -0500 (EST) Message-ID: <3C976918.D9B16082@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Boyer, David G (Dave)" CC: Jonathan Rosenberg , Li Hua Tang , simple@mailman.dynamicsoft.com Subject: Re: [Simple] We need a clear description of Presence References: <8CA1128D59AD27429985B397118CEDDF78FEFE@nj7460avexu1.global.avaya.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 19 Mar 2002 11:36:40 -0500 Content-Transfer-Encoding: 7bit comments below. Paul "Boyer, David G (Dave)" wrote: > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, March 19, 2002 12:14 AM > > To: Paul Kyzivat > > Cc: Li Hua Tang; simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] We need a clear description of Presence > > > > > > > > > > Paul Kyzivat wrote: > > > > > > > > If you receive a voice call, and want to indicate unavailability for > > > voice, > > > but continued availability to chat, you might reregister: > > > > > > REGISTER ... > > > ... > > > Contact: sip:your@device;media="message/*" > > > > > > They you would update this again at completion of your call when > > > you are again willing to receive voice. > > > > > > Given a suitable linkage between the registrar and presence server, > > > then these changes ought to be reported as presence changes. > > Presence changes should also be reportable by non-communicative devices - > video motion detection/face recognition, blue-tooth node registration, > etc. Desiring presence information about someone does not necessarily imply > the desire to communicate with that person. I don't understand your point. Devices must be communicative in some way to report presence. Are you saying that some devices that don't do sip may want to update presence? I am not suggesting that registration must be the *only* way of doing so. But I am suggesting that a *subset* of the presence information is in 1:1 correspondence to registration information, and that *one way* for that information to get into the presence document is via the registrar. I realize this is controversial, but I believe that it is *best* for the presence server to get that portion of the presence document content from the registrar. This is analogous to expecting a proxy server and registrar to communicate via an unspecified location service. > > Using caller prefs for the UA to explicitly set presence is bad, since > > it depends on the UA knowing the policy of the presence server in its > > construction of the presence doc. By being explicit, i..e, "set my > > presence to available", that problem is avoided. > > Shouldn't availability be expressible on a per user basis, not just > globally? Again I don't understand your point. ("Not just globally?" ???) **** _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 19 11:45:42 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26617 for ; Tue, 19 Mar 2002 11:45:42 -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 g2JGg1gB011721; Tue, 19 Mar 2002 11:42:01 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06170; Tue, 19 Mar 2002 11:45:06 -0500 (EST) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06157 for ; Tue, 19 Mar 2002 11:44:57 -0500 (EST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18078 for ; Tue, 19 Mar 2002 11:42:32 -0500 (EST) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18065 for ; Tue, 19 Mar 2002 11:42:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] We need a clear description of Presence Message-ID: <8CA1128D59AD27429985B397118CEDDF391249@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] We need a clear description of Presence Thread-Index: AcHPZF4bEdI3Jp4UQtWUvaiJddf4/wAAApgA From: "Boyer, David G (Dave)" To: "Paul Kyzivat" Cc: "Jonathan Rosenberg" , "Li Hua Tang" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA06157 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 19 Mar 2002 11:44:40 -0500 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, March 19, 2002 11:37 AM > To: Boyer, David G (Dave) > Cc: Jonathan Rosenberg; Li Hua Tang; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] We need a clear description of Presence > > > comments below. > > Paul > > "Boyer, David G (Dave)" wrote: > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Tuesday, March 19, 2002 12:14 AM > > > To: Paul Kyzivat > > > Cc: Li Hua Tang; simple@mailman.dynamicsoft.com > > > Subject: Re: [Simple] We need a clear description of Presence > > > > > > > > > > > > > > > Paul Kyzivat wrote: > > > > > > > > > > > If you receive a voice call, and want to indicate > unavailability for > > > > voice, > > > > but continued availability to chat, you might reregister: > > > > > > > > REGISTER ... > > > > ... > > > > Contact: sip:your@device;media="message/*" > > > > > > > > They you would update this again at completion of your call when > > > > you are again willing to receive voice. > > > > > > > > Given a suitable linkage between the registrar and > presence server, > > > > then these changes ought to be reported as presence changes. > > > > Presence changes should also be reportable by > non-communicative devices - > > video motion detection/face recognition, blue-tooth node > registration, > > etc. Desiring presence information about someone does not > necessarily imply > > the desire to communicate with that person. > > I don't understand your point. Devices must be communicative > in some way > to report presence. Are you saying that some devices that don't do sip > may want to update presence? Definitly - biometric devices are not capable of communications but can indicate very accurate presence information, surveillance cameras can be used to uniquely identify individuals, etc. This presence information should also be recorded in a Presence server. Perhaps this is out side the scope of SIP, but it is not outside the scope of a presence service. > > I am not suggesting that registration must be the *only* way > of doing so. > > But I am suggesting that a *subset* of the presence information is in > 1:1 correspondence to registration information, and that *one way* > for that information to get into the presence document is via > the registrar. > > I realize this is controversial, but I believe that it is *best* for > the presence server to get that portion of the presence > document content > from the registrar. This is analogous to expecting a proxy server and > registrar to communicate via an unspecified location service. This is fine for SIP devices. Perhaps the answer is that the other devices need to communicate to the Presence server via a different means, although it seems that using the SIP registration method would make sense for these non-standard devices. > > > > Using caller prefs for the UA to explicitly set presence > is bad, since > > > it depends on the UA knowing the policy of the presence > server in its > > > construction of the presence doc. By being explicit, i..e, "set my > > > presence to available", that problem is avoided. > > > > Shouldn't availability be expressible on a per user basis, not just > > globally? > > Again I don't understand your point. ("Not just globally?" ???) > **** The way Johnathan worded setting availability above sounded to me that availability is something you toggle on and off. Availability can be more complex than that. I am available to Johnathan through IM only, I am available to Paul via cell-phone and IM, etc. Perhaps I misunderstood Johnathans comment. Dave _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 19 12:09:42 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27473 for ; Tue, 19 Mar 2002 12:09:41 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2JH62gB012203; Tue, 19 Mar 2002 12:06:02 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06305; Tue, 19 Mar 2002 12:09:04 -0500 (EST) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06294 for ; Tue, 19 Mar 2002 12:08:55 -0500 (EST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16395 for ; Tue, 19 Mar 2002 12:06:31 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16380 for ; Tue, 19 Mar 2002 12:06:31 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] We need a clear description of Presence Message-ID: Thread-Topic: [Simple] We need a clear description of Presence Thread-Index: AcHPZF4bEdI3Jp4UQtWUvaiJddf4/wAAApgAAACgHQA= From: "Zmolek, Andrew (Andrew)" To: "Boyer, David G (Dave)" , "Paul Kyzivat" Cc: "Jonathan Rosenberg" , "Li Hua Tang" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA06294 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 19 Mar 2002 10:08:42 -0700 Content-Transfer-Encoding: 8bit Comments inline... >> I don't understand your point. Devices must be communicative >> in some way to report presence. Are you saying that some >> devices that don't do sip may want to update presence? > > Definitly - biometric devices are not capable of communications > but can indicate very accurate presence information, > surveillance cameras can be used to uniquely identify > individuals, etc. This presence information should also be > recorded in a Presence server. Perhaps this is out side the > scope of SIP, but it is not outside the scope of a presence > service. This is a key point. Primary sensors are connected to analysis systems, which probably don't provide presence. But those systems create intelligence that is useful and a potential feed into a presence system. This notion of multiple feeds from analysis system makes the notion of presence via a single document seem overly constrained, as there are probably going to be many feeds to the presence service. Plus, exposure of availability is a different matter (and isn't likely to be the complete "document" of information known to the presence service and could be a complete lie for my local telemarketer, for instance) >> I am not suggesting that registration must be the *only* way >> of doing so. >> >> But I am suggesting that a *subset* of the presence information is in >> 1:1 correspondence to registration information, and that *one way* >> for that information to get into the presence document is via >> the registrar. >> >> I realize this is controversial, but I believe that it is *best* for >> the presence server to get that portion of the presence >> document content from the registrar. This is analogous to expecting >> a proxy server and registrar to communicate via an unspecified >> location service. Again, there are going to be lots of feeds from lots of sources. Registrars will form a key part of the resulting data, but there isn't any point in constraining the notion of presence by excluding other valid feeds. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 19 21:44:56 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11822 for ; Tue, 19 Mar 2002 21:44:55 -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 g2K2f5gB016791; Tue, 19 Mar 2002 21:41:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08207; Tue, 19 Mar 2002 21:44:05 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08195 for ; Tue, 19 Mar 2002 21:43:27 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.147]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2K2hVTE011439; Tue, 19 Mar 2002 21:43:31 -0500 (EST) Message-ID: <3C97F70D.C43EDE93@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Boyer, David G (Dave)" CC: Paul Kyzivat , Li Hua Tang , simple@mailman.dynamicsoft.com Subject: Re: [Simple] We need a clear description of Presence References: <8CA1128D59AD27429985B397118CEDDF391249@nj7460avexu1.global.avaya.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 19 Mar 2002 21:42:21 -0500 Content-Transfer-Encoding: 7bit "Boyer, David G (Dave)" wrote: > > > I don't understand your point. Devices must be communicative > > in some way > > to report presence. Are you saying that some devices that don't do sip > > may want to update presence? > > Definitly - biometric devices are not capable of communications > but can indicate very accurate presence information, surveillance > cameras can be used to uniquely identify individuals, etc. This > presence information should also be recorded in a Presence server. > Perhaps this is out side the scope of SIP, but it is not outside > the scope of a presence service. It is within the scope of a SIP based presence system to report presence that includes that kind of information. It is fundamental to the model we have been advocating that a presence document is a composition of data sources from potentially disparate devices. In this case, it is very unlikely that the presence data arrives to the server via SIP, but it doesn't have to in order to be distributed by a SIP based presence server. > > > Shouldn't availability be expressible on a per user basis, not just > > > globally? > > > > Again I don't understand your point. ("Not just globally?" ???) > > **** > The way Johnathan worded setting availability above sounded to me that > availability is something you toggle on and off. Availability can be > more complex than that. I am available to Johnathan through IM only, > I am available to Paul via cell-phone and IM, etc. Perhaps I > misunderstood > Johnathans comment. I wasn't saying it was global. I was merely saying that a user should be allowed to explicitly ask the server to set particular aspects of a presence document, and the way it does this is by publishing such a document to the server. Whether the presence server uses the values it provides is a matter of local policy, but at least the server knows the intent of the user. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 19 21:46:45 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11841 for ; Tue, 19 Mar 2002 21:46:44 -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 g2K2h1gB016820; Tue, 19 Mar 2002 21:43:01 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08234; Tue, 19 Mar 2002 21:46:05 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08221 for ; Tue, 19 Mar 2002 21:45:16 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.147]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2K2jETE011442; Tue, 19 Mar 2002 21:45:14 -0500 (EST) Message-ID: <3C97F779.22A9247D@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "Boyer, David G (Dave)" , Li Hua Tang , simple@mailman.dynamicsoft.com Subject: Re: [Simple] We need a clear description of Presence References: <3C976918.D9B16082@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 19 Mar 2002 21:44:09 -0500 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > But I am suggesting that a *subset* of the presence information is in > 1:1 correspondence to registration information, and that *one way* > for that information to get into the presence document is via the > registrar. > > I realize this is controversial, but I believe that it is *best* for > the presence server to get that portion of the presence document content > from the registrar. This is analogous to expecting a proxy server and > registrar to communicate via an unspecified location service. I don't want to ever dictate policy on how a PA composes a presence document. Its that simple. All we can do is provide ways for a user to explicitly indicate what they want. How the PA collects that information and generates a composite presence document MUST be permitted to be entirely a matter of local policy. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 19 23:49:37 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15050 for ; Tue, 19 Mar 2002 23:49:37 -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 g2K4k2gB017301; Tue, 19 Mar 2002 23:46:02 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08665; Tue, 19 Mar 2002 23:49:05 -0500 (EST) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08652 for ; Tue, 19 Mar 2002 23:48:15 -0500 (EST) Received: from maillennium.att.com ([135.25.114.99]) by almso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g2K4lK901548 for ; Tue, 19 Mar 2002 23:47:21 -0500 (EST) Received: from att.com ([135.210.75.30]) by maillennium.att.com (mailgw1) with SMTP id <20020320044719gw1001rqp9e> (Authid: tony); Wed, 20 Mar 2002 04:47:19 +0000 Message-ID: <3C981275.F3228127@att.com> From: Tony Hansen X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: SIMPLE list Subject: Re: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again) References: <20020206000526.76476.qmail@web11608.mail.yahoo.com> <3C7C0CCC.D6EBC1BC@att.com> <3C885FAF.A82A3222@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 19 Mar 2002 23:39:17 -0500 Content-Transfer-Encoding: 7bit Discussion on the components document is scheduled for the last 45 minutes of the SIMPLE slot. While we can probably get some things agreed on during that time, there are probably a number of issues that won't be. Since face to face is so much higher bandwidth than email, are people interested in continuing a discussion of the components document and IM/P service profiles either over dinner on Wednesday after SIMPLE, over lunch on Thursday, or over dinner on Thursday? Tony Hansen tony@att.com Jonathan Rosenberg wrote: > > Tony Hansen wrote: > > > > Here are some ideas on how this could play out within the IETF. > > > > One of the documents being put out in the SIP WG is SIP Call Flow > > Examples. It shows how the SIP protocol should be used in an IP > > Telephony service. > > > > Another effort in the IETF is the Voice Profile for Internet Messaging > > (VPIM) working group. That group has been figuring out how to do voice > > messaging (for voice mailboxes) using existing protocols, such as SMTP > > and IMAP. Where the existing protocols were lacking, they also worked on > > filling in the gaps, either within the VPIM WG or in conjunction with > > other working groups (e.g., imap-ext). Note: the VPIM WG was originally > > formed due to input from an external organization, the EMA, but the work > > has all been done here in the IETF. > > > > The problem we're facing here in SIMPLE seems to be in the same > > category, and the solution may be similar. It appears that what is > > required is a profile for an instant messaging service saying how it > > should pull together the different piece parts to form a coherent whole. > > Well, there are two parts. > > Part one, is to specify the pieces, and to make sure they are all there. > Part two, is to specify an architecture that puts them together as a > whole. > > Part one is definitely an IETF activity. We really have most of the > pieces, and the few that remain, are easy. I have written an I-D on this > subject, which discusess the pieces needed for a consumer IM/buddy-list > application: > > http://www.ietf.org/internet-drafts/draft-rosenberg-simple-components-00.txt > > I'd really like to get group input on whether there is > interest/agreement on which aspects of my proposed plan. > > The second piece, part two, is to specify an architecture that pulls it > all together. If such a thing were done here, it would need to be > informational to say the least. There is precendent for publication of > informational architecture docs generated by other bodies (the DCS > architecture). I think SOMEONE needs to put this together, that is for > certain. If no one else is stepping up to the plate, I'd prefer IETF to > nobody, thats for sure. > > > > > I'm convinced we can solve this problem. Getting feedback from the > > industry is absolutely useful in the process, but I think the work needs > > to happen here, in the IETF. And I'm willing to work on it. > > > > Comments? Should something like this go on the SIMPLE agenda for > > Minneapolis? > > I'd like to discuss it, yes. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 20 00:36:37 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15909 for ; Wed, 20 Mar 2002 00:36:36 -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 g2K5X4gB017506; Wed, 20 Mar 2002 00:33:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08838; Wed, 20 Mar 2002 00:36:08 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08827 for ; Wed, 20 Mar 2002 00:35:29 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.114]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2K5ZdTE011516; Wed, 20 Mar 2002 00:35:39 -0500 (EST) Message-ID: <3C981F6D.9EB2863C@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-winfo-format-01.txt References: <3C88EBAF.A823F391@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 20 Mar 2002 00:34:37 -0500 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > I have a question about: > > duration: The amount of time, in seconds, that the subscription > was in the previous state before transitioning to the state > described in the status parameter. > > I can see how this can be useful when receiving a notification > containing only changes. But it is less useful when doing a fetch, or > when receiving the initial notification > following a subscription. Agreed. > In those cases there is no way to know how > long the subscription has been in the current state. Good point. > > One solution would be to provide two values. But I think it is > sufficient to provide only the duration in the current state. This is > clearly the value needed when you have > no prior information about the subscription. If you have a prior value, > then the total time in the prior state, if desired, can be computed > using the prior duration value, > the time the last notification was sent, and the time the current > notification was sent. Seems reasonable. Of course, now the opposite problem occurs. Notifications sent on state changes will always have a duration of zero, providing meaningless information. So, either the fetch and subscribe-triggered notifies have useless durations, or the event-triggered notifications have useless durations.... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 20 01:40:48 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16768 for ; Wed, 20 Mar 2002 01:40:48 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2K6b4gB017730; Wed, 20 Mar 2002 01:37:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09069; Wed, 20 Mar 2002 01:40:06 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09056 for ; Wed, 20 Mar 2002 01:39:26 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.114]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2K6dZTE011539; Wed, 20 Mar 2002 01:39:36 -0500 (EST) Message-ID: <3C982E67.E7FC1F9A@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Torrey Searle CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Date header and offline messages References: <3C88A1A5.8020102@indigosw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 20 Mar 2002 01:38:31 -0500 Content-Transfer-Encoding: 7bit Torrey Searle wrote: > > in 9.5 it seems to allow for a store and forward mechanism with sip > messaging. > Am I correct in assuming that the Date header a forwared delayed request > > must have an updated date header to avoid being blocked by the replay > prevention described in 11.3? Good point. I would prefer that the date header NOT be updated (as this would invalidate the signature). Rather, the text in the message draft add some words that indicate that a late IM may not indicate an attack, and then give some guidelines about what it would mean, and when its OK, and when its not. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 20 09:36:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00588 for ; Wed, 20 Mar 2002 09:36:02 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2KEW7gB019434; Wed, 20 Mar 2002 09:32:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10532; Wed, 20 Mar 2002 09:35:07 -0500 (EST) Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA10518 for ; Wed, 20 Mar 2002 09:34:16 -0500 (EST) Message-ID: <20020320143323.41489.qmail@web11603.mail.yahoo.com> Received: from [166.63.189.85] by web11603.mail.yahoo.com via HTTP; Wed, 20 Mar 2002 06:33:23 PST From: Sean Olson Subject: Re: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again) To: Tony Hansen , SIMPLE list In-Reply-To: <3C981275.F3228127@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 20 Mar 2002 06:33:23 -0800 (PST) This sounds like a good thing. How about Wednesday evening over dinner before the plenary? /sean --- Tony Hansen wrote: > Discussion on the components document is scheduled > for the last 45 > minutes of the SIMPLE slot. While we can probably > get some things agreed > on during that time, there are probably a number of > issues that won't > be. Since face to face is so much higher bandwidth > than email, are > people interested in continuing a discussion of the > components document > and IM/P service profiles either over dinner on > Wednesday after SIMPLE, > over lunch on Thursday, or over dinner on Thursday? > > Tony Hansen > tony@att.com ===== Sean Olson __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 20 10:20:39 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02062 for ; Wed, 20 Mar 2002 10:20:39 -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 g2KFH2gB019852; Wed, 20 Mar 2002 10:17:02 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10701; Wed, 20 Mar 2002 10:20:05 -0500 (EST) Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10687 for ; Wed, 20 Mar 2002 10:19:18 -0500 (EST) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2KFI2d54591; Wed, 20 Mar 2002 09:18:02 -0600 (CST) From: "Ben Campbell" To: "Paul Kyzivat" , "Boyer, David G \(Dave\)" Cc: "Jonathan Rosenberg" , "Li Hua Tang" , Subject: RE: [Simple] We need a clear description of Presence 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C976918.D9B16082@cisco.com> Importance: Normal Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 20 Mar 2002 09:18:02 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Paul Kyzivat > Sent: Tuesday, March 19, 2002 10:37 AM > To: Boyer, David G (Dave) > Cc: Jonathan Rosenberg; Li Hua Tang; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] We need a clear description of Presence > But I am suggesting that a *subset* of the presence information is in > 1:1 correspondence to registration information, and that *one way* > for that information to get into the presence document is via the > registrar. > > I realize this is controversial, but I believe that it is *best* for > the presence server to get that portion of the presence document content > from the registrar. This is analogous to expecting a proxy server and > registrar to communicate via an unspecified location service. > That is a perfectly acceptable and useful presence service to build with SIMPLE. But SIMPLE must not mandate that particular service. I can envision SIMPLE related services with no registrar involved at all. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Mar 22 00:58:17 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09838 for ; Fri, 22 Mar 2002 00:58:17 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2M5s6gB001967; Fri, 22 Mar 2002 00:54:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17730; Fri, 22 Mar 2002 00:57:06 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17719 for ; Fri, 22 Mar 2002 00:56:33 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2M5trt29175 for ; Fri, 22 Mar 2002 07:55:53 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Mar 2002 07:55:40 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 22 Mar 2002 07:55:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: [Simple] We need a clear description of Presence Thread-Index: AcHQJ5QHlPfqDQopQ36JiPExrAY8hgBPESjg To: Cc: X-OriginalArrivalTime: 22 Mar 2002 05:55:40.0200 (UTC) FILETIME=[32309A80:01C1D166] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id AAA17719 Subject: [Simple] Requirements to SIMPLE components continuation Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 22 Mar 2002 07:55:39 +0200 Content-Transfer-Encoding: 8bit Hi, It seems that work based on the proposals in the SIMPLE components draft is getting started within SIMPLE and SIPPING. In addition to those mentioned in the draft and presentation, I would like to propose the following requirements: - Private messages in a multiparty centralized conference with messaging sessions. This means that if a number of participants are in a conference/chat via a centralized server it should be possible to send a private (i.e. only shown to the selected recipient, not the whole conference) message between two participants. It must be possible to correlate it somehow on the ongoing conference, so that it can be shown correctly on recipient's chat window, meaning that a completely separate one-shot message is not the right solution. - Showing different presence information to different Watchers. This means that e.g. for some Watchers the status of IMs is just "closed", while for others something more accurate could be shown. So, basically the presence doc. is formed based on who is asking for it, and there must be a way for the presentity to control this. - Presence subscription filtering. This means that a Watcher should be able to presence to the changes in certain _part_ of the presence info. If other parts change, NOTIFYs are not generated. Do these seem like reasonable requirements? Are there already solutions for these, or should they be included in the starting work? Markus _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Mar 24 18:47:32 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19855 for ; Sun, 24 Mar 2002 18:47:32 -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 g2ONh7gB012335; Sun, 24 Mar 2002 18:43:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29645; Sun, 24 Mar 2002 18:46:08 -0500 (EST) Received: from a-start.start.syd ([203.111.107.186]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29634 for ; Sun, 24 Mar 2002 18:45:55 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Simple] Requirements to SIMPLE components continuation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <0EB17E926D035949A09C0F4CD5E9D77302F234@a-start.start.syd> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Simple] We need a clear description of Presence Thread-Index: AcHQJ5QHlPfqDQopQ36JiPExrAY8hgBPESjgAIoWxDA= From: "Stephen Gryphon" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id SAA29634 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 10:44:40 +1100 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > - Private messages in a multiparty centralized conference > with messaging sessions. This means that if a number of > participants are in a conference/chat via a centralized > server it should be possible to send a private (i.e. only > shown to the selected recipient, not the whole conference) > message between two participants. It must be possible to > correlate it somehow on the ongoing conference, so that it > can be shown correctly on recipient's chat window, meaning > that a completely separate one-shot message is not the right solution. The central conferencing model we are basing our work on is similar to a mailing list, where when a message is posted the Request-URI and the To field are both the conference/address, with the From address as the speaker. This is then delivered to the conference server. The conference server then distributes the MESSAGE to all participants, setting the Request-URI to the correct value for each recipient (but keeping the To field as the conference name). [NB. It is not unusual for the To and Request-URI to not match, e.g. when proxying.] We are also assuming that threading is based on the Call-ID (or the In-Reply-To) field. This means that (a) A MESSAGE could be sent directly to the recipients address, or (b) A MESSAGE could be sent to the conference Request-URI, but with the To field as the indended individual recipient (this lets the conference server know to only forward to that participant). In both cases the Call-ID should be set appropriately (this also lets the conference server know which conference the private message is part of). It is the Call-ID (or In-Reply-To) that determines the threading and should be used by the UI to display the message in context (as per the Components draft). In short: - The UI should correlate the conference based on the Call-ID. - Separate one-shot should then be displayed correctly, if it can get through and passes all security checks. - For a complete record the MESSAGE can still go via the conference server by using an appropriate Request-URI (and Call-ID), with the intended To field. Hope this helps. - Sly _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Mar 24 19:52:36 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20532 for ; Sun, 24 Mar 2002 19:52:36 -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 g2P0mxgB012463; Sun, 24 Mar 2002 19:48:59 -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 TAA29880; Sun, 24 Mar 2002 19:52:05 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29869 for ; Sun, 24 Mar 2002 19:51:59 -0500 (EST) Received: from diamond.cs.columbia.edu (diamond.cs.columbia.edu [128.59.16.9]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA00754 for ; Sun, 24 Mar 2002 19:51:05 -0500 (EST) Received: from diamond.cs.columbia.edu (localhost [127.0.0.1]) by diamond.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2P0p5AT024570 for ; Sun, 24 Mar 2002 19:51:05 -0500 (EST) Received: (from petkos@localhost) by diamond.cs.columbia.edu (8.12.1/8.12.1/Submit) id g2P0p46V024568 for simple@mailman.dynamicsoft.com; Sun, 24 Mar 2002 19:51:04 -0500 (EST) From: "Petri K. Koskelainen" Message-Id: <200203250051.g2P0p46V024568@diamond.cs.columbia.edu> To: simple@mailman.dynamicsoft.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Requirements to SIMPLE components continuation Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sun, 24 Mar 2002 19:51:04 -0500 (EST) Content-Transfer-Encoding: 7bit Hi, Since each member in a conference has a different call-id for SIP signaling (with the server), how can you send one-shot MESSAGE directly to recipient and use call-id information to indicate that this refers to existing conference? The sender does not know about call-id's between server and recipient, and there isn't any conference wide call-id. Petri _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Mar 24 23:54:02 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25167 for ; Sun, 24 Mar 2002 23:54:01 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2P4o0gB012925; Sun, 24 Mar 2002 23:50:00 -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 XAA00637; Sun, 24 Mar 2002 23:53:05 -0500 (EST) Received: from a-start.start.syd ([203.111.107.186]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00625 for ; Sun, 24 Mar 2002 23:52:34 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Simple] Requirements to SIMPLE components continuation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <0EB17E926D035949A09C0F4CD5E9D77302F235@a-start.start.syd> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Simple] Requirements to SIMPLE components continuation Thread-Index: AcHTlzbFamhe2qkASoeK+IOkvEn1aAAGSSaA From: "Stephen Gryphon" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id XAA00625 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 15:51:20 +1100 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu] > Since each member in a conference has a different call-id for > SIP signaling (with the server), how can you send one-shot MESSAGE > directly to recipient and use call-id information to indicate > that this refers to existing conference? > The sender does not know about call-id's between server > and recipient, and there isn't any conference wide call-id. I don't think one-shot MESSAGE's are a good idea, but, depend on the implementation assumptions, it may work anyway. Using the conference server for passing the private MESSAGE (in-session) makes a lot more sense. Assuming the setup is per a MESSAGE session, with the signalling channels only setting up the conference session. Clients will then have a separate media channel for content MESSAGE's, which could share a common call-id. One-shot MESSAGE may work if the sender uses this common session Call-ID, and the recipient just threads all with the same Call-ID (irrespective of other headers). [I still don't like it though.] == Not sure what others think, the assumptions of a common Call-ID for the conference session makes good sense to me. In particular, when the conference server receives a MESSAGE the only thing it needs to change when broadcasting is the Request-URI. Whilst the message delivered to conference participants may then seem a little strange (e.g. it is neither To them, nor From anyone they are in direct contact with), this is not much different from when you are receiving from a proxy. It also makes the processing by the conference server very quick (rewriting To, From, and Call-ID for each outgoing connection would be extra work). Keeping the From address also allows the UI to display the author of each message (this was a problem with draft-khartabil-sip-conferencing-00, there was no way for the recipient to identify, and hence display, the author of a message). In fact, if you embed the conference identifier in the conference Request-URI, then you could actually stream incoming messages straight to outbound pipes, if you wanted a particularly fast conference server. I have some samples of the message flow, if anyone is interested. == Can anyone see any problems? - Sly _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 25 14:23:59 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27691 for ; Mon, 25 Mar 2002 14:23:59 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2PJK3xj003934; Mon, 25 Mar 2002 14:20:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02103; Mon, 25 Mar 2002 14:23:07 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02092 for ; Mon, 25 Mar 2002 14:22:47 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2PJM4I25542; Mon, 25 Mar 2002 14:22:04 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAH34728; Mon, 25 Mar 2002 14:24:53 -0500 (EST) Message-ID: <3C9F78C1.B4FC31C1@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: simple@mailman.dynamicsoft.com, jdrosen@dynamicsoft.com Subject: Re: [Simple] Requirements to SIMPLE components continuation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 14:21:37 -0500 Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > > Hi, > > It seems that work based on the proposals in the SIMPLE components draft is getting started within SIMPLE and SIPPING. > > In addition to those mentioned in the draft and presentation, I would like to propose the following requirements: > > - Private messages in a multiparty centralized conference with messaging sessions. This means that if a number of participants are in a conference/chat via a centralized server it should be possible to send a private (i.e. only shown to the selected recipient, not the whole conference) message between two participants. It must be possible to correlate it somehow on the ongoing conference, so that it can be shown correctly on recipient's chat window, meaning that a completely separate one-shot message is not the right solution. I question this. Why should private side messages involve the conference as a whole at all? This seems to violate the notion of the conference. And, why would I trust that a message delivered through a conference server will only been seen by my intended recipient? My willingness to trust this will probably vary depending upon how the conference is implemented. (For instance if the moderator of the conference is not my intended recipient.) I would prefer that the side conversations be entirely independent the shared conferencing components - via page-mode MESSAGE exchanges, or via a separate MESSAGE session. (This doesn't prohibit the GUI tying these together, based on In-Reply-To headers or the like.) > > - Showing different presence information to different Watchers. This means that e.g. for some Watchers the status of IMs is just "closed", while for others something more accurate could be shown. So, basically the presence doc. is formed based on who is asking for it, and there must be a way for the presentity to control this. This may be probematic because of scaling problems. If a separate view has to be computed for every watcher then it may not be possible to use use presence servers to distribute presence state to the masses. However, it might make sense to access-control the various presence attributes, so that only certain people are permitted to see detailed information while a larger set of people may see more general information. This would fit in well with filtering - requests for too much detail might fail for some users, where they would succeed when using a suitable filter. (Or else, the required filter could be automatically applied to avoid refusing the request.) > > - Presence subscription filtering. This means that a Watcher should be able to presence to the changes in certain _part_ of the presence info. If other parts change, NOTIFYs are not generated. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Mar 25 16:26:29 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04190 for ; Mon, 25 Mar 2002 16:26:28 -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 g2PLG8FA005049; Mon, 25 Mar 2002 16:16:08 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02506; Mon, 25 Mar 2002 16:19:05 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02495 for ; Mon, 25 Mar 2002 16:18:27 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2PLHjs08446 for ; Mon, 25 Mar 2002 23:17:45 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Mar 2002 23:17:30 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Mar 2002 23:17:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Requirements to SIMPLE components continuation Message-ID: Thread-Topic: [Simple] Requirements to SIMPLE components continuation Thread-Index: AcHUMlRzjirprzDoQOGmkNHwjjiVLgADc1gA To: Cc: , X-OriginalArrivalTime: 25 Mar 2002 21:17:30.0676 (UTC) FILETIME=[790AB740:01C1D442] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id QAA02495 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 23:17:30 +0200 Content-Transfer-Encoding: 8bit Paul Kyzivat wrote: > > I would prefer that the side conversations be entirely > independent the shared conferencing components - via > page-mode MESSAGE exchanges, or via a separate MESSAGE session. > > (This doesn't prohibit the GUI tying these together, based on > In-Reply-To headers or the like.) I guess the requirement itself is still fine. It should be possible for the recipient to show the "private" message in the right context, like in the same window where the chat conference is ongoing (as in Netmeeting). If a separate page-mode MESSAGE with In-Reply-To etc. is able to do this, it is probably OK. > However, it might make sense to access-control the various > presence attributes, so that only certain people are > permitted to see detailed information while a larger set of > people may see more general information. This would fit in > well with filtering - requests for too much detail might fail > for some users, where they would succeed when using > a suitable filter. (Or else, the required filter could be > automatically applied to avoid refusing the request.) Yes, I think this should be possible. There should be at least two levels, e.g. "public" (everyone) and "private" (my buddies or co-workers etc.). Even this might be too complicated for most users to set, but for some it could be useful. I think the filtering and other access rules should be such, that also the access to geographical location info could be controlled by them (as part of presence or as a separate event package?), if at all possible. GEOPRIV probably has some quite strict privacy requirements related to that. Markus > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 25 March, 2002 21:22 > To: Isomaki Markus (NRC/Helsinki) > Cc: simple@mailman.dynamicsoft.com; jdrosen@dynamicsoft.com > Subject: Re: [Simple] Requirements to SIMPLE components continuation > > > > > Markus.Isomaki@nokia.com wrote: > > > > Hi, > > > > It seems that work based on the proposals in the SIMPLE > components draft is getting started within SIMPLE and SIPPING. > > > > In addition to those mentioned in the draft and > presentation, I would like to propose the following requirements: > > > > - Private messages in a multiparty centralized conference > with messaging sessions. This means that if a number of > participants are in a conference/chat via a centralized > server it should be possible to send a private (i.e. only > shown to the selected recipient, not the whole conference) > message between two participants. It must be possible to > correlate it somehow on the ongoing conference, so that it > can be shown correctly on recipient's chat window, meaning > that a completely separate one-shot message is not the right solution. > > I question this. Why should private side messages involve the > conference as a whole at all? This seems to violate the > notion of the conference. And, why would I trust that > a message delivered through a conference server will only > been seen by my intended recipient? My willingness to trust > this will probably vary depending upon how the > conference is implemented. (For instance if the moderator of > the conference is not my intended recipient.) > > I would prefer that the side conversations be entirely > independent the shared conferencing components - via > page-mode MESSAGE exchanges, or via a separate MESSAGE session. > > (This doesn't prohibit the GUI tying these together, based on > In-Reply-To headers or the like.) > > > > > - Showing different presence information to different > Watchers. This means that e.g. for some Watchers the status > of IMs is just "closed", while for others something more > accurate could be shown. So, basically the presence doc. is > formed based on who is asking for it, and there must be a way > for the presentity to control this. > > This may be probematic because of scaling problems. If a > separate view has to be computed for every watcher then it > may not be possible to use use presence servers to > distribute presence state to the masses. > > However, it might make sense to access-control the various > presence attributes, so that only certain people are > permitted to see detailed information while a larger set of > people may see more general information. This would fit in > well with filtering - requests for too much detail might fail > for some users, where they would succeed when using > a suitable filter. (Or else, the required filter could be > automatically applied to avoid refusing the request.) > > > > > - Presence subscription filtering. This means that a > Watcher should be able to presence to the changes in certain > _part_ of the presence info. If other parts change, NOTIFYs > are not generated. > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 26 08:59:12 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03099 for ; Tue, 26 Mar 2002 08:59:11 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2QDt6FA009051; Tue, 26 Mar 2002 08:55:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05529; Tue, 26 Mar 2002 08:58:07 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05518 for ; Tue, 26 Mar 2002 08:57:17 -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 g2QDtcG06396 for ; Tue, 26 Mar 2002 15:55:38 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Mar 2002 15:56:19 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Mar 2002 15:56:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF104059@esebe004.NOE.Nokia.com> Thread-Topic: question about winfo-package Thread-Index: AcHUzf/zHlqJTITTTGiQ+ENINbIhPQ== To: X-OriginalArrivalTime: 26 Mar 2002 13:56:19.0232 (UTC) FILETIME=[013EAA00:01C1D4CE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA05518 Subject: [Simple] question about winfo-package Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 15:56:16 +0200 Content-Transfer-Encoding: 8bit Hi, One question about winfo-package. Lets say that winfo is applied to presence event-package and that user A has subscribed his winfo. Now user B performs FETCH (SUBSCRIBE with expires: 0) on user A's presence information. User B is authorized to subscribe A's presence: First server send winfo NOTIFY to user A then PS sends presence document to user B and immediately after that an other NOTIFY to user A with Should user A receive these two NOTIFY message or can FETCH request be considered expired when it arrives so that only the second winfo NOTIFY would be needed? regards - Mikko _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Mar 26 20:33:07 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02523 for ; Tue, 26 Mar 2002 20:33:07 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2R1R4FA015311; Tue, 26 Mar 2002 20:27:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07640; Tue, 26 Mar 2002 20:30:07 -0500 (EST) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07625; Tue, 26 Mar 2002 20:29:53 -0500 (EST) Received: from d23rh902.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g2R1OG3450438; Wed, 27 Mar 2002 12:24:16 +1100 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18]) by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2R1TW608284; Wed, 27 Mar 2002 12:29:32 +1100 Subject: Re: [Simple] question about winfo-package To: mikko.lonnfors@nokia.com Cc: simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Li Hua Tang" X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at 27/03/2002 09:29:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 09:29:02 +0800 Mikko, My opinion about your question is as follows: The motivating application for winfo package is presence authorization. If User B is authorized to subscribe A's presence, as you said, generally speaking the PS doesn't need to notify A of the B's subscription status for authorization. If the PS needs to notify A of this FETCH subscription, you may use the 'expiration' attribute of winfo foramt. Like this: In this case, A should understanding that a FETCH subscription is requested. How about this way to solute your problem? Will you attend the coming 10th SIPIT? I think We can discuss about this question and more about SIMPLE face-to-face at that time. Best regards, Tang Lihua Research Member, Infrastructure Technology IBM China Research Lab. Phone: (8610)62986677-542 Tie line: 905-542 Email: tanglih@cn.ibm.com mikko.lonnfors@nokia.com Sent by: To: simple-admin@mailman.dynam cc: icsoft.com Subject: [Simple] question about winfo-package 2002-03-26 21:56 Please respond to mikko.lonnfors Hi, One question about winfo-package. Lets say that winfo is applied to presence event-package and that user A has subscribed his winfo. Now user B performs FETCH (SUBSCRIBE with expires: 0) on user A's presence information. User B is authorized to subscribe A's presence: First server send winfo NOTIFY to user A then PS sends presence document to user B and immediately after that an other NOTIFY to user A with Should user A receive these two NOTIFY message or can FETCH request be considered expired when it arrives so that only the second winfo NOTIFY would be needed? regards - Mikko _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 27 02:36:44 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18360 for ; Wed, 27 Mar 2002 02:36:43 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2R7WwFA016557; Wed, 27 Mar 2002 02:32:58 -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 CAA08767; Wed, 27 Mar 2002 02:36:05 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08754; Wed, 27 Mar 2002 02:35:36 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2R7Yss08419; Wed, 27 Mar 2002 09:34:54 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 09:34:40 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 09:34:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] question about winfo-package Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF10405B@esebe004.NOE.Nokia.com> Thread-Topic: [Simple] question about winfo-package Thread-Index: AcHVLthgpsZYzozJT+Gs4L7860OWhgALIFgw To: Cc: , X-OriginalArrivalTime: 27 Mar 2002 07:34:40.0136 (UTC) FILETIME=[DABBA880:01C1D561] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id CAA08754 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 09:34:39 +0200 Content-Transfer-Encoding: 8bit Hi, Some comments inline -----Original Message----- From: ext Li Hua Tang [mailto:tanglih@cn.ibm.com] Sent: 27 March, 2002 03:29 To: Lonnfors Mikko (NRC/Helsinki) Cc: simple@mailman.dynamicsoft.com; simple-admin@mailman.dynamicsoft.com Subject: Re: [Simple] question about winfo-package Mikko, My opinion about your question is as follows: The motivating application for winfo package is presence authorization. If User B is authorized to subscribe A's presence, as you said, generally speaking the PS doesn't need to notify A of the B's subscription status for authorization. I would still say that winfo is designed to enable presentity to get lists of watchers interested in their presence status. This should happen regardless of the watcher's authorization status. Presence authorization may be the main motivation to enable this functionality but not the only one. If the PS needs to notify A of this FETCH subscription, you may use the 'expiration' attribute of winfo foramt. Like this: In this case, A should understanding that a FETCH subscription is requested. How about this way to solute your problem? I think there are some problems with this approach. I think that winfo is designed to signal changes in watchers subscription status i.e. signal the state to which a watcher has moved from previous state. In this case, as you said, A should be able to understand that means FETCH. This would mean special casing expiration="0". Otherwise, continuing this we could send Now, should A be able to understand that B's subscription expires in 200 and after that time automatically do something (for example delete B's entry from GUI)? But now if B refreshes his subscription A needs to get new winfo NOTIFY with new expiration timer despite that there has been no change in B's subscription status. We could take an other example. Let's say that B performs FETCH but has no authorization. Should A now get I would say that sending would make more sense. Any comments? Will you attend the coming 10th SIPIT? I think We can discuss about this question and more about SIMPLE face-to-face at that time. I will probably not be able attend this one. regards - Mikko Best regards, Tang Lihua Research Member, Infrastructure Technology IBM China Research Lab. Phone: (8610)62986677-542 Tie line: 905-542 Email: tanglih@cn.ibm.com mikko.lonnfors@nokia.com Sent by: To: simple-admin@mailman.dynam cc: icsoft.com Subject: [Simple] question about winfo-package 2002-03-26 21:56 Please respond to mikko.lonnfors Hi, One question about winfo-package. Lets say that winfo is applied to presence event-package and that user A has subscribed his winfo. Now user B performs FETCH (SUBSCRIBE with expires: 0) on user A's presence information. User B is authorized to subscribe A's presence: First server send winfo NOTIFY to user A then PS sends presence document to user B and immediately after that an other NOTIFY to user A with Should user A receive these two NOTIFY message or can FETCH request be considered expired when it arrives so that only the second winfo NOTIFY would be needed? regards - Mikko _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 27 06:22:59 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22434 for ; Wed, 27 Mar 2002 06:22:59 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2RBHwFA017183; Wed, 27 Mar 2002 06:17:58 -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 GAA09467; Wed, 27 Mar 2002 06:21:05 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09453; Wed, 27 Mar 2002 06:20:10 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RBJUs06485; Wed, 27 Mar 2002 13:19:30 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 13:19:16 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:19:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] question about winfo-package (resend with revision marks) Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0DCAED@esebe004.NOE.Nokia.com> Thread-Topic: [Simple] question about winfo-package Thread-Index: AcHVLthgpsZYzozJT+Gs4L7860OWhgALIFgwAAldreA= To: Cc: , X-OriginalArrivalTime: 27 Mar 2002 11:19:15.0697 (UTC) FILETIME=[3ACB1610:01C1D581] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA09453 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 13:19:15 +0200 Content-Transfer-Encoding: 8bit Sorry for resending this. Original main didn't have any revision marks. Some comments inline inside . -----Original Message----- From: ext Li Hua Tang [mailto:tanglih@cn.ibm.com] Sent: 27 March, 2002 03:29 To: Lonnfors Mikko (NRC/Helsinki) Cc: simple@mailman.dynamicsoft.com; simple-admin@mailman.dynamicsoft.com Subject: Re: [Simple] question about winfo-package Mikko, My opinion about your question is as follows: The motivating application for winfo package is presence authorization. If User B is authorized to subscribe A's presence, as you said, generally speaking the PS doesn't need to notify A of the B's subscription status for authorization. I would still say that winfo is designed to enable presentity to get lists of watchers interested in their presence status. This should happen regardless of the watcher's authorization status. Presence authorization may be the main motivation to enable this functionality but not the only one. If the PS needs to notify A of this FETCH subscription, you may use the 'expiration' attribute of winfo foramt. Like this: In this case, A should understanding that a FETCH subscription is requested. How about this way to solute your problem? I think there are some problems with this approach. I think that winfo is designed to signal changes in watchers subscription status i.e. signal the state to which a watcher has moved from previous state. In this case, as you said, A should be able to understand that means FETCH. This would mean special casing expiration="0". Otherwise, continuing this we could send Now, should A be able to understand that B's subscription expires in 200 and after that time automatically do something (for example delete B's entry from GUI)? But now if B refreshes his subscription A needs to get new winfo NOTIFY with new expiration timer despite that there has been no change in B's subscription status. We could take an other example. Let's say that B performs FETCH but has no authorization. Should A now get I would say that sending would make more sense. Any comments? Will you attend the coming 10th SIPIT? I think We can discuss about this question and more about SIMPLE face-to-face at that time. I will probably not be able attend this one. regards - Mikko Best regards, Tang Lihua Research Member, Infrastructure Technology IBM China Research Lab. Phone: (8610)62986677-542 Tie line: 905-542 Email: tanglih@cn.ibm.com mikko.lonnfors@nokia.com Sent by: To: simple-admin@mailman.dynam cc: icsoft.com Subject: [Simple] question about winfo-package 2002-03-26 21:56 Please respond to mikko.lonnfors Hi, One question about winfo-package. Lets say that winfo is applied to presence event-package and that user A has subscribed his winfo. Now user B performs FETCH (SUBSCRIBE with expires: 0) on user A's presence information. User B is authorized to subscribe A's presence: First server send winfo NOTIFY to user A then PS sends presence document to user B and immediately after that an other NOTIFY to user A with Should user A receive these two NOTIFY message or can FETCH request be considered expired when it arrives so that only the second winfo NOTIFY would be needed? regards - Mikko _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 27 10:15:00 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01846 for ; Wed, 27 Mar 2002 10:14:59 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2RFB2FA018403; Wed, 27 Mar 2002 10:11:02 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10195; Wed, 27 Mar 2002 10:14:09 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10184 for ; Wed, 27 Mar 2002 10:13:09 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RFCSs03557 for ; Wed, 27 Mar 2002 17:12:28 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 17:12:14 +0200 Received: from nokia.com ([172.21.148.60]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 17:12:13 +0200 Message-ID: <3CA1E13D.6090602@nokia.com> From: "Niemi Aki (NET/Espoo)" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020212 X-Accept-Language: en-us MIME-Version: 1.0 To: ext Jonathan Rosenberg CC: simple@mailman.dynamicsoft.com References: <3C96913C.F810071D@cisco.com> <3C96C912.6D26FF18@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2002 15:12:13.0849 (UTC) FILETIME=[C66BD090:01C1D5A1] Subject: [Simple] IM Session Transport Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 17:11:57 +0200 Content-Transfer-Encoding: 7bit Hi All, Based on the discussions at the SIMPLE session at the IETF53 meeting, do we now have consensus that the approaches we're studying for the message transport inside an IM session are in fact: - SIP MESSAGE (with a specific "feature set") - IMSX (draft-mrose-simple-exchange-01.txt) At least this was my impression from the presentations/discussions there. I assume this means that IMTP as such is not considered any more, but an updated version of draft-ietf-simple-im-session-00.txt that addresses the issues Jonathan presented, may instead be expected? Cheers, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 27 12:48:57 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10941 for ; Wed, 27 Mar 2002 12:48:56 -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 g2RHixFA020070; Wed, 27 Mar 2002 12:44:59 -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 MAA10723; Wed, 27 Mar 2002 12:48:05 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10712 for ; Wed, 27 Mar 2002 12:47:48 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2RHlwTE016810; Wed, 27 Mar 2002 12:47:59 -0500 (EST) Message-ID: <3CA2058A.A14C43CD@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: "Niemi Aki (NET/Espoo)" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] IM Session Transport References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 12:46:50 -0500 Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > > Based on the discussions at the SIMPLE session at the IETF53 meeting, > do > > we now have consensus that the approaches we're studying for the > message > > transport inside an IM session are in fact: > > > > - SIP MESSAGE (with a specific "feature set") > > - IMSX (draft-mrose-simple-exchange-01.txt) > > > > At least this was my impression from the presentations/discussions > there. > > > > I assume this means that IMTP as such is not considered any more, but > an > > updated version of draft-ietf-simple-im-session-00.txt that addresses > > the issues Jonathan presented, may instead be expected? > > That is definitely not my impression. I left the meeting feeling that > the rough consensus was to use IMTP as the base solution, with the > possibility of negotiating other transports in SDP as an option (e.g. > IMSX). However, Jonathan promised to update the IMTP draft. I think the difference between what Aki and you are saying is merely pedantic. The basic idea behind my presentation was that, with the new loose routing capabilities of bis, we would no longer need a separate protocol for IM transport. We could use regular SIP, with the MESSAGE method, in a particular usage scenario (pre-loaded routes with all tcp transport, for example). Thus, there would no longer be IMTP as a separate protocol, merely a draft on the usage of the MESSAGE method in this modality. Indeed, I would argue that such a usage description belongs in draft-ietf-simple-im-session. My impression was that there was good consensus on this approach, but we would need to have a concrete proposal to look at. I believe the chairs allocated 4 weeks for the total time to write and submit the draft, and compare it with IMSX. I also recall that there was general agreement that other IM transport could always be negotiated as per the general SIP/SDP capability. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 27 14:04:40 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16596 for ; Wed, 27 Mar 2002 14:04:40 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2RJ0xFA020866; Wed, 27 Mar 2002 14:00:59 -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 OAA11000; Wed, 27 Mar 2002 14:04:05 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10989 for ; Wed, 27 Mar 2002 14:03:00 -0500 (EST) Received: from diamond.cs.columbia.edu (diamond.cs.columbia.edu [128.59.16.9]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA01543 for ; Wed, 27 Mar 2002 14:02:06 -0500 (EST) Received: from diamond.cs.columbia.edu (localhost [127.0.0.1]) by diamond.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2RJ26AT027532 for ; Wed, 27 Mar 2002 14:02:06 -0500 (EST) Received: (from petkos@localhost) by diamond.cs.columbia.edu (8.12.1/8.12.1/Submit) id g2RJ22Tj027530 for simple@mailman.dynamicsoft.com; Wed, 27 Mar 2002 14:02:02 -0500 (EST) From: "Petri K. Koskelainen" Message-Id: <200203271902.g2RJ22Tj027530@diamond.cs.columbia.edu> To: simple@mailman.dynamicsoft.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Requirements to SIMPLE components continuation Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 14:02:02 -0500 (EST) Content-Transfer-Encoding: 7bit Stephen wrote: > Assuming the setup is per a MESSAGE session, with the signalling > channels only setting up the conference session. Clients will > then have a separate media channel for > content MESSAGE's, which could share a common call-id. Do you mean that all MESSAGEs in a conference session share same call-id? This can be done, but then you cannot do message identification. It is impossible to refer to a specific MESSAGE anymore, and I think this is required. (Referring to a conference discussion based on call-id is useful, but you may also want to refer to a specific IM inside a conference, especially when replying). New header (message-id) would solve that problem. It might make sense to create also References header. This would allow that In-Reply-To always refers to a session, while References refers to a specific MESSAGE. BR, -- Petri _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 27 17:37:01 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27989 for ; Wed, 27 Mar 2002 17:37:01 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2RMH0FA022570; Wed, 27 Mar 2002 17:17:01 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11664; Wed, 27 Mar 2002 17:20:06 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11651 for ; Wed, 27 Mar 2002 17:19:34 -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 g2RMIab28448 for ; Wed, 27 Mar 2002 16:18:36 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 16:18:38 -0600 Message-ID: From: "Sriram Parameswar" To: simple@mailman.dynamicsoft.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D5DD.5798E090" Subject: [Simple] (no subject) Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 16:18:37 -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_01C1D5DD.5798E090 Content-Type: text/plain; charset="iso-8859-1" Jonathan wrote: <> I think the difference between what Aki and you are saying is merely pedantic. The basic idea behind my presentation was that, with the new loose routing capabilities of bis, we would no longer need a separate protocol for IM transport. We could use regular SIP, with the MESSAGE method, in a particular usage scenario (pre-loaded routes with all tcp transport, for example). Thus, there would no longer be IMTP as a separate protocol, merely a draft on the usage of the MESSAGE method in this modality. Indeed, I would argue that such a usage description belongs in draft-ietf-simple-im-session. <> Jonathan, "Just a question for clarification" using 3GPP-speak. When you say we will use loose routing and full blown SIP (as opposed to a limited header set defined in IMTP), are you implying that the MESSAGE will now follow the exact same route as the signaling? Also are the other SIP headers applicable to MESSAGE now going to be allowed in IM sessions? Thanks, Sriram ------_=_NextPart_001_01C1D5DD.5798E090 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Jonathan wrote:
<<quote>>
I think the difference between what = Aki and you are saying is merely pedantic. The basic idea behind my = presentation was that, with the new loose routing capabilities of bis, = we would no longer need a separate protocol for IM transport. We could = use regular SIP, with the MESSAGE method, in a particular usage = scenario (pre-loaded routes with all tcp transport, for example). Thus, = there would no longer be IMTP as a separate protocol, merely a draft on = the usage of the MESSAGE method in this modality. Indeed, I would argue = that such a usage description belongs in draft-ietf-simple-im-session. =

<<endquote>>

Jonathan,

"Just a question for = clarification" using 3GPP-speak. When you say we will use loose = routing and full blown SIP (as opposed to a limited header set defined = in IMTP), are you implying that the MESSAGE will now follow the exact = same route as the signaling? Also are the other SIP headers applicable = to MESSAGE now going to be allowed in IM sessions?

Thanks,

Sriram


------_=_NextPart_001_01C1D5DD.5798E090-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 27 18:29:13 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29389 for ; Wed, 27 Mar 2002 18:29:13 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2RNNvFA023019; Wed, 27 Mar 2002 18:23:57 -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 SAA11892; Wed, 27 Mar 2002 18:27:07 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10431 for ; Wed, 27 Mar 2002 11:25:28 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 27 Mar 2002 08:24:32 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Mar 2002 08:24:33 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 27 Mar 2002 08:24:31 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 27 Mar 2002 08:24:24 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Wed, 27 Mar 2002 08:21:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] IM Session Transport Message-ID: Thread-Topic: [Simple] IM Session Transport thread-index: AcHVpQRz/l8A+1j2QKup7fCwakKfIAABo3wQ From: "Christian Huitema" To: "Niemi Aki (NET/Espoo)" , "ext Jonathan Rosenberg" Cc: X-OriginalArrivalTime: 27 Mar 2002 16:21:17.0780 (UTC) FILETIME=[6C658140:01C1D5AB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA10431 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 08:21:17 -0800 Content-Transfer-Encoding: 8bit > Based on the discussions at the SIMPLE session at the IETF53 meeting, do > we now have consensus that the approaches we're studying for the message > transport inside an IM session are in fact: > > - SIP MESSAGE (with a specific "feature set") > - IMSX (draft-mrose-simple-exchange-01.txt) > > At least this was my impression from the presentations/discussions there. > > I assume this means that IMTP as such is not considered any more, but an > updated version of draft-ietf-simple-im-session-00.txt that addresses > the issues Jonathan presented, may instead be expected? That is definitely not my impression. I left the meeting feeling that the rough consensus was to use IMTP as the base solution, with the possibility of negotiating other transports in SDP as an option (e.g. IMSX). However, Jonathan promised to update the IMTP draft. -- Christian Huitema _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 27 19:01:41 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00175 for ; Wed, 27 Mar 2002 19:01:41 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2RNruFA023218; Wed, 27 Mar 2002 18:53:56 -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 SAA12014; Wed, 27 Mar 2002 18:57:05 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12002 for ; Wed, 27 Mar 2002 18:56:17 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2RNtgi15030; Wed, 27 Mar 2002 18:55:43 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAH48830; Wed, 27 Mar 2002 18:58:36 -0500 (EST) Message-ID: <3CA25BE7.53DE97BA@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: "Niemi Aki (NET/Espoo)" , ext Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] IM Session Transport References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 18:55:19 -0500 Content-Transfer-Encoding: 7bit My impression is consistent with what Jonathon posted - namely that IMTP should go away, to be replaced with a restricted profile of SIP. I thought there was general agreement of the room on that, though I don't recall if there was a humm. Paul Christian Huitema wrote: > > > Based on the discussions at the SIMPLE session at the IETF53 meeting, > do > > we now have consensus that the approaches we're studying for the > message > > transport inside an IM session are in fact: > > > > - SIP MESSAGE (with a specific "feature set") > > - IMSX (draft-mrose-simple-exchange-01.txt) > > > > At least this was my impression from the presentations/discussions > there. > > > > I assume this means that IMTP as such is not considered any more, but > an > > updated version of draft-ietf-simple-im-session-00.txt that addresses > > the issues Jonathan presented, may instead be expected? > > That is definitely not my impression. I left the meeting feeling that > the rough consensus was to use IMTP as the base solution, with the > possibility of negotiating other transports in SDP as an option (e.g. > IMSX). However, Jonathan promised to update the IMTP draft. > > -- Christian Huitema > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Mar 27 22:19:25 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04139 for ; Wed, 27 Mar 2002 22:19:25 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2S3F4FA024149; Wed, 27 Mar 2002 22:15:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12635; Wed, 27 Mar 2002 22:18:05 -0500 (EST) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12624 for ; Wed, 27 Mar 2002 22:17:29 -0500 (EST) Received: from maillennium.att.com ([135.25.114.99]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g2S3GY105105 for ; Wed, 27 Mar 2002 21:16:34 -0600 (CST) Received: from att.com ([135.210.112.72]) by maillennium.att.com (mailgw1) with SMTP id <20020328031634gw1001rp9pe> (Authid: tony); Thu, 28 Mar 2002 03:16:34 +0000 Message-ID: <3CA28B04.F5F647FA@att.com> From: Tony Hansen X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Subject: Re: [Simple] IM Session Transport References: <3CA25BE7.53DE97BA@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 22:16:20 -0500 Content-Transfer-Encoding: 7bit My notes say: IMTP was to be replaced by a profile of SIP after 4 weeks, both the IMTP replacement and IMSX would then be compared on their advantages and disadvantages Yes, it was noted that more than one session mechanism could be defined. But that was not used as a justification to make a decision for either mechanism that day. Tony Hansen tony@att.com Paul Kyzivat wrote: > > My impression is consistent with what Jonathon posted - namely that > IMTP should go away, to be replaced with a restricted profile of SIP. > I thought there was general > agreement of the room on that, though I don't recall if there was a humm. > > Paul > > Christian Huitema wrote: > > > > > Based on the discussions at the SIMPLE session at the IETF53 meeting, > > do > > > we now have consensus that the approaches we're studying for the > > message > > > transport inside an IM session are in fact: > > > > > > - SIP MESSAGE (with a specific "feature set") > > > - IMSX (draft-mrose-simple-exchange-01.txt) > > > > > > At least this was my impression from the presentations/discussions > > there. > > > > > > I assume this means that IMTP as such is not considered any more, but > > an > > > updated version of draft-ietf-simple-im-session-00.txt that addresses > > > the issues Jonathan presented, may instead be expected? > > > > That is definitely not my impression. I left the meeting feeling that > > the rough consensus was to use IMTP as the base solution, with the > > possibility of negotiating other transports in SDP as an option (e.g. > > IMSX). However, Jonathan promised to update the IMTP draft. > > > > -- Christian Huitema _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 28 10:16:55 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29982 for ; Thu, 28 Mar 2002 10:16:54 -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 g2SFA5FA026710; Thu, 28 Mar 2002 10:10:05 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14844; Thu, 28 Mar 2002 10:13:05 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14833 for ; Thu, 28 Mar 2002 10:12:51 -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 g2SFBsk16348; Thu, 28 Mar 2002 09:11:54 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 09:11:59 -0600 Message-ID: From: "Sriram Parameswar" To: "'simple@mailman.dynamicsoft.com'" Cc: "'jdrosen@dynamicsoft.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D66A.E6E2DF70" Subject: [Simple] IM Session Transport **Resend with subject** Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 28 Mar 2002 09:11:57 -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_01C1D66A.E6E2DF70 Content-Type: text/plain; charset="iso-8859-1" *** Resend with proper Subject*** > Jonathan wrote: > <> > I think the difference between what Aki and you are saying is merely > pedantic. The basic idea behind my presentation was that, with the new > loose routing capabilities of bis, we would no longer need a separate > protocol for IM transport. We could use regular SIP, with the MESSAGE > method, in a particular usage scenario (pre-loaded routes with all tcp > transport, for example). Thus, there would no longer be IMTP as a separate > protocol, merely a draft on the usage of the MESSAGE method in this > modality. Indeed, I would argue that such a usage description belongs in > draft-ietf-simple-im-session. > <> > > Jonathan, > > "Just a question for clarification" using 3GPP-speak. When you say we will > use loose routing and full blown SIP (as opposed to a limited header set > defined in IMTP), are you implying that the MESSAGE will now follow the > exact same route as the signaling? Also are the other SIP headers > applicable to MESSAGE now going to be allowed in IM sessions? > > Thanks, > > Sriram > > ------_=_NextPart_001_01C1D66A.E6E2DF70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IM Session Transport **Resend with subject**

*** Resend with  proper Subject***

Jonathan wrote:
<<quote>>
I think the difference between what = Aki and you are saying is merely pedantic. The basic idea behind my = presentation was that, with the new loose routing capabilities of bis, = we would no longer need a separate protocol for IM transport. We could = use regular SIP, with the MESSAGE method, in a particular usage = scenario (pre-loaded routes with all tcp transport, for example). Thus, = there would no longer be IMTP as a separate protocol, merely a draft on = the usage of the MESSAGE method in this modality. Indeed, I would argue = that such a usage description belongs in draft-ietf-simple-im-session. =

<<endquote>>

Jonathan,

"Just a question for = clarification" using 3GPP-speak. When you say we will use loose = routing and full blown SIP (as opposed to a limited header set defined = in IMTP), are you implying that the MESSAGE will now follow the exact = same route as the signaling? Also are the other SIP headers applicable = to MESSAGE now going to be allowed in IM sessions?

Thanks,

Sriram


------_=_NextPart_001_01C1D66A.E6E2DF70-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Mar 28 17:34:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18291 for ; Thu, 28 Mar 2002 17:34:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2SMQGFA001271; Thu, 28 Mar 2002 17:26:16 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16241; Thu, 28 Mar 2002 17:29:06 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16229 for ; Thu, 28 Mar 2002 17:28:40 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2SMSnTE019322; Thu, 28 Mar 2002 17:28:49 -0500 (EST) Message-ID: <3CA398DB.1D7D3CAB@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sriram Parameswar CC: "'simple@mailman.dynamicsoft.com'" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] Re: IM Session Transport **Resend with subject** Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 28 Mar 2002 17:27:39 -0500 Content-Transfer-Encoding: 7bit Sriram Parameswar wrote: > > *** Resend with proper Subject*** > > Jonathan wrote: > <> > I think the difference between what Aki and you are saying is merely > pedantic. The basic idea behind my presentation was that, with the new > loose routing capabilities of bis, we would no longer need a separate > protocol for IM transport. We could use regular SIP, with the MESSAGE > method, in a particular usage scenario (pre-loaded routes with all tcp > transport, for example). Thus, there would no longer be IMTP as a > separate protocol, merely a draft on the usage of the MESSAGE method in > this modality. Indeed, I would argue that such a usage description > belongs in draft-ietf-simple-im-session. > > <> > > Jonathan, > > "Just a question for clarification" using 3GPP-speak. When you say we > will use loose routing and full blown SIP (as opposed to a limited > header set defined in IMTP), are you implying that the MESSAGE will now > follow the exact same route as the signaling? No. It can follow a different route. > Also are the other SIP > headers applicable to MESSAGE now going to be allowed in IM sessions? Well, I would think that pretty much everything allowed in page mode should also work for the session usage. In addition, since a context is established, things like CSeq can be used to establish order. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple