From simple-admin@mailman.dynamicsoft.com Fri Nov 1 01:59: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 BAA00454 for ; Fri, 1 Nov 2002 01:59: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 gA170Psu019300; Fri, 1 Nov 2002 02:00: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 CAA17765; Fri, 1 Nov 2002 02:01:08 -0500 (EST) Received: from mta0 ([61.144.161.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17753 for ; Fri, 1 Nov 2002 02:00:09 -0500 (EST) Received: from D70286 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H4V001OFY136Y@mta0.huawei.com> for simple@mailman.dynamicsoft.com; Fri, 01 Nov 2002 14:58:16 +0800 (CST) From: Deepankar To: simple@mailman.dynamicsoft.com Message-id: <007201c28174$417807d0$ac064d0a@D70286> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_a9vvxkheUlOa3fgJMBRtNA)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Simple] Interdomain 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: Fri, 01 Nov 2002 14:59:42 +0800 This is a multi-part message in MIME format. --Boundary_(ID_a9vvxkheUlOa3fgJMBRtNA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Folks, In case of a softswitch based presence solution, If the PA is co-located with the Proxy/Registrar with the Softswitch, then what mechanisms are there for it, to know of the presence of users homed in a different Softswitch. Deeps --Boundary_(ID_a9vvxkheUlOa3fgJMBRtNA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Folks,
 
In case of a softswitch based presence solution, If the PA is co-located with the Proxy/Registrar with the Softswitch, then what mechanisms are there for it, to know of the presence of users homed in a different Softswitch.
 
Deeps
--Boundary_(ID_a9vvxkheUlOa3fgJMBRtNA)-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 1 05:04: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 FAA02549 for ; Fri, 1 Nov 2002 05:04: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 gA1A58su020999 for ; Fri, 1 Nov 2002 05:05: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 FAA20243 for ; Fri, 1 Nov 2002 05:06:04 -0500 (EST) Date: Fri, 1 Nov 2002 05:06:04 -0500 (EST) Message-Id: <200211011006.FAA20243@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 Sat Nov 2 08:07: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 IAA04235 for ; Sat, 2 Nov 2002 08:07: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 gA2D8bsu026434; Sat, 2 Nov 2002 08:08:37 -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 IAA26621; Sat, 2 Nov 2002 08:09:04 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26610 for ; Sat, 2 Nov 2002 08:08:26 -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 gA2D7wO12415 for ; Sat, 2 Nov 2002 15:08:02 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 2 Nov 2002 15:08:22 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 2 Nov 2002 15:08:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD19@esebe004.ntc.nokia.com> Thread-Topic: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt Thread-Index: AcJ/XXBzy3S2SSvqRVSFa8QkW/NGiAAmZrYg To: , X-OriginalArrivalTime: 02 Nov 2002 13:08:21.0928 (UTC) FILETIME=[EB87AA80:01C28270] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA26610 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, 2 Nov 2002 15:08:20 +0200 Content-Transfer-Encoding: 8bit Hi, inline > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 29 October, 2002 17:06 > To: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] FW: I-D > ACTION:draft-lonnfors-simple-prescaps-ext-00.txt > > > mikko.lonnfors@nokia.com wrote: > > > > Hi, > > > > New draft is now available. Basically draft presents a > solution for the requirements presented in > draft-kyzivat-simple-prescaps-reqts-00.txt. > > All comments are welcome. > > Obviously Mikko and I have been cooperating on this. We were > both interested in the subject. I thought it would be helpful > to be clear about the requirements rather than jumping > directly to a proposed solution, so I posted a requirements > draft last week. Since then I have been waiting for Mikko to > submit this in order to have more fodder for discussion. > > There is already a work item to produce a SIP-specific > profile for PIDF. I consider these drafts to be a *partial* > response to that work item. I realize there is a desire for > some addition generalized status values beyond open/closed, > such as busy. That is a minefield, and we have chosen not to > address it. Instead, we are focusing on some attributes that > should be less controversial because they are drawn from the > callerprefs draft, whose basic concepts have been accepted > for a long time. (I am open to discussion about whether these > specific drafts should be expanded to cover the more general > requirement, or whether that should be left separate.) > The assertion of these drafts is that capabilities a UAS can > specify when registering are information that is equally > important in a presence document. I believe Mikko is most > concerned with supported media. I also consider that to be of > major importance, but I also believe all the others are of > potential value in a presence document. This topic was first discussed in IMPP mailing list related to PIDF communication means. After some discussion it was concluded that this work might fit better to SIMPLE WG agenda. I would also like to see some comments to the requirements draft. A small problem in writing that was that there were no requirements for callerpreferences and because of that we have tried to put quite a lot motivational and explanative text into requirements. It would be very helpful to hear also other people comments to this. If the overall idea is acceptable then the exact requirements should be quite clear. At least requirements 1, 2, and 3 should be quite self-evident (I hope). Requirement 4 is now marked with SHOULD level and I would like to hear if it would be good idea to move it to MUST level. Also I am not sure we have been able to collect all relevant requirements so if something seems to be missing please let us know. > The callerprefs draft is still itself in a state of flux. The > work here should remain dependent on the outcome of that > work. But I believe it would be helpful to begin progressing > these documents now. We have tried to keep this draft as independent of callerprefs as possible but there is of course quite heavy dependency between these two. Here are some open items for solution draft: - At a moment draft allows use of extension in two places inside PIDF document (inside and . Should we specify the exact location where this extension can be used within PIDF document. - We went through 2 or 3 different XML schemas before ending up with current one. Obviously there is lot of different options and if someone thinks there exists better alternatives then this can be discussed. - We ended up using negated attribute inside elements to indicate whether value is supporter or not supported. There are also other alternatives to represent this. One alternative would be to replace with either or element. - Mikko > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Nov 2 16:32: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 QAA12786 for ; Sat, 2 Nov 2002 16:32:27 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gA2LXEsu027160; Sat, 2 Nov 2002 16:33: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 QAA28107; Sat, 2 Nov 2002 16:34:07 -0500 (EST) Received: from IPOfCard1.guest-tek.com ([141.154.107.194]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28086 for ; Sat, 2 Nov 2002 16:33:35 -0500 (EST) Received: from dynamicsoft.com ([141.154.107.210]) by IPOfCard1.guest-tek.com (8.11.6/8.8.7) with ESMTP id gA2LW9r13239; Sat, 2 Nov 2002 16:32:10 -0500 Message-ID: <3DC4057B.1060901@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Deepankar CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Interdomain presence References: <007201c28174$417807d0$ac064d0a@D70286> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sat, 02 Nov 2002 12:03:55 -0500 Content-Transfer-Encoding: 7bit A PUA can publish presence to any PA using the SIP PUBLISH method. You can find the current I-D for this at: http://www.ietf.org/internet-drafts/draft-olson-simple-publish-01.txt whether you call the PA a softswitch or not is irrelevant. -Jonathan R. Deepankar wrote: > Folks, > > In case of a softswitch based presence solution, If the PA is co-located > with the Proxy/Registrar with the Softswitch, then what mechanisms are > there for it, to know of the presence of users homed in a different > Softswitch. > > Deeps -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Nov 2 16:33: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 QAA12827 for ; Sat, 2 Nov 2002 16:33: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 gA2LYdsu027199; Sat, 2 Nov 2002 16:34: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 QAA28128; Sat, 2 Nov 2002 16:35:38 -0500 (EST) Received: from IPOfCard1.guest-tek.com ([141.154.107.194]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28096 for ; Sat, 2 Nov 2002 16:33:50 -0500 (EST) Received: from dynamicsoft.com ([141.154.107.210]) by IPOfCard1.guest-tek.com (8.11.6/8.8.7) with ESMTP id gA2LWPr13321; Sat, 2 Nov 2002 16:32:25 -0500 Message-ID: <3DC41F3C.1010301@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sat, 02 Nov 2002 13:53:48 -0500 Content-Transfer-Encoding: 7bit Cant we solve this at the cpim-msg-sessions layer? That draft could simply say something like "when you go to connect to the IP address/port that is listed there, first check if you already have a connection there. If so, use that again, and ignore any comedia stuff in the SDP." -Jonathan R. Paul Kyzivat wrote: > Draft-campbell-simple-cpimmsg-sessions-00 defines the protocol in such a way that multiple sessions can be demultiplexed from a single connection. Meanwhile draft-campbell-simple-im-sessions-00 calls for the use of the comedia spec to establish the connections. It also wishes to reuse a single connection for multiple sessions. > > This presents a problem, because the comedia draft (ietf-mmusic-sdp-comedia-04) does not provide a way to share a connection among multiple sessions. It was constrained from doing so because it made no assumption about the protocol to be used on the connection. As a result it had to come up with a way to associate connections with sessions without regard to media content. > > Either a way must be found to change comedia to provide this capability, or else comedia must be abandoned in favor of some other arrangement for negotiating a connection. (It would be nice to make comedia work for this.) > > Rohan and I talked about this, and began to think we could find an enhancement to comedia that would permit this, but then it got very ugly trying to figure out when connections should go away, especially between a pair of intermediaries. This is going to require some work. > > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Nov 2 16: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 QAA12840 for ; Sat, 2 Nov 2002 16: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 gA2LYusu027221; Sat, 2 Nov 2002 16:34: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 QAA28144; Sat, 2 Nov 2002 16:35:55 -0500 (EST) Received: from IPOfCard1.guest-tek.com ([141.154.107.194]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28091 for ; Sat, 2 Nov 2002 16:33:50 -0500 (EST) Received: from dynamicsoft.com ([141.154.107.210]) by IPOfCard1.guest-tek.com (8.11.6/8.8.7) with ESMTP id gA2LWOr13316; Sat, 2 Nov 2002 16:32:24 -0500 Message-ID: <3DC41E11.5090306@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Paul Kyzivat , Simple Subject: Re: [Simple] Message Session IDs References: <3DBEFB35.1040908@dynamicsoft.com> <3DBF311F.B8AC9254@cisco.com> <3DBF43E4.4050107@dynamicsoft.com> <3DBF6051.6020502@dynamicsoft.com> <3DBFE7D9.CE57E118@cisco.com> <3DBFEF54.1020907@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sat, 02 Nov 2002 13:48:49 -0500 Content-Transfer-Encoding: 7bit Agreed that msgID belongs inside the envelope. The issue, then, is what MIME header are we using in the outer envelope that would be used by the intermediary for routing? Is there an existing one that fits the job... suggestions anyone? -Jonathan R. Ben Campbell wrote: > Paul Kyzivat wrote: > >> >> Ben Campbell wrote: > > > [...] > >> >>> If we were to do this, does it also make sense to move MsgID to the >>> outer envelope? >> >> >> >> I don't know about this. If it is only needed by the endpoints then it >> might as well be in the inner envelope. Protecting it should help >> protect against some kinds of attacks. >> > > On reflection, I agree with you. I had it in my head that an > intermediary might use it for ordering purposes, but now that I am more > awake I realize there is no need for that. > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Nov 3 10:33: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 KAA08493 for ; Sun, 3 Nov 2002 10:33: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 gA3FYEsu028534; Sun, 3 Nov 2002 10:34: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 KAA01280; Sun, 3 Nov 2002 10:35:05 -0500 (EST) Received: from mta2 ([61.144.161.16]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01267 for ; Sun, 3 Nov 2002 10:34:14 -0500 (EST) Received: from mta2 (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0H5000HNDB9T6V@mta2.huawei.com> for simple@mailman.dynamicsoft.com; Sun, 03 Nov 2002 23:34:42 +0800 (CST) Received: from huawei.com ([172.17.1.59]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0H5000HGJB9TI1@mta2.huawei.com> for simple@mailman.dynamicsoft.com; Sun, 03 Nov 2002 23:34:41 +0800 (CST) Received: from [211.161.63.60] by mailb.huawei.com (mshttpd); Sun, 03 Nov 2002 07:33:29 -0800 From: deepankarb 70286 Subject: Re: [Simple] Interdomain presence To: Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com Message-id: <4b9f94bb39.4bb394b9f9@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 0.7 (built Jun 26 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: 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: Sun, 03 Nov 2002 07:33:29 -0800 Content-Transfer-Encoding: 7BIT Yes, thats correct, but I would try to put my query this way. say if my PA aka softswitch is responsible for abc.com administrative domain, and there's another PA taking care of xyz.com administrative domain. Both have their set of homing subscribers (PUAs). Here, I am taking PUAs as fixed IP phones, PSTN phones. Since both belong to different administrative domains, and in case of an example of presence based voice calling, a sip caller sip:acaller@abc.com is calling sip:acallee@xyz.com, and abc.com needs to find the presence first, and then route the call. In this case, how would xyz.com indicate the presence status/document of acallee to abc.com? Deeps ----- Original Message ----- From: Jonathan Rosenberg Date: Saturday, November 2, 2002 9:03 am Subject: Re: [Simple] Interdomain presence > A PUA can publish presence to any PA using the SIP PUBLISH method. > You > can find the current I-D for this at: > http://www.ietf.org/internet-drafts/draft-olson-simple-publish-01.txt > > whether you call the PA a softswitch or not is irrelevant. > > -Jonathan R. > > Deepankar wrote: > > Folks, > > > > In case of a softswitch based presence solution, If the PA is co- > located > > with the Proxy/Registrar with the Softswitch, then what > mechanisms are > > there for it, to know of the presence of users homed in a > different > > Softswitch. > > > > Deeps > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Nov 3 11:28: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 LAA09812 for ; Sun, 3 Nov 2002 11:28: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 gA3GT3su028648; Sun, 3 Nov 2002 11:29: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 LAA01453; Sun, 3 Nov 2002 11:30:03 -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 LAA01440 for ; Sun, 3 Nov 2002 11:29:45 -0500 (EST) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gA3GTFU1081249; Sun, 3 Nov 2002 10:29:16 -0600 (CST) Message-ID: <3DC54ECF.4040507@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sun, 03 Nov 2002 10:29:03 -0600 Content-Transfer-Encoding: 7bit I agree we should do that, and avoid a dependency on getting the issue fixed in comedia. It does, however, seem like a generalized issue that _should_ be handled in the comedia specification as well, but that does not seem to be in scope for this wg. Jonathan Rosenberg wrote: > Cant we solve this at the cpim-msg-sessions layer? > > That draft could simply say something like "when you go to connect to > the IP address/port that is listed there, first check if you already > have a connection there. If so, use that again, and ignore any comedia > stuff in the SDP." > > -Jonathan R. > > Paul Kyzivat wrote: > >> Draft-campbell-simple-cpimmsg-sessions-00 defines the protocol in such >> a way that multiple sessions can be demultiplexed from a single >> connection. Meanwhile draft-campbell-simple-im-sessions-00 calls for >> the use of the comedia spec to establish the connections. It also >> wishes to reuse a single connection for multiple sessions. >> >> This presents a problem, because the comedia draft >> (ietf-mmusic-sdp-comedia-04) does not provide a way to share a >> connection among multiple sessions. It was constrained from doing so >> because it made no assumption about the protocol to be used on the >> connection. As a result it had to come up with a way to associate >> connections with sessions without regard to media content. >> Either a way must be found to change comedia to provide this >> capability, or else comedia must be abandoned in favor of some other >> arrangement for negotiating a connection. (It would be nice to make >> comedia work for this.) >> >> Rohan and I talked about this, and began to think we could find an >> enhancement to comedia that would permit this, but then it got very >> ugly trying to figure out when connections should go away, especially >> between a pair of intermediaries. This is going to require some work. >> >> Paul >> _______________________________________________ >> simple mailing list >> simple@mailman.dynamicsoft.com >> http://mailman.dynamicsoft.com/mailman/listinfo/simple >> > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Nov 3 22:04: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 WAA20372 for ; Sun, 3 Nov 2002 22:04: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 gA4358su029442; Sun, 3 Nov 2002 22:05: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 WAA03419; Sun, 3 Nov 2002 22:06:03 -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 WAA03408 for ; Sun, 3 Nov 2002 22:05:48 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gA435XYH023593; Sun, 3 Nov 2002 22:05:37 -0500 (EST) Message-ID: <3DC5E3FD.7030506@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: deepankarb 70286 CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Interdomain presence References: <4b9f94bb39.4bb394b9f9@huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sun, 03 Nov 2002 22:05:33 -0500 Content-Transfer-Encoding: 7bit deepankarb 70286 wrote: > Yes, thats correct, but I would try to put my query this way. > > say if my PA aka softswitch is responsible for abc.com administrative > domain, and there's another PA taking care of xyz.com administrative > domain. Both have their set of homing subscribers (PUAs). Here, I am > taking PUAs as fixed IP phones, PSTN phones. Since both belong to > different administrative domains, and in case of an example of > presence based voice calling, a sip caller sip:acaller@abc.com is > calling sip:acallee@xyz.com, and abc.com needs to find the presence > first, and then route the call. In this case, how would xyz.com > indicate the presence status/document of acallee to abc.com? Thats what draft-ietf-simple-presence is for. The abc.com would SUBSCRIBE to the presence state at xyz.com. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 4 01:04: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 BAA23907 for ; Mon, 4 Nov 2002 01:04: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 gA4658su029802; Mon, 4 Nov 2002 01:05: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 BAA03964; Mon, 4 Nov 2002 01:06:03 -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 BAA03952 for ; Mon, 4 Nov 2002 01:05:20 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA4654xF000620; Sun, 3 Nov 2002 22:05:04 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABF97048; Sun, 3 Nov 2002 22:02:44 -0800 (PST) Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Jonathan Rosenberg , Paul Kyzivat , Simple To: Ben Campbell From: Rohan Mahy In-Reply-To: <3DC54ECF.4040507@dynamicsoft.com> Message-Id: <5FAFE972-EFBB-11D6-ACCB-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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, 3 Nov 2002 22:05:09 -0800 Content-Transfer-Encoding: 7bit Ben, I think the right question to ask is: how do a pair of intermediaries decide when they can terminate a connection? this could be reference counting, or idle timeouts, or something else, but I think a lot of stuff will fall out from that decision. thanks, -rohan On Sunday, November 3, 2002, at 08:29 AM, Ben Campbell wrote: > I agree we should do that, and avoid a dependency on getting the issue > fixed in comedia. > > It does, however, seem like a generalized issue that _should_ be > handled in the comedia specification as well, but that does not seem > to be in scope for this wg. > > Jonathan Rosenberg wrote: >> Cant we solve this at the cpim-msg-sessions layer? >> That draft could simply say something like "when you go to connect to >> the IP address/port that is listed there, first check if you already >> have a connection there. If so, use that again, and ignore any >> comedia stuff in the SDP." >> -Jonathan R. >> Paul Kyzivat wrote: >>> Draft-campbell-simple-cpimmsg-sessions-00 defines the protocol in >>> such a way that multiple sessions can be demultiplexed from a single >>> connection. Meanwhile draft-campbell-simple-im-sessions-00 calls for >>> the use of the comedia spec to establish the connections. It also >>> wishes to reuse a single connection for multiple sessions. >>> >>> This presents a problem, because the comedia draft >>> (ietf-mmusic-sdp-comedia-04) does not provide a way to share a >>> connection among multiple sessions. It was constrained from doing so >>> because it made no assumption about the protocol to be used on the >>> connection. As a result it had to come up with a way to associate >>> connections with sessions without regard to media content. >>> Either a way must be found to change comedia to provide this >>> capability, or else comedia must be abandoned in favor of some other >>> arrangement for negotiating a connection. (It would be nice to make >>> comedia work for this.) >>> >>> Rohan and I talked about this, and began to think we could find an >>> enhancement to comedia that would permit this, but then it got very >>> ugly trying to figure out when connections should go away, >>> especially between a pair of intermediaries. This is going to >>> require some work. >>> >>> Paul >>> _______________________________________________ >>> simple mailing list >>> simple@mailman.dynamicsoft.com >>> http://mailman.dynamicsoft.com/mailman/listinfo/simple >>> > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 4 03:10: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 DAA05817 for ; Mon, 4 Nov 2002 03: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 gA48B7su000104; Mon, 4 Nov 2002 03:11: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 DAA04327; Mon, 4 Nov 2002 03:12:03 -0500 (EST) Received: from mta2 ([61.144.161.16]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04316 for ; Mon, 4 Nov 2002 03:11:52 -0500 (EST) Received: from mta2 (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0H5100MEGLGMJT@mta2.huawei.com> for simple@mailman.dynamicsoft.com; Mon, 04 Nov 2002 16:12:22 +0800 (CST) Received: from huawei.com ([172.17.1.59]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0H5100H3BLGMI1@mta2.huawei.com> for simple@mailman.dynamicsoft.com; Mon, 04 Nov 2002 16:12:22 +0800 (CST) Received: from [211.161.63.60] by mailb.huawei.com (mshttpd); Mon, 04 Nov 2002 00:11:10 -0800 From: deepankarb 70286 Subject: Re: [Simple] Interdomain presence To: Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com Message-id: <54bbc5284b.5284b54bbc@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 0.7 (built Jun 26 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: 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: Mon, 04 Nov 2002 00:11:10 -0800 Content-Transfer-Encoding: 7BIT Bingo ! But, would'nt it increase the call setup time ? ----- Original Message ----- From: Jonathan Rosenberg Date: Sunday, November 3, 2002 7:05 pm Subject: Re: [Simple] Interdomain presence > > > deepankarb 70286 wrote: > > Yes, thats correct, but I would try to put my query this way. > > > > say if my PA aka softswitch is responsible for abc.com > administrative > domain, and there's another PA taking care of > xyz.com administrative > > domain. Both have their set of homing subscribers (PUAs). Here, > I am > > taking PUAs as fixed IP phones, PSTN phones. Since both belong to > > different administrative domains, and in case of an example of > > presence based voice calling, a sip caller sip:acaller@abc.com is > > calling sip:acallee@xyz.com, and abc.com needs to find the presence > > first, and then route the call. In this case, how would xyz.com > > indicate the presence status/document of acallee to abc.com? > > Thats what draft-ietf-simple-presence is for. The abc.com would > SUBSCRIBE to the presence state at xyz.com. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 4 09:18: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 JAA13942 for ; Mon, 4 Nov 2002 09:18: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 gA4EJCcD001058; Mon, 4 Nov 2002 09:19: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 JAA01206; Mon, 4 Nov 2002 09: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 JAA01193 for ; Mon, 4 Nov 2002 09:19:27 -0500 (EST) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gA4EJMU1070316; Mon, 4 Nov 2002 08:19:23 -0600 (CST) Message-ID: <3DC681DD.3040905@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: deepankarb 70286 CC: Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Interdomain presence References: <54bbc5284b.5284b54bbc@huawei.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 04 Nov 2002 08:19:09 -0600 Content-Transfer-Encoding: 7bit Certainly it will, if you need it for call routing and you don't have it prior to call setup. If you cannot have a delay in call setup, you must subscribe to the information in advance. But submit that the application you describe is very much a classic SIP application, and does not gain much from a presence subscription. Abc.com does not need to subscribe to presence information, unless abc.com (or the user) expects to be notified of a presence change and take some action as a result of that change. In your example, why would you not simply have abc.com proxy the call to xyz.com, then let xyz.com route the call based on the registered contacts? What routing decision is abc.com making based on presence? deepankarb 70286 wrote: > Bingo ! But, would'nt it increase the call setup time ? > > > ----- Original Message ----- > From: Jonathan Rosenberg > Date: Sunday, November 3, 2002 7:05 pm > Subject: Re: [Simple] Interdomain presence > > >> >>deepankarb 70286 wrote: >> >>>Yes, thats correct, but I would try to put my query this way. >>> >>>say if my PA aka softswitch is responsible for abc.com >> >>administrative > domain, and there's another PA taking care of >>xyz.com administrative >> >>>domain. Both have their set of homing subscribers (PUAs). Here, >> >>I am >> >>>taking PUAs as fixed IP phones, PSTN phones. Since both belong to >>>different administrative domains, and in case of an example of >>>presence based voice calling, a sip caller sip:acaller@abc.com is >>>calling sip:acallee@xyz.com, and abc.com needs to find the presence >>>first, and then route the call. In this case, how would xyz.com >>>indicate the presence status/document of acallee to abc.com? >> >>Thats what draft-ietf-simple-presence is for. The abc.com would >>SUBSCRIBE to the presence state at xyz.com. >> >>-Jonathan R. >> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>simple mailing list >>simple@mailman.dynamicsoft.com >>http://mailman.dynamicsoft.com/mailman/listinfo/simple >> > > > _______________________________________________ > 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 Nov 4 14:48:30 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 OAA02682 for ; Mon, 4 Nov 2002 14:48:30 -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 gA4JnIcD002862; Mon, 4 Nov 2002 14:49: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 OAA02183; Mon, 4 Nov 2002 14:50: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 LAA01578 for ; Mon, 4 Nov 2002 11:03:34 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA4G3ja8001045; Mon, 4 Nov 2002 11:03:45 -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 AAU14201; Mon, 4 Nov 2002 11:08:21 -0500 (EST) Message-ID: <3DC69A4F.245BB284@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: Jonathan Rosenberg , Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@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: Mon, 04 Nov 2002 11:03:27 -0500 Content-Transfer-Encoding: 7bit Jonathan, Ben, I would be pleased if we can find a way to finesse this. The problem is that comedia requires some way to infer, from the sip signaling and SDP content, when connections should be made/dropped. Both sides must make the same inference, or else the connection establishment will fail. As soon as we start to pool connections there starts to be the potential for race conditions. This is especially a problem with connections between two intermediaries. The hard question is: when can you ever drop a connection between two intermediaries? Of course an intermediary never knows if its peer in the connection is also an intermediary or not, so it must act as if the peer is a UA following the comedia spec plus whatever additional rules we can come up with for simple. We can't drop a connection until we know that there are no sessions using it. A corollary to that is that we can't reuse a connection that has no sessions using it, because it might be dropped. And so we should drop a connection as soon as there are no sessions using it, because it is then worthless. That already starts looking suboptimal, because we must drop connections between pairs of high traffic intermediaries any time there doesn't happen to be some session traversing them. But I'm not sure this is workable even with that limitation. I have a hunch there is still a race condition when one end will think there is a connection and attempt to reuse it, while the other end has decided there is no session using the connection and tries to drop it or establish a new one. This is tricky, and probably impossible to decide in general except with respect to a precise rule for reuse. But here is one case that seems simpler than some others: Suppose we are in the process of establishing a call between A-----I1-----I2-----B and there was no connection between I1 and I2. A includes an offer in the invite, so I1 and I2 will each rewrite the SDP as the invite goes by. But neither I1 nor I2 yet knows if the invite will succeed, so don't know if this will result in establishing a connection. Meanwhile, we start to establish a new call C-----I1-----I2-----D C includes an offer in the invite. I1 needs to rewrite the SDP in the offer, and would like to reuse the connection it has proposed establishing with I2. But it doesn't yet know if that call will succeed and so doesn't know if the connection will be established. Hence I believe it must assume there will be no connection to reuse, and so must arrange things to establish a separate connection. Yet it is possible that both calls will succeed, so it must be prepared to establish both connections, and to discriminate them from one another. So I think it must offer a separate port in this invite. This scenario doesn't fail, but again it is suboptimal because it may require intermediaries to listen for connections on multiple ports, and may result in redundant connections between a pair of intermediaries. It will take more work to demonstrate a case that actually fails, or to demonstrate a reuse rule that can be proved does not fail. Paul Ben Campbell wrote: > > I agree we should do that, and avoid a dependency on getting the issue > fixed in comedia. > > It does, however, seem like a generalized issue that _should_ be handled > in the comedia specification as well, but that does not seem to be in > scope for this wg. > > Jonathan Rosenberg wrote: > > Cant we solve this at the cpim-msg-sessions layer? > > > > That draft could simply say something like "when you go to connect to > > the IP address/port that is listed there, first check if you already > > have a connection there. If so, use that again, and ignore any comedia > > stuff in the SDP." > > > > -Jonathan R. > > > > Paul Kyzivat wrote: > > > >> Draft-campbell-simple-cpimmsg-sessions-00 defines the protocol in such > >> a way that multiple sessions can be demultiplexed from a single > >> connection. Meanwhile draft-campbell-simple-im-sessions-00 calls for > >> the use of the comedia spec to establish the connections. It also > >> wishes to reuse a single connection for multiple sessions. > >> > >> This presents a problem, because the comedia draft > >> (ietf-mmusic-sdp-comedia-04) does not provide a way to share a > >> connection among multiple sessions. It was constrained from doing so > >> because it made no assumption about the protocol to be used on the > >> connection. As a result it had to come up with a way to associate > >> connections with sessions without regard to media content. > >> Either a way must be found to change comedia to provide this > >> capability, or else comedia must be abandoned in favor of some other > >> arrangement for negotiating a connection. (It would be nice to make > >> comedia work for this.) > >> > >> Rohan and I talked about this, and began to think we could find an > >> enhancement to comedia that would permit this, but then it got very > >> ugly trying to figure out when connections should go away, especially > >> between a pair of intermediaries. This is going to require some work. > >> > >> Paul > >> _______________________________________________ > >> simple mailing list > >> simple@mailman.dynamicsoft.com > >> http://mailman.dynamicsoft.com/mailman/listinfo/simple > >> > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 4 19:53: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 TAA16829 for ; Mon, 4 Nov 2002 19:53:21 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gA50s9cD004173; Mon, 4 Nov 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 TAA03208; Mon, 4 Nov 2002 19:55:04 -0500 (EST) Received: from mta0 ([61.144.161.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03193 for ; Mon, 4 Nov 2002 19:53:59 -0500 (EST) Received: from D70286 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H5200L2CVQYAJ@mta0.huawei.com> for simple@mailman.dynamicsoft.com; Tue, 05 Nov 2002 08:52:12 +0800 (CST) From: Deepankar Subject: Re: [Simple] Interdomain presence To: Ben Campbell Cc: Jonathan Rosenberg , simple@mailman.dynamicsoft.com Message-id: <002901c28465$c79a80b0$ac064d0a@D70286> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <54bbc5284b.5284b54bbc@huawei.com> <3DC681DD.3040905@dynamicsoft.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: Tue, 05 Nov 2002 08:53:39 +0800 Content-Transfer-Encoding: 7BIT Inline ----- Original Message ----- From: "Ben Campbell" To: "deepankarb 70286" Cc: "Jonathan Rosenberg" ; Sent: Monday, November 04, 2002 10:19 PM Subject: Re: [Simple] Interdomain presence > Certainly it will, if you need it for call routing and you don't have it > prior to call setup. If you cannot have a delay in call setup, you must > subscribe to the information in advance. [Deeps] OK. Now, when we are talking of softswitches, it means a whole bunch of subscribers, which would be heavy, specially, when presence gets extended to H.323 endpoints and MGCP phones. Would presencelist package work here ? > > But submit that the application you describe is very much a classic SIP > application, and does not gain much from a presence subscription. > Abc.com does not need to subscribe to presence information, unless > abc.com (or the user) expects to be notified of a presence change and > take some action as a result of that change. > [Deeps] The objective is to do a fetch on the presence information, and route the call. Subsequent notifications might not be necessary for presence based voice calling. As above, they might be required only if say, the presence servers/PAs on both the ends maintain a separate secure channel for SUBSCRIBE/NOTIFY. > In your example, why would you not simply have abc.com proxy the call to > xyz.com, then let xyz.com route the call based on the registered > contacts? What routing decision is abc.com making based on presence? > [Deeps] Then in case of a callee busy everywhere, but with some preferences like, the incoming calls should holler him after the lunch, or call the following delegates at these numbers, .. the call appears to be terminated normally to abc.com, and it does'nt gain from presence information. If abc.com would have got the updated presence information/document, before routing the call, it would had prompted the caller for further actions. > > > deepankarb 70286 wrote: > > Bingo ! But, would'nt it increase the call setup time ? > > > > > > ----- Original Message ----- > > From: Jonathan Rosenberg > > Date: Sunday, November 3, 2002 7:05 pm > > Subject: Re: [Simple] Interdomain presence > > > > > >> > >>deepankarb 70286 wrote: > >> > >>>Yes, thats correct, but I would try to put my query this way. > >>> > >>>say if my PA aka softswitch is responsible for abc.com > >> > >>administrative > domain, and there's another PA taking care of > >>xyz.com administrative > >> > >>>domain. Both have their set of homing subscribers (PUAs). Here, > >> > >>I am > >> > >>>taking PUAs as fixed IP phones, PSTN phones. Since both belong to > >>>different administrative domains, and in case of an example of > >>>presence based voice calling, a sip caller sip:acaller@abc.com is > >>>calling sip:acallee@xyz.com, and abc.com needs to find the presence > >>>first, and then route the call. In this case, how would xyz.com > >>>indicate the presence status/document of acallee to abc.com? > >> > >>Thats what draft-ietf-simple-presence is for. The abc.com would > >>SUBSCRIBE to the presence state at xyz.com. > >> > >>-Jonathan R. > >> > >> > >>-- > >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > >>Chief Scientist First Floor > >>dynamicsoft East Hanover, NJ 07936 > >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.dynamicsoft.com > >> > >>_______________________________________________ > >>simple mailing list > >>simple@mailman.dynamicsoft.com > >>http://mailman.dynamicsoft.com/mailman/listinfo/simple > >> > > > > > > _______________________________________________ > > 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 Tue Nov 5 17:14: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 RAA19698 for ; Tue, 5 Nov 2002 17:14: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 gA5MFKcD008438; Tue, 5 Nov 2002 17:15: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 RAA06777; Tue, 5 Nov 2002 17:16:05 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06766 for ; Tue, 5 Nov 2002 17:15:17 -0500 (EST) From: Tim.Moran@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA5MGCX09957 for ; Tue, 5 Nov 2002 16:16:16 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Nov 2002 16:15:15 -0600 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 16:15:14 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C28518.D0331702" Message-ID: <278B6B0D76698D45BBA872CD23DD496A6743CD@daebe004.americas.nokia.com> X-MS-Has-Attach: yes Thread-Topic: Sipping digest, Vol 1 #692 - 8 msgs Thread-Index: AcKEJKsrjJjQhyPTQjKgoqyIqFOsZAA7qWtg To: , X-OriginalArrivalTime: 05 Nov 2002 22:15:14.0639 (UTC) FILETIME=[D0AB45F0:01C28518] Subject: [Simple] 2 drafts on SIP Notification Filtering 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 Nov 2002 16:15:13 -0600 This is a multi-part message in MIME format. ------_=_NextPart_001_01C28518.D0331702 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greetings, There are two drafts available in the ietf drafts directory related to = the filtering of SIP notifications for clients and networks with limited = resources.=20 The goal is to allow clients (e.g. mobile clients) to specify the rules = whereby the sending of notifications may be restricted to when and what = the client wishes to be notified of. The first draft defines a set of requirements for filtering. <>=20 The second defines an architecture (framework) from which an = application, e.g. presence, can define application specific filtering = capabilities. <>=20 Regards, Tim Moran ------_=_NextPart_001_01C28518.D0331702 Content-Type: application/octet-stream; name="draft-moran-sipping-filter-reqs-00.url" Content-Description: draft-moran-sipping-filter-reqs-00.url Content-Disposition: attachment; filename="draft-moran-sipping-filter-reqs-00.url" Content-Transfer-Encoding: base64 W0RFRkFVTFRdDQpCQVNFVVJMPWh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LW1vcmFuLXNpcHBpbmctZmlsdGVyLXJlcXMtMDAudHh0DQpbSW50ZXJuZXRTaG9ydGN1dF0N ClVSTD1odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tb3Jhbi1zaXBw aW5nLWZpbHRlci1yZXFzLTAwLnR4dA0KTW9kaWZpZWQ9QzBFREJDM0IxNTg1QzIwMTAxDQo= ------_=_NextPart_001_01C28518.D0331702 Content-Type: application/octet-stream; name="draft-moran-sipping-filter-arch-01.url" Content-Description: draft-moran-sipping-filter-arch-01.url Content-Disposition: attachment; filename="draft-moran-sipping-filter-arch-01.url" Content-Transfer-Encoding: base64 W0RFRkFVTFRdDQpCQVNFVVJMPWh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LW1vcmFuLXNpcHBpbmctZmlsdGVyLWFyY2gtMDEudHh0DQpbSW50ZXJuZXRTaG9ydGN1dF0N ClVSTD1odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tb3Jhbi1zaXBw aW5nLWZpbHRlci1hcmNoLTAxLnR4dA0KTW9kaWZpZWQ9MDBCQzdDRkYxNDg1QzIwMTkzDQo= ------_=_NextPart_001_01C28518.D0331702-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 5 20:29:27 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 UAA29626 for ; Tue, 5 Nov 2002 20:29:27 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gA61U5cD009079; Tue, 5 Nov 2002 20:30: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 UAA07441; Tue, 5 Nov 2002 20:31:03 -0500 (EST) Received: from mta0 ([61.144.161.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07430 for ; Tue, 5 Nov 2002 20:30:13 -0500 (EST) Received: from D70286 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H54003GSS3IBU@mta0.huawei.com> for simple@mailman.dynamicsoft.com; Wed, 06 Nov 2002 09:28:31 +0800 (CST) From: Deepankar To: simple@mailman.dynamicsoft.com Message-id: <007701c28534$05174580$ac064d0a@D70286> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_mjaDetrOrOcRq8nV/KBIcg)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Simple] Message Waiting 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 Nov 2002 09:29:58 +0800 This is a multi-part message in MIME format. --Boundary_(ID_mjaDetrOrOcRq8nV/KBIcg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Folks, Could I get directions for message waiting indicators draft.? Deeps --Boundary_(ID_mjaDetrOrOcRq8nV/KBIcg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Folks,
 
Could I get directions for message waiting indicators draft.?
 
Deeps
--Boundary_(ID_mjaDetrOrOcRq8nV/KBIcg)-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 5 23: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 XAA09852 for ; Tue, 5 Nov 2002 23:13: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 gA64EAcD009495; Tue, 5 Nov 2002 23:14: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 XAA08017; Tue, 5 Nov 2002 23:15:05 -0500 (EST) Received: from hss.hns.com ([164.164.94.118]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08004 for ; Tue, 5 Nov 2002 23:14:13 -0500 (EST) From: sunayak@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id gA63tbi29064; Wed, 6 Nov 2002 09:25:41 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C69.0016F58F ; Wed, 6 Nov 2002 09:40:46 +0530 X-Lotus-FromDomain: HSSBLR To: Deepankar cc: simple@mailman.dynamicsoft.com Message-ID: <65256C69.0016F3AC.00@sampark.hss.hns.com> Subject: Re: [Simple] Message Waiting Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=kgiVYlESbWTXP2VwOQSi78qZBfi63BFqSi6DMqYeAhzz43YhAJvbeeno" Content-Disposition: inline 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 Nov 2002 09:40:40 +0530 --0__=kgiVYlESbWTXP2VwOQSi78qZBfi63BFqSi6DMqYeAhzz43YhAJvbeeno Content-type: text/plain; charset=us-ascii Content-Disposition: inline http://www.ietf.org/internet-drafts/draft-ietf-sipping-mwi-01.txt Subhash. Deepankar on 11/06/2002 06:59:58 AM To: simple@mailman.dynamicsoft.com cc: (bcc: Subhash Ullal Nayak/HSSBLR) Subject: [Simple] Message Waiting Folks, Could I get directions for message waiting indicators draft.? Deeps --0__=kgiVYlESbWTXP2VwOQSi78qZBfi63BFqSi6DMqYeAhzz43YhAJvbeeno Content-type: text/html; name="att-1.htm" Content-Disposition: attachment; filename="att-1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuMDAuMjkyMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Gb2xr cyw8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs IHNpemU9Mj5Db3VsZCBJIGdldCBkaXJlY3Rpb25zIGZvciBtZXNzYWdlIHdhaXRpbmcgDQppbmRp Y2F0b3JzIGRyYWZ0Lj88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj5EZWVwczwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0KDQo= --0__=kgiVYlESbWTXP2VwOQSi78qZBfi63BFqSi6DMqYeAhzz43YhAJvbeeno-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 6 11:21: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 LAA00026 for ; Wed, 6 Nov 2002 11:21:24 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gA6GM6cD011390; Wed, 6 Nov 2002 11:22: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 LAA10105; Wed, 6 Nov 2002 11:23:04 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10094 for ; Wed, 6 Nov 2002 11:22:28 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA6GM1O20738 for ; Wed, 6 Nov 2002 18:22:01 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 6 Nov 2002 18:21:32 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 18:21:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C285B0.90BA66D6" Message-ID: X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt Thread-Index: AcKESzsqh/72XbQPT+2WaTbqz2HG2gBY7nGA To: X-OriginalArrivalTime: 06 Nov 2002 16:21:31.0249 (UTC) FILETIME=[90F4B610:01C285B0] Subject: [Simple] FW: I-D ACTION:draft-isomaki-simple-list-man-sem-00.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, 6 Nov 2002 18:21:30 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C285B0.90BA66D6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The following draft is now available in the I-D directories. It is an = initial attempt to specify a list management protocol on an abstract = level (only semantics, no syntax). The proposal is made based on the = requirements stated in "draft-ietf-simple-data-req-00". The draft is = still quite drafty, but the main points should be visible.=20 The main idea is that many applications (for instance presence and = conferencing) require lists that should be configurable by a client = terminal. It would be useful to define a standard protocol to handle = list manipulation (for SIP-applications), so that it could be "plugged = in" to any application needing it. I hope comments to the approach and to the actual abstract protocol. If = this is a good enough start, it could be used as a basis for a WG = document. After that would be reasonably stable, a mapping to some real = syntax could be made and that specifation should be in standards track. Markus =20 > -----Original Message----- > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: 04 November, 2002 17:05 > Subject: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Semantic Description of SIMPLE List=20 > Manipulation=20 > Operations > Author(s) : M. Isomaki et al. > Filename : draft-isomaki-simple-list-man-sem-00.txt > Pages : 13 > Date : 2002-11-1 > =09 > In SIMPLE based presence and messaging applications, it is necessary=20 > for the user to be able to configure a number of pieces of=20 > information.=20 > One of the most common types of information is a list of URIs. List=20 > management is useful outside the scope of SIMPLE as well, for=20 > instance=20 > in conferencing. There are many reasons why it would be beneficial to=20 > manage the lists in a similar fashion regardless of the application.=20 > Before the selection of the actual protocol(s) to manage the=20 > lists there=20 > is a need to describe their semantics on an abstract level. This=20 > document proposes the semantics for SIMPLE list manipulation protocol. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-isomaki-simple-list- man-sem-00.txt To remove yourself from the IETF Announcement list, send a message to=20 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-isomaki-simple-list-man-sem-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-isomaki-simple-list-man-sem-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C285B0.90BA66D6 Content-Type: application/octet-stream; name="ATT840765.TXT" Content-Description: ATT840765.TXT Content-Disposition: attachment; filename="ATT840765.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAyLTExLTExNDMzMzkuSS1EQGlldGYub3JnPg0KDQpF TkNPRElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaXNvbWFraS1zaW1wbGUt bGlzdC1tYW4tc2VtLTAwLnR4dA0K ------_=_NextPart_001_01C285B0.90BA66D6 Content-Type: application/octet-stream; name="draft-isomaki-simple-list-man-sem-00.URL" Content-Description: draft-isomaki-simple-list-man-sem-00.URL Content-Disposition: attachment; filename="draft-isomaki-simple-list-man-sem-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pc29tYWtpLXNpbXBsZS1saXN0LW1hbi1zZW0tMDAudHh0DQo= ------_=_NextPart_001_01C285B0.90BA66D6-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 6 11:57: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 LAA01519 for ; Wed, 6 Nov 2002 11:57: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 gA6Gw4cD011639; Wed, 6 Nov 2002 11:58: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 LAA10317; Wed, 6 Nov 2002 11:59:03 -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 LAA10306 for ; Wed, 6 Nov 2002 11:58:59 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gA6Gx0YH025553; Wed, 6 Nov 2002 11:59:00 -0500 (EST) Message-ID: <3DC94A52.4060505@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Ben Campbell , Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 06 Nov 2002 11:58:58 -0500 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > Jonathan, Ben, > > I would be pleased if we can find a way to finesse this. The problem > is that comedia requires some way to infer, from the sip signaling > and SDP content, when connections should be made/dropped. Both sides > must make the same inference, or else the connection establishment > will fail. As soon as we start to pool connections there starts to be > the potential for race conditions. > > This is especially a problem with connections between two > intermediaries. The hard question is: when can you ever drop a > connection between two intermediaries? I don't see this as that critical. I would guess that the passive side of a connection can always close, and the active side would just reopen if the session isn't terminated. No? I think comedia says you shouldnt close the connection before the session ends, but sometimes that happens for a variety of reasons. It should say something about retrying. f course an intermediary > never knows if its peer in the connection is also an intermediary or > not, so it must act as if the peer is a UA following the comedia spec > plus whatever additional rules we can come up with for simple. Right. > We > can't drop a connection until we know that there are no sessions > using it. A corollary to that is that we can't reuse a connection > that has no sessions using it, because it might be dropped. And so we > should drop a connection as soon as there are no sessions using it, > because it is then worthless. > > That already starts looking suboptimal, because we must drop > connections between pairs of high traffic intermediaries any time > there doesn't happen to be some session traversing them. I think you want to decouple the connection lifetimes from the session lifetimes. > > But I'm not sure this is workable even with that limitation. I have a > hunch there is still a race condition when one end will think there > is a connection and attempt to reuse it, while the other end has > decided there is no session using the connection and tries to drop it > or establish a new one. This is tricky, and probably impossible to > decide in general except with respect to a precise rule for reuse. > But here is one case that seems simpler than some others: > > Suppose we are in the process of establishing a call between > > A-----I1-----I2-----B > > and there was no connection between I1 and I2. A includes an offer in > the invite, so I1 and I2 will each rewrite the SDP as the invite goes > by. But neither I1 nor I2 yet knows if the invite will succeed, so > don't know if this will result in establishing a connection. > > Meanwhile, we start to establish a new call > > C-----I1-----I2-----D > > C includes an offer in the invite. I1 needs to rewrite the SDP in the > offer, and would like to reuse the connection it has proposed > establishing with I2. But it doesn't yet know if that call will > succeed and so doesn't know if the connection will be established. > Hence I believe it must assume there will be no connection to reuse, This is an artifact of a very bad design choice made by comedia. What you REALLY want is that whenever I1 modifies an INVITE, it *always* puts the same port number/IP into the SDP. Multiple connections can be established onto that IP/port. Thus, both the INVITE from A and from C, I1 would place the same IP/port into the SDP. Now, if either of those should succeed, I1 will try to open a connection to that IP/port. If it already has one there, that gets reused. So, whats the problem? Well, all intermediaries need to maintain a routing table, which tells them what to do with incoming messages. That table tells them that if an IM arrives on some specific connection, with a specific URI/identifier in the outer envelope, to forward to a different connection with a different URI/identifier in the outer envelope. THis means that the intermediary has to associate each connection with a specific dialog used to set it up (since the dialog is used to exchange the SDP that contains the URI/identifiers). How is this association done? Right now, its done with the SOURCE ADDRESS. That is, the SDP sent out by A in your example contains the source IP/port it will make the connection from. So, when I1 receives the connection request, it can determine the source, and then match it to the dialog. The problem is, this doesn't work at all through NAT. If you don't want to use the source to demux, the intermediary can arrange for each connection to occur on a different port, and that means no reuse. So, we have a real problem. I registered this complaint about comedia/NAT to mmusic some time back, but it was ignored. IMHO its still a show stopper. Its especially heinous when you want to add intermediaries, which wasn't considered at the time. My proposal would be to use connection identifiers separate from addresses. The SDP contains some kind of parameter that identifies the connection. Its just a random token. Whenever the connection is opened, the active side sends, as the first bytes, this identifier. THis way, the passive side knows which dialog its associated with, without needing to rely on source IP. So, lets go through an example of how this works with a single intermediary. We've got A----I-----B: * A sends an INVITE. SDP has a connection identifier of CID-A1 and a URI of sip:A1. Through comedia it says it can be both active or passive. Of course we want it to be active in case its natted. This goes to I. * I rewrites the SDP. It places a different IP/port (some common one used in all requests), and a new connection ID, CID-I1. It rewrites the address to sip:I1. It also indicates passive only. Note that, since its passive, the connection ID isn't important. This goes to B. * B sends a 200 OK. It indicates active in its SDP. It includes a connection ID of CID-B1 and URI of sip:B1. * I rewrites the SDP in the 200 OK. It includes the same common IP/port, but yet another connection ID, CID-I2 and URI sip:I2. Forwards to A. Now, I knows that messages from sip:A1 on either connection CID-I2 or CID-A1 go to sip:B1, on either connection CID-I1 or CID-B1. Which connection depends on which direction establishes. * A opens a connection to I. Once opened, it passes CID-A1 on the connection. Now, I knows that this connection corresponds to the dialog it established with A. Similarly, B opens a connection to I, passes CID-B1, and I knows that this connection is associated with the dialog opened to B. Forwarding happens. Now, consider the more complex case, of two intermediaries. So its A---I---IJ---B. Lets say there is already a connection opened between I and J. I had indicated a connection ID of CID-I1, and J had indicated CID-J1. * A sends an INVITE. connection ID is new, CID-A1. URI is sip:A1. It indicates direction:both. Includes some IP/port for receiving connections. * I gets the INVITE. Rewrites the SDP to CID-I2 (a new ID - since it doesn't know who will get this, whether a connection is there already). Rewrites the URI to sip:I2. Direction passive. Includes its common IP/port. Sends to J. * J gets the INVITE. Rewrites the SDP to CID-J2, also a new ID. Rewrites the URI to sip:J2. Direction, passive. Includes its common IP/port. Sends to B. * B gets the INVITE. Sends a 200 OK. B notices it doesn't have a connection to the IP/port indicated by J in the SDP. So, it creates a new CID, CID-B1, and places that in its SDP, along with direction:active. * J gets the 200 OK. J notices that it does have a connection to the IP/port in the INVITE it received. So, it decides it can reuse that connection. So, it rewrites the SDP in the 200 OK with CID-J1 (the ID it had formerly exchanged with I), and indicates a direction of active. FOrwards to I. * I gets the 200 OK. I sees that it DOESNT have a connection to the IP/port that A provided, so it creates a new connection ID, CID-I3, and places that in the 200 OK. It indicates a direction of passive. Places its common IP/port in the SDP, sends to A. * Now, the SDP that A got indicated passive. So, it opens a connection to the IP/port provided by I. It sends its proposed connection ID, CID-A1 once the connection is opened. * The SDP that B got indicated passive. So, it opens a connection to the IP/port that J provided. It sends its proposed connection ID, CID-B1, once the connection is opened. * I and J realize that the connection IDs exchanged betwen them relate to an existing connection, so they don't open a new one. If the connection between I and J should close, either side would re-initiate, and it would reuse the connection ID it had stored and remembered as associated with the destiation IP/port it needs to open a connection to. Now, I *think* this works. I'm a bit hazy on the precise rules of usage and reuse of these connection IDs. THe aim is to do something that doesnt require a re-INVITE when a new connection is opened. Again - we want to separate connection lifetime from session lifetime. This solution allows for connection reuse and also works smoothly through NAT without any pains. Thoughts? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 6 13:15:14 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 NAA05075 for ; Wed, 6 Nov 2002 13:15:14 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gA6IG5cD012046; Wed, 6 Nov 2002 13: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 NAA10597; Wed, 6 Nov 2002 13:17:03 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10586 for ; Wed, 6 Nov 2002 13:16:11 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA6IGeB03392 for ; Wed, 6 Nov 2002 20:16:40 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Nov 2002 20:16:09 +0200 Received: from agni.research.nokia.com ([172.21.40.24]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 20:16:09 +0200 Received: from agni.research.nokia.com (localhost [127.0.0.1]) by agni.research.nokia.com (8.12.5/8.12.5) with ESMTP id gA6IG7hP026161; Wed, 6 Nov 2002 20:16:07 +0200 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.5/8.12.5/Submit) id gA6IG7Gt026160; Wed, 6 Nov 2002 20:16:07 +0200 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: , Cc: Stephane.Coulombe@nokia.com, Pekka.Pessi@nokia.com, Jose.Costa-Requena@nokia.com X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <278B6B0D76698D45BBA872CD23DD496A6743CD@daebe004.americas.nokia.com> Message-ID: Lines: 28 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 06 Nov 2002 18:16:09.0919 (UTC) FILETIME=[94F674F0:01C285C0] Subject: [Simple] Re: [Sipping] 2 drafts on SIP Notification Filtering 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: 06 Nov 2002 20:16:07 +0200 Hello all, We have submitted two drafts regarding multimedia message adaptation. A multimedia message is typically a message containing images, audio or video clips and their presentation information, e.g., smil. Also, even XML-formatted text may require adaptation in some cases. Our goal is to have a framework using SIP, HTTP and MIME that allows a person sending multimedia message to adapt the message contents suitable to all the recipients. In some cases the adaptation can be done by the sending terminal, but we also see that an adaptation service would be very useful in many cases. Such an adaptation mechanism is used by MMS service provided by cellular networks nowadays. The message adaptation work concerns both SIPPING and SIMPLE, the requirements I-D lists use cases and requirements for multimedia messaging and message adaptation solutions and the framework I-D tries to explore possible solutions. Best regards, Pekka http://www.ietf.org/internet-drafts/draft-coulombe-message-adaptation-framework-00.txt http://www.ietf.org/internet-drafts/draft-coulombe-message-adaptation-requirements-00.txt _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 6 13:23: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 NAA05532 for ; Wed, 6 Nov 2002 13:23: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 gA6IO5cD012150; Wed, 6 Nov 2002 13:24: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 NAA10654; Wed, 6 Nov 2002 13:25:05 -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 NAA10631 for ; Wed, 6 Nov 2002 13:24:22 -0500 (EST) 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 gA6INtO22922 for ; Wed, 6 Nov 2002 20:23:55 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Nov 2002 20:24:15 +0200 Received: from agni.research.nokia.com ([172.21.40.24]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 20:24:15 +0200 Received: from agni.research.nokia.com (localhost [127.0.0.1]) by agni.research.nokia.com (8.12.5/8.12.5) with ESMTP id gA6IODhP026209; Wed, 6 Nov 2002 20:24:13 +0200 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.5/8.12.5/Submit) id gA6IODGQ026208; Wed, 6 Nov 2002 20:24:13 +0200 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: , References: X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: Message-ID: Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 06 Nov 2002 18:24:15.0713 (UTC) FILETIME=[B684BD10:01C285C1] Subject: [Simple] Multimedia message adaptation Internet-Drafts 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: 06 Nov 2002 20:24:13 +0200 While these drafts concern event filtering, too, the subject was a bit misleading because I lazily just followed up Tim's e-mail. Pekka http://www.ietf.org/internet-drafts/draft-coulombe-message-adaptation-framework-00.txt http://www.ietf.org/internet-drafts/draft-coulombe-message-adaptation-requirements-00.txt Pekka Pessi writes: >We have submitted two drafts regarding multimedia message >adaptation. A multimedia message is typically a message >containing images, audio or video clips and their presentation >information, e.g., smil. Also, even XML-formatted text may >require adaptation in some cases. >Our goal is to have a framework using SIP, HTTP and MIME that >allows a person sending multimedia message to adapt the message >contents suitable to all the recipients. In some cases the >adaptation can be done by the sending terminal, but we also see >that an adaptation service would be very useful in many cases. >Such an adaptation mechanism is used by MMS service provided by >cellular networks nowadays. >The message adaptation work concerns both SIPPING and SIMPLE, >the requirements I-D lists use cases and requirements for >multimedia messaging and message adaptation solutions and the >framework I-D tries to explore possible solutions. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 6 13:50: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 NAA06543 for ; Wed, 6 Nov 2002 13:50: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 gA6Ip3cD012362; Wed, 6 Nov 2002 13:51:03 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10771; Wed, 6 Nov 2002 13:52:02 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10760 for ; Wed, 6 Nov 2002 13:51:50 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gA6IpmF19806 for ; Wed, 6 Nov 2002 13:51:48 -0500 (EST) Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 18:51:47 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00696E509@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sipping@ietf.org, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Multimedia message adaptation Internet-Drafts MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 6 Nov 2002 18:51:46 -0000 I am getting a bit confused as to which group should be discussing these filtering issues. Could we have a statement from the WG chairs of SIPPING or SIMPLE as to whether this, and the moran drafts, are part of the scope of SIPPING or SIMPLE. And before you say these are both author drafts, I think we do need to charter one of the WGs to do some work in this area - I am just not sure of the exact scope yet. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > Sent: 06 November 2002 18:24 > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > Subject: [Simple] Multimedia message adaptation Internet-Drafts > > > While these drafts concern event filtering, too, the subject was > a bit misleading because I lazily just followed up Tim's e-mail. > > Pekka > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > ptation-framework-00.txt > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > ptation-requirements-00.txt > > Pekka Pessi writes: > >We have submitted two drafts regarding multimedia message > >adaptation. A multimedia message is typically a message > >containing images, audio or video clips and their presentation > >information, e.g., smil. Also, even XML-formatted text may > >require adaptation in some cases. > > >Our goal is to have a framework using SIP, HTTP and MIME that > >allows a person sending multimedia message to adapt the message > >contents suitable to all the recipients. In some cases the > >adaptation can be done by the sending terminal, but we also see > >that an adaptation service would be very useful in many cases. > >Such an adaptation mechanism is used by MMS service provided by > >cellular networks nowadays. > > >The message adaptation work concerns both SIPPING and SIMPLE, > >the requirements I-D lists use cases and requirements for > >multimedia messaging and message adaptation solutions and the > >framework I-D tries to explore possible solutions. > > _______________________________________________ > 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 Nov 6 13:53: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 NAA06700 for ; Wed, 6 Nov 2002 13:53:09 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gA6Is4cD012431; Wed, 6 Nov 2002 13:54: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 NAA10805; Wed, 6 Nov 2002 13:55: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 NAA10792 for ; Wed, 6 Nov 2002 13:54:30 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA6IsfOH012378; Wed, 6 Nov 2002 13:54:42 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAU32850; Wed, 6 Nov 2002 13:59:16 -0500 (EST) Message-ID: <3DC9655E.1C8CBDA1@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: Ben Campbell , Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@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: Wed, 06 Nov 2002 13:54:22 -0500 Content-Transfer-Encoding: 7bit Jonathan - comments inline. Paul Jonathan Rosenberg wrote: > > > This is especially a problem with connections between two > > intermediaries. The hard question is: when can you ever drop a > > connection between two intermediaries? > > I don't see this as that critical. I would guess that the passive side > of a connection can always close, and the active side would just reopen > if the session isn't terminated. No? I think comedia says you shouldnt > close the connection before the session ends, but sometimes that happens > for a variety of reasons. It should say something about retrying. I should have been clearer - I meant that this is a hard question given the current specification of comedia. There may well be modifications to comedia or alternatives to comedia where this isn't hard. But comedia is the way it is because of assumptions made around its requirements. Those assumptions will need to be changed to get to a different solution. > I think you want to decouple the connection lifetimes from the session > lifetimes. This is one of those assumtions. *If* you decouple these, then it is necessary to retain a listener for connections on the advertised port even after a connection is established. This gets to be a problem when it is also necessary to dedicate a port for each distinct session in progress. Its all a house of cards. > > > > > But I'm not sure this is workable even with that limitation. I have a > > hunch there is still a race condition when one end will think there > > is a connection and attempt to reuse it, while the other end has > > decided there is no session using the connection and tries to drop it > > or establish a new one. This is tricky, and probably impossible to > > decide in general except with respect to a precise rule for reuse. > > But here is one case that seems simpler than some others: > > > > Suppose we are in the process of establishing a call between > > > > A-----I1-----I2-----B > > > > and there was no connection between I1 and I2. A includes an offer in > > the invite, so I1 and I2 will each rewrite the SDP as the invite goes > > by. But neither I1 nor I2 yet knows if the invite will succeed, so > > don't know if this will result in establishing a connection. > > > > Meanwhile, we start to establish a new call > > > > C-----I1-----I2-----D > > > > C includes an offer in the invite. I1 needs to rewrite the SDP in the > > offer, and would like to reuse the connection it has proposed > > establishing with I2. But it doesn't yet know if that call will > > succeed and so doesn't know if the connection will be established. > > Hence I believe it must assume there will be no connection to reuse, > > This is an artifact of a very bad design choice made by comedia. > > What you REALLY want is that whenever I1 modifies an INVITE, it *always* > puts the same port number/IP into the SDP. Multiple connections can be > established onto that IP/port. Thus, both the INVITE from A and from C, > I1 would place the same IP/port into the SDP. > > Now, if either of those should succeed, I1 will try to open a connection > to that IP/port. If it already has one there, that gets reused. > > So, whats the problem? Well, all intermediaries need to maintain a > routing table, which tells them what to do with incoming messages. That > table tells them that if an IM arrives on some specific connection, with > a specific URI/identifier in the outer envelope, to forward to a > different connection with a different URI/identifier in the outer > envelope. THis means that the intermediary has to associate each > connection with a specific dialog used to set it up (since the dialog is > used to exchange the SDP that contains the URI/identifiers). How is this > association done? > > Right now, its done with the SOURCE ADDRESS. That is, the SDP sent out > by A in your example contains the source IP/port it will make the > connection from. So, when I1 receives the connection request, it can > determine the source, and then match it to the dialog. The problem is, > this doesn't work at all through NAT. If you don't want to use the > source to demux, the intermediary can arrange for each connection to > occur on a different port, and that means no reuse. So, we have a real > problem. > > I registered this complaint about comedia/NAT to mmusic some time back, > but it was ignored. IMHO its still a show stopper. Its especially > heinous when you want to add intermediaries, which wasn't considered at > the time. Once again, this is a matter of conflicting assumptions/requirements. Sharing of a connection by different sessions, or even sharing of the port to which connections are made, requires that you be able to correlate some unique session identifier passed in the SDP session description with something passed through the resulting connection. But that places a constraint on the kind of protocol that is used over the connection. The comedia work was already in progress when I discovered it. It was my perception that placing requirements on the protocol to be used over the connection was out of scope. I tried to get some revisions into comedia that would make it more palatable within those constraints. But I must agree with you that the result is pretty ugly - nothing that I would prefer to use. I think it would be a good thing to revisit the assumptions behind comedia and then come up with something better that satisfies them. I don't know if this should be viewed as a revision to comedia or simply something new. My point in bringing this up wrt draft-campbell-simple-*-sessions-00 is that the existing comedia draft (draft-ietf-mmusic-sdp-comedia-04) doesn't provide the needed functionality. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 7 08:40: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 IAA23565 for ; Thu, 7 Nov 2002 08:40: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 gA7DfIcD015689; Thu, 7 Nov 2002 08:41:18 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14125; Thu, 7 Nov 2002 08:42:06 -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 IAA14114 for ; Thu, 7 Nov 2002 08:41:13 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA7DekO03087 for ; Thu, 7 Nov 2002 15:40:46 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 7 Nov 2002 15:41:12 +0200 Received: from agni.research.nokia.com ([172.21.40.24]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 15:41:12 +0200 Received: from agni.research.nokia.com (localhost [127.0.0.1]) by agni.research.nokia.com (8.12.5/8.12.5) with ESMTP id gA7Df9hP028341; Thu, 7 Nov 2002 15:41:09 +0200 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.5/8.12.5/Submit) id gA7Df8IN028340; Thu, 7 Nov 2002 15:41:08 +0200 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Cc: Ben Campbell Subject: Re: [Simple] Message Session IDs References: <3DBEFB35.1040908@dynamicsoft.com> X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3DBEFB35.1040908@dynamicsoft.com> Message-ID: Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 07 Nov 2002 13:41:12.0830 (UTC) FILETIME=[565831E0:01C28663] 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: 07 Nov 2002 15:41:08 +0200 Ben Campbell writes: >draft-campbell-simple-im-sessions-00 discusses the use of the SDP >offer/answer model for initiating message sessions, without talking much >about the message sessions themselves. There are some things with SDP that might require modifications. I would use the default mapping from SDP spec, according to it the message/cpim would be presented like m=message (port) (tport) cpim. I would also list the inner MIME types in fmtp or similar attribute line. So, instead of m=message 8937 cpim/tls text/plain text/html I would write it like this: m=message 8937 tls cpim a=fmtp:cpim accept:text/plain,text/html As an added bonus, this would also work: m=message 8937 tls/sctp cpim sip sipfrag >draft-campbell-simple-cpimmsg-sessions-00 proposes a message session >transport that involves transporting messages over TCP or TLS using the >message/cpim format. This draft depends on the signaling methods described >in the im-sessions draft. The comedia draft does not define how the application should behave when a connection is closed (except with direction:both, which states that the endpoint SHOULD close an idle connection). An explicit message like RTCP BYE might be useful here. Pekka _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 7 15:05: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 PAA08803 for ; Thu, 7 Nov 2002 15:05: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 gA7K1AcD017508; Thu, 7 Nov 2002 15:01: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 PAA15227; Thu, 7 Nov 2002 15:02:04 -0500 (EST) Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15216 for ; Thu, 7 Nov 2002 15:01:18 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gA7K1H124640; Thu, 7 Nov 2002 14:01:17 -0600 From: Robert Sparks To: simple@mailman.dynamicsoft.com Cc: "jon.peterson@neustar.biz" Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Message-Id: <1036698869.12174.51.camel@RjS.localdomain> Mime-Version: 1.0 Subject: [Simple] SIMPLE IETF55 agenda requests 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: 07 Nov 2002 13:54:29 -0600 Content-Transfer-Encoding: 7bit Folks - The following represents (in no particular order) the requests I've received for agenda time at the Atlanta meeting. If you think you've asked for time not represented here, let me know ASAP. I'll turn this into an actual agenda over the next couple of days. There's a lot to cover here, and we have only a two hour meeting. Remember that the meeting time needs to focus on resolving open issues, not presenting drafts. We will be focusing on those drafts that are receiving attention on the list. RjS -------------------------------------------------------------------------------------- Jonathan Rosenberg - Data Requirements http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-00.txt Aki Niemi - 3GPP messaging and presence requirements http://www.ietf.org/internet-drafts/draft-niemi-simple-im-wireless-reqs-00.txt http://www.ietf.org/internet-drafts/draft-kiss-simple-presence-wireless-reqs-01.txt Paul Kyzivat - SIP Presence extensions http://www.ietf.org/internet-drafts/draft-kyzivat-simple-prescaps-reqts-00.txt Markus Isomaki - Semantic Description of SIMPLE List Manipulation Operations http://www.ietf.org/internet-drafts/draft-isomaki-simple-list-man-sem-00.txt Robert Sparks - XMPP sessions http://www.ietf.org/internet-drafts/draft-sparks-simple-jabber-sessions-00.txt Adam Roach - List Templates http://www.ietf.org/internet-drafts/draft-roach-sip-list-template-00.txt Ben Campbell - Message Sessions http://www.ietf.org/internet-drafts/draft-campbell-simple-im-sessions-00.txt http://www.ietf.org/internet-drafts/draft-campbell-simple-cpimmsg-sessions-00.txt Sean Olson - Publish http://www.ietf.org/internet-drafts/draft-olson-simple-publish-01.txt _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 7 16:39: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 QAA14429 for ; Thu, 7 Nov 2002 16:39: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 gA7LZ8cD018014; Thu, 7 Nov 2002 16:35: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 QAA15540; Thu, 7 Nov 2002 16:36:04 -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 PAA15291 for ; Thu, 7 Nov 2002 15:16:28 -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 PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; x-msg: NoteWell Subject: [Simple] Note Well Statement 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 Nov 2002 15:11:40 -0500 From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 7 22:06:24 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 WAA22750 for ; Thu, 7 Nov 2002 22:06:24 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gA837DcD018970; Thu, 7 Nov 2002 22:07: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 WAA16554; Thu, 7 Nov 2002 22:08:08 -0500 (EST) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16543 for ; Thu, 7 Nov 2002 22:07:42 -0500 (EST) Received: from kevlar.softarmor.com (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.12.5/8.12.5) with ESMTP id gA83AsHF020532; Thu, 7 Nov 2002 21:10:54 -0600 Received: (from dwillis@localhost) by kevlar.softarmor.com (8.12.5/8.12.5/Submit) id gA83Ap4f020530; Thu, 7 Nov 2002 21:10:51 -0600 X-Authentication-Warning: kevlar.softarmor.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: Re: [Sipping] RE: [Simple] Multimedia message adaptation Internet-Drafts From: Dean Willis To: "Drage, Keith (Keith)" Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com In-Reply-To: <475FF955A05DD411980D00508B6D5FB00696E509@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00696E509@en0033exch001u.uk.lucent.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Message-Id: <1036725050.20411.2.camel@kevlar.softarmor.com> Mime-Version: 1.0 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 07 Nov 2002 21:10:50 -0600 Content-Transfer-Encoding: 7bit Well, I'd like to hear opinions from the participants here . . . Clearly they aren't explicitly on the charter for either group. Do we as yet have a consensus that we need to work on these problems? If so, we can consider WHERE to work on them. I suspect SIPPING is closer to a matching scope than is SIMPLE, but the relevant ADs may have suggestions to make there as well. -- Dean On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > I am getting a bit confused as to which group should be discussing these filtering issues. > > Could we have a statement from the WG chairs of SIPPING or SIMPLE as to whether this, and the moran drafts, are part of the scope of SIPPING or SIMPLE. > > And before you say these are both author drafts, I think we do need to charter one of the WGs to do some work in this area - I am just not sure of the exact scope yet. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > Sent: 06 November 2002 18:24 > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > Subject: [Simple] Multimedia message adaptation Internet-Drafts > > > > > > While these drafts concern event filtering, too, the subject was > > a bit misleading because I lazily just followed up Tim's e-mail. > > > > Pekka > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > ptation-framework-00.txt > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > ptation-requirements-00.txt > > > > Pekka Pessi writes: > > >We have submitted two drafts regarding multimedia message > > >adaptation. A multimedia message is typically a message > > >containing images, audio or video clips and their presentation > > >information, e.g., smil. Also, even XML-formatted text may > > >require adaptation in some cases. > > > > >Our goal is to have a framework using SIP, HTTP and MIME that > > >allows a person sending multimedia message to adapt the message > > >contents suitable to all the recipients. In some cases the > > >adaptation can be done by the sending terminal, but we also see > > >that an adaptation service would be very useful in many cases. > > >Such an adaptation mechanism is used by MMS service provided by > > >cellular networks nowadays. > > > > >The message adaptation work concerns both SIPPING and SIMPLE, > > >the requirements I-D lists use cases and requirements for > > >multimedia messaging and message adaptation solutions and the > > >framework I-D tries to explore possible solutions. > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 8 06:45:53 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 GAA13679 for ; Fri, 8 Nov 2002 06:45: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 gA8Bk6cD020152; Fri, 8 Nov 2002 06:46: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 GAA18187; Fri, 8 Nov 2002 06:47:03 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18176 for ; Fri, 8 Nov 2002 06:46:41 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA8BlCB04414 for ; Fri, 8 Nov 2002 13:47:12 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Nov 2002 13:46:34 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 13:46:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Message-ID: Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKG1KTa2SE/J0KdTJCVUzzcD3eDCAARX8MA To: , , , Cc: , X-OriginalArrivalTime: 08 Nov 2002 11:46:37.0845 (UTC) FILETIME=[7EF27C50:01C2871C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA18176 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 Nov 2002 13:46:36 +0200 Content-Transfer-Encoding: 8bit Hi, Actually this thread is about two separate things: - Event filtering - Multimedia message adaptation Neither of them appears currently on any sippish WG charter currently. Event filtering has been discussed several times and it is even mentioned in (but out of scope of) SIP Events RFC. My impression has been that people think that it is needed, but there has been debate about scope and feasibility. I hope the requirements draft will help in that discussion. My own opinion is that what is concretely needed in short term is some simple filtering definitions for Presence event package. More wide-scoped and complex things could be worked upon as the understanding accumulates. Multimedia message adaptation hasn't been yet discussed much. I think it is in general a desirable feature, especially for relatively small and dumb terminals, which are not easily upgradable and may not understand all media formats. So I propose the WG chairs think where these items would be appropriate, and if there is enough interest for them, let's put them on the charters. Markus > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 08 November, 2002 5:11 > To: Drage, Keith (Keith) > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > Subject: Re: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > Well, I'd like to hear opinions from the participants here . . . > > Clearly they aren't explicitly on the charter for either > group. Do we as > yet have a consensus that we need to work on these problems? If so, we > can consider WHERE to work on them. I suspect SIPPING is closer to a > matching scope than is SIMPLE, but the relevant ADs may have > suggestions > to make there as well. > > -- > Dean > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > I am getting a bit confused as to which group should be > discussing these filtering issues. > > > > Could we have a statement from the WG chairs of SIPPING or > SIMPLE as to whether this, and the moran drafts, are part of > the scope of SIPPING or SIMPLE. > > > > And before you say these are both author drafts, I think we > do need to charter one of the WGs to do some work in this > area - I am just not sure of the exact scope yet. > > > > Keith > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > > -----Original Message----- > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > Sent: 06 November 2002 18:24 > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > Subject: [Simple] Multimedia message adaptation Internet-Drafts > > > > > > > > > While these drafts concern event filtering, too, the subject was > > > a bit misleading because I lazily just followed up Tim's e-mail. > > > > > > Pekka > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > ptation-framework-00.txt > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > ptation-requirements-00.txt > > > > > > Pekka Pessi writes: > > > >We have submitted two drafts regarding multimedia message > > > >adaptation. A multimedia message is typically a message > > > >containing images, audio or video clips and their presentation > > > >information, e.g., smil. Also, even XML-formatted text may > > > >require adaptation in some cases. > > > > > > >Our goal is to have a framework using SIP, HTTP and MIME that > > > >allows a person sending multimedia message to adapt the message > > > >contents suitable to all the recipients. In some cases the > > > >adaptation can be done by the sending terminal, but we also see > > > >that an adaptation service would be very useful in many cases. > > > >Such an adaptation mechanism is used by MMS service provided by > > > >cellular networks nowadays. > > > > > > >The message adaptation work concerns both SIPPING and SIMPLE, > > > >the requirements I-D lists use cases and requirements for > > > >multimedia messaging and message adaptation solutions and the > > > >framework I-D tries to explore possible solutions. > > > > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > 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 Nov 8 07:56: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 HAA17291 for ; Fri, 8 Nov 2002 07:56:11 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gA8Cv3cD020374; Fri, 8 Nov 2002 07:57: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 HAA18406; Fri, 8 Nov 2002 07:58:03 -0500 (EST) Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18395 for ; Fri, 8 Nov 2002 07:57:41 -0500 (EST) Received: from cypress.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id gA8Cvei15184; Fri, 8 Nov 2002 12:57:40 GMT Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id gA8CvYX12331; Fri, 8 Nov 2002 12:57:34 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 07:58:23 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB39A@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Markus.Isomaki@nokia.com'" , dean.willis@softarmor.com, drage@lucent.com, rohan@cisco.com, Gonzalo.Camarillo@lmf.ericsson.se Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet- Drafts MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 8 Nov 2002 07:58:21 -0500 It seems to me that these filtering drafts concern the modification of MIME bodies in SIP messages by intermediaries. This is not exactly an uncontroversial topic in SIP circles, and therefore I don't think it is a foregone conclusion that this is work that some SIP-related WG should charter. At a high level, these drafts also argue that capability negotiation should be administered by intermediaries rather than through an end-to-end process; this approach may attract some similar controversy. Provided that this is work the community would like to pursue, the applicability and impact of this mechanism is larger than the problem of instant messaging and presence. While clearly, from the framework, instant messaging and presence cases are driving this work, it is applicable to the general use of SIP events (messaging, I think, is something of a corner case). While SIMPLE could certainly spend some time refining the framework and requirements related to IM & presence, I imagine that at a mechanism stage this work would need to take place in SIPPING. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Friday, November 08, 2002 3:47 AM > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > Hi, > > Actually this thread is about two separate things: > - Event filtering > - Multimedia message adaptation > > Neither of them appears currently on any sippish WG charter > currently. > > Event filtering has been discussed several times and it is > even mentioned in (but out of scope of) SIP Events RFC. My > impression has been that people think that it is needed, but > there has been debate about scope and feasibility. I hope the > requirements draft will help in that discussion. My own > opinion is that what is concretely needed in short term is > some simple filtering definitions for Presence event package. > More wide-scoped and complex things could be worked upon as > the understanding accumulates. > > Multimedia message adaptation hasn't been yet discussed much. > I think it is in general a desirable feature, especially for > relatively small and dumb terminals, which are not easily > upgradable and may not understand all media formats. > > So I propose the WG chairs think where these items would be > appropriate, and if there is enough interest for them, let's > put them on the charters. > > Markus > > > -----Original Message----- > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: 08 November, 2002 5:11 > > To: Drage, Keith (Keith) > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > Subject: Re: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > Well, I'd like to hear opinions from the participants here . . . > > > > Clearly they aren't explicitly on the charter for either > > group. Do we as > > yet have a consensus that we need to work on these > problems? If so, we > > can consider WHERE to work on them. I suspect SIPPING is closer to a > > matching scope than is SIMPLE, but the relevant ADs may have > > suggestions > > to make there as well. > > > > -- > > Dean > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > > I am getting a bit confused as to which group should be > > discussing these filtering issues. > > > > > > Could we have a statement from the WG chairs of SIPPING or > > SIMPLE as to whether this, and the moran drafts, are part of > > the scope of SIPPING or SIMPLE. > > > > > > And before you say these are both author drafts, I think we > > do need to charter one of the WGs to do some work in this > > area - I am just not sure of the exact scope yet. > > > > > > Keith > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > > > -----Original Message----- > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > Sent: 06 November 2002 18:24 > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > Subject: [Simple] Multimedia message adaptation Internet-Drafts > > > > > > > > > > > > While these drafts concern event filtering, > too, the subject was > > > > a bit misleading because I lazily just followed > up Tim's e-mail. > > > > > > > > Pekka > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > ptation-framework-00.txt > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > ptation-requirements-00.txt > > > > > > > > Pekka Pessi writes: > > > > >We have submitted two drafts regarding multimedia message > > > > >adaptation. A multimedia message is typically a message > > > > >containing images, audio or video clips and their presentation > > > > >information, e.g., smil. Also, even XML-formatted text may > > > > >require adaptation in some cases. > > > > > > > > >Our goal is to have a framework using SIP, HTTP and MIME that > > > > >allows a person sending multimedia message to adapt the message > > > > >contents suitable to all the recipients. In some cases the > > > > >adaptation can be done by the sending terminal, but we also see > > > > >that an adaptation service would be very useful in many cases. > > > > >Such an adaptation mechanism is used by MMS service provided by > > > > >cellular networks nowadays. > > > > > > > > >The message adaptation work concerns both SIPPING and SIMPLE, > > > > >the requirements I-D lists use cases and requirements for > > > > >multimedia messaging and message adaptation solutions and the > > > > >framework I-D tries to explore possible solutions. > > > > > > > > _______________________________________________ > > > > simple mailing list > > > > simple@mailman.dynamicsoft.com > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > > _______________________________________________ > > 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 Fri Nov 8 09:28: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 JAA19714 for ; Fri, 8 Nov 2002 09:28: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 gA8ET9cD020769; Fri, 8 Nov 2002 09: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 JAA18746; Fri, 8 Nov 2002 09:30: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 JAA18733 for ; Fri, 8 Nov 2002 09:29:32 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA8ET3O21986 for ; Fri, 8 Nov 2002 16:29:04 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Nov 2002 16:29:30 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 16:29:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Message-ID: Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKHJxfnqq4Cok0gRuuISgD/1VlMGgAChXcw To: , , , , Cc: , X-OriginalArrivalTime: 08 Nov 2002 14:29:30.0757 (UTC) FILETIME=[400E8350:01C28733] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA18733 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 Nov 2002 16:29:29 +0200 Content-Transfer-Encoding: 8bit Hi, Is this analogous to media transcoding within a session? Maybe these two cases should be handled somewhat similarly. The general framework is something like this: - There is a UA supporting media type X/Y (content in SIP message bodies, media setup with SDP offer-answer) - There is another UA supporting media type X/Z - There is a resource somewhere which can convert X/Y to X/Z and vice versa The things to consider: - Should it be a proxy or a UA who needs to detect the need for the conversion? - If it is a UA, how can it manage to discover and use a suitable converter? - If it is a proxy, what information can it use to do the detection? - What about end-to-end security and trust models? - What is the efficiency in the access network, i.e. how many times the content needs to be sent from UA to proxy or proxy to UA? (In theory only once, but in end-to-end scenarios trial and error may the way, and that may not be acceptable.) Are there any BCP-type-of call flows somewhere how media transcoding can or should be handled using current SIP and SDP specifications, taking also into account the possible use of S/MIME? Are similar practices applicaple to SIP payload adaptation? Markus > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 08 November, 2002 14:58 > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > > It seems to me that these filtering drafts concern the > modification of MIME > bodies in SIP messages by intermediaries. This is not exactly an > uncontroversial topic in SIP circles, and therefore I don't > think it is a > foregone conclusion that this is work that some SIP-related WG should > charter. At a high level, these drafts also argue that capability > negotiation should be administered by intermediaries rather > than through an > end-to-end process; this approach may attract some similar > controversy. > > Provided that this is work the community would like to pursue, the > applicability and impact of this mechanism is larger than the > problem of > instant messaging and presence. While clearly, from the > framework, instant > messaging and presence cases are driving this work, it is > applicable to the > general use of SIP events (messaging, I think, is something > of a corner > case). While SIMPLE could certainly spend some time refining > the framework > and requirements related to IM & presence, I imagine that at > a mechanism > stage this work would need to take place in SIPPING. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > Sent: Friday, November 08, 2002 3:47 AM > > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > > Gonzalo.Camarillo@lmf.ericsson.se > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > Hi, > > > > Actually this thread is about two separate things: > > - Event filtering > > - Multimedia message adaptation > > > > Neither of them appears currently on any sippish WG charter > > currently. > > > > Event filtering has been discussed several times and it is > > even mentioned in (but out of scope of) SIP Events RFC. My > > impression has been that people think that it is needed, but > > there has been debate about scope and feasibility. I hope the > > requirements draft will help in that discussion. My own > > opinion is that what is concretely needed in short term is > > some simple filtering definitions for Presence event package. > > More wide-scoped and complex things could be worked upon as > > the understanding accumulates. > > > > Multimedia message adaptation hasn't been yet discussed much. > > I think it is in general a desirable feature, especially for > > relatively small and dumb terminals, which are not easily > > upgradable and may not understand all media formats. > > > > So I propose the WG chairs think where these items would be > > appropriate, and if there is enough interest for them, let's > > put them on the charters. > > > > Markus > > > > > -----Original Message----- > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: 08 November, 2002 5:11 > > > To: Drage, Keith (Keith) > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message > > > adaptationInternet-Drafts > > > > > > > > > Well, I'd like to hear opinions from the participants here . . . > > > > > > Clearly they aren't explicitly on the charter for either > > > group. Do we as > > > yet have a consensus that we need to work on these > > problems? If so, we > > > can consider WHERE to work on them. I suspect SIPPING is > closer to a > > > matching scope than is SIMPLE, but the relevant ADs may have > > > suggestions > > > to make there as well. > > > > > > -- > > > Dean > > > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > > > I am getting a bit confused as to which group should be > > > discussing these filtering issues. > > > > > > > > Could we have a statement from the WG chairs of SIPPING or > > > SIMPLE as to whether this, and the moran drafts, are part of > > > the scope of SIPPING or SIMPLE. > > > > > > > > And before you say these are both author drafts, I think we > > > do need to charter one of the WGs to do some work in this > > > area - I am just not sure of the exact scope yet. > > > > > > > > Keith > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > Tel: +44 1793 776249 > > > > Email: drage@lucent.com > > > > > > > > > -----Original Message----- > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > Sent: 06 November 2002 18:24 > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > > Subject: [Simple] Multimedia message adaptation > Internet-Drafts > > > > > > > > > > > > > > > While these drafts concern event filtering, > > too, the subject was > > > > > a bit misleading because I lazily just followed > > up Tim's e-mail. > > > > > > > > > > Pekka > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > ptation-framework-00.txt > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > ptation-requirements-00.txt > > > > > > > > > > Pekka Pessi writes: > > > > > >We have submitted two drafts regarding multimedia message > > > > > >adaptation. A multimedia message is typically a message > > > > > >containing images, audio or video clips and their > presentation > > > > > >information, e.g., smil. Also, even XML-formatted text may > > > > > >require adaptation in some cases. > > > > > > > > > > >Our goal is to have a framework using SIP, HTTP and MIME that > > > > > >allows a person sending multimedia message to adapt > the message > > > > > >contents suitable to all the recipients. In some cases the > > > > > >adaptation can be done by the sending terminal, but > we also see > > > > > >that an adaptation service would be very useful in > many cases. > > > > > >Such an adaptation mechanism is used by MMS service > provided by > > > > > >cellular networks nowadays. > > > > > > > > > > >The message adaptation work concerns both SIPPING and SIMPLE, > > > > > >the requirements I-D lists use cases and requirements for > > > > > >multimedia messaging and message adaptation solutions and the > > > > > >framework I-D tries to explore possible solutions. > > > > > > > > > > _______________________________________________ > > > > > simple mailing list > > > > > simple@mailman.dynamicsoft.com > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > > 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 Fri Nov 8 11:38:24 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 LAA26252 for ; Fri, 8 Nov 2002 11:38:24 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gA8Gd9cD021513; Fri, 8 Nov 2002 11:39:09 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19259; Fri, 8 Nov 2002 11:40:05 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19246 for ; Fri, 8 Nov 2002 11:39:06 -0500 (EST) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H5900J49NFD1N@firewall.wcom.com> for simple@mailman.dynamicsoft.com; Fri, 08 Nov 2002 16:36:01 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H5900301NCTXP@dgismtp03.wcomnet.com>; Fri, 08 Nov 2002 16:35:44 +0000 (GMT) Received: from hsinnreich2 ([166.42.32.115]) by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H590036WNDHQ7@dgismtp03.wcomnet.com>; Fri, 08 Nov 2002 16:34:30 +0000 (GMT) From: Henry Sinnreich Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts In-reply-to: <15A2739B7DAA624D8091C65981D7DA815EB39A@stntexch2.va.neustar.com> To: "'Peterson, Jon'" , Markus.Isomaki@nokia.com, dean.willis@softarmor.com, drage@lucent.com, rohan@cisco.com, Gonzalo.Camarillo@lmf.ericsson.se Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com Message-id: <000201c28744$b66196d0$8ea023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: 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, 08 Nov 2002 10:34:29 -0600 Content-Transfer-Encoding: 7bit I don't think it is a foregone > conclusion that this is work that some SIP-related WG should > charter. I agree that anything that conflicts with e2e should not be ligitimized by any IETF WG. Think of NATs and firewalls... If folks want to implement B2BUA, it should be done on their own responsibility and then live with the consequences. My two cents. Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Peterson, Jon > Sent: Friday, November 08, 2002 6:58 AM > To: 'Markus.Isomaki@nokia.com'; dean.willis@softarmor.com; > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > > It seems to me that these filtering drafts concern the > modification of MIME bodies in SIP messages by > intermediaries. This is not exactly an uncontroversial topic > in SIP circles, and therefore I don't think it is a foregone > conclusion that this is work that some SIP-related WG should > charter. At a high level, these drafts also argue that > capability negotiation should be administered by > intermediaries rather than through an end-to-end process; > this approach may attract some similar controversy. > > Provided that this is work the community would like to > pursue, the applicability and impact of this mechanism is > larger than the problem of instant messaging and presence. > While clearly, from the framework, instant messaging and > presence cases are driving this work, it is applicable to the > general use of SIP events (messaging, I think, is something > of a corner case). While SIMPLE could certainly spend some > time refining the framework and requirements related to IM & > presence, I imagine that at a mechanism stage this work would > need to take place in SIPPING. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > Sent: Friday, November 08, 2002 3:47 AM > > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > > Gonzalo.Camarillo@lmf.ericsson.se > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > Hi, > > > > Actually this thread is about two separate things: > > - Event filtering > > - Multimedia message adaptation > > > > Neither of them appears currently on any sippish WG charter > > currently. > > > > Event filtering has been discussed several times and it is > > even mentioned in (but out of scope of) SIP Events RFC. My > > impression has been that people think that it is needed, but > > there has been debate about scope and feasibility. I hope the > > requirements draft will help in that discussion. My own > > opinion is that what is concretely needed in short term is > > some simple filtering definitions for Presence event package. > > More wide-scoped and complex things could be worked upon as > > the understanding accumulates. > > > > Multimedia message adaptation hasn't been yet discussed much. > > I think it is in general a desirable feature, especially for > > relatively small and dumb terminals, which are not easily > > upgradable and may not understand all media formats. > > > > So I propose the WG chairs think where these items would be > > appropriate, and if there is enough interest for them, let's > > put them on the charters. > > > > Markus > > > > > -----Original Message----- > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: 08 November, 2002 5:11 > > > To: Drage, Keith (Keith) > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message > > > adaptationInternet-Drafts > > > > > > > > > Well, I'd like to hear opinions from the participants here . . . > > > > > > Clearly they aren't explicitly on the charter for either > > > group. Do we as > > > yet have a consensus that we need to work on these > > problems? If so, we > > > can consider WHERE to work on them. I suspect SIPPING is > closer to a > > > matching scope than is SIMPLE, but the relevant ADs may have > > > suggestions to make there as well. > > > > > > -- > > > Dean > > > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > > > I am getting a bit confused as to which group should be > > > discussing these filtering issues. > > > > > > > > Could we have a statement from the WG chairs of SIPPING or > > > SIMPLE as to whether this, and the moran drafts, are part of > > > the scope of SIPPING or SIMPLE. > > > > > > > > And before you say these are both author drafts, I think we > > > do need to charter one of the WGs to do some work in this > > > area - I am just not sure of the exact scope yet. > > > > > > > > Keith > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > Tel: +44 1793 776249 > > > > Email: drage@lucent.com > > > > > > > > > -----Original Message----- > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > Sent: 06 November 2002 18:24 > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > > Subject: [Simple] Multimedia message adaptation > Internet-Drafts > > > > > > > > > > > > > > > While these drafts concern event filtering, > > too, the subject was > > > > > a bit misleading because I lazily just followed > > up Tim's e-mail. > > > > > > > > > > Pekka > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > ptation-framework-00.txt > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > ptation-requirements-00.txt > > > > > > > > > > Pekka Pessi writes: > > > > > >We have submitted two drafts regarding multimedia message > > > > > >adaptation. A multimedia message is typically a message > > > > > >containing images, audio or video clips and their > presentation > > > > > >information, e.g., smil. Also, even XML-formatted text may > > > > > >require adaptation in some cases. > > > > > > > > > > >Our goal is to have a framework using SIP, HTTP and > MIME that > > > > > >allows a person sending multimedia message to adapt > the message > > > > > >contents suitable to all the recipients. In some cases the > > > > > >adaptation can be done by the sending terminal, but > we also see > > > > > >that an adaptation service would be very useful in > many cases. > > > > > >Such an adaptation mechanism is used by MMS service > provided by > > > > > >cellular networks nowadays. > > > > > > > > > > >The message adaptation work concerns both SIPPING > and SIMPLE, > > > > > >the requirements I-D lists use cases and requirements for > > > > > >multimedia messaging and message adaptation > solutions and the > > > > > >framework I-D tries to explore possible solutions. > > > > > > > > > > _______________________________________________ > > > > > simple mailing list > > > > > simple@mailman.dynamicsoft.com > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP Use > > > > sip-implementors@cs.columbia.edu for questions on > current sip Use > > > > sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sip@ietf.org for new developments of core SIP > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 8 12:11: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 MAA28727 for ; Fri, 8 Nov 2002 12:11: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 gA8HC4cD021786; Fri, 8 Nov 2002 12: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 MAA19422; Fri, 8 Nov 2002 12:13:03 -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 MAA19411 for ; Fri, 8 Nov 2002 12:12:54 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA8HCZxF004360; Fri, 8 Nov 2002 09:12:35 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABG61447; Fri, 8 Nov 2002 09:10:17 -0800 (PST) Subject: Re: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'Peterson, Jon'" , Markus.Isomaki@nokia.com, dean.willis@softarmor.com, drage@lucent.com, Gonzalo.Camarillo@lmf.ericsson.se, sipping@ietf.org, simple@mailman.dynamicsoft.com To: Henry Sinnreich From: Rohan Mahy In-Reply-To: <000201c28744$b66196d0$8ea023a6@hsinnreich2> Message-Id: <4E0420E8-F33D-11D6-ACCB-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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 Nov 2002 09:12:48 -0800 Content-Transfer-Encoding: 7bit Folks, lets keep this on one list please.... thanks, -rohan On Friday, November 8, 2002, at 08:34 AM, Henry Sinnreich wrote: > I don't think it is a foregone >> conclusion that this is work that some SIP-related WG should >> charter. > > I agree that anything that conflicts with e2e should not be ligitimized > by any IETF WG. Think of NATs and firewalls... > > If folks want to implement B2BUA, it should be done on their own > responsibility and then live with the consequences. My two cents. > > Thanks, Henry > >> -----Original Message----- >> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] >> On Behalf Of Peterson, Jon >> Sent: Friday, November 08, 2002 6:58 AM >> To: 'Markus.Isomaki@nokia.com'; dean.willis@softarmor.com; >> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se >> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com >> Subject: RE: [Sipping] RE: [Simple] Multimedia message >> adaptationInternet-Drafts >> >> >> >> It seems to me that these filtering drafts concern the >> modification of MIME bodies in SIP messages by >> intermediaries. This is not exactly an uncontroversial topic >> in SIP circles, and therefore I don't think it is a foregone >> conclusion that this is work that some SIP-related WG should >> charter. At a high level, these drafts also argue that >> capability negotiation should be administered by >> intermediaries rather than through an end-to-end process; >> this approach may attract some similar controversy. >> >> Provided that this is work the community would like to >> pursue, the applicability and impact of this mechanism is >> larger than the problem of instant messaging and presence. >> While clearly, from the framework, instant messaging and >> presence cases are driving this work, it is applicable to the >> general use of SIP events (messaging, I think, is something >> of a corner case). While SIMPLE could certainly spend some >> time refining the framework and requirements related to IM & >> presence, I imagine that at a mechanism stage this work would >> need to take place in SIPPING. >> >> Jon Peterson >> NeuStar, Inc. >> >>> -----Original Message----- >>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>> Sent: Friday, November 08, 2002 3:47 AM >>> To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; >>> Gonzalo.Camarillo@lmf.ericsson.se >>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com >>> Subject: RE: [Sipping] RE: [Simple] Multimedia message >>> adaptationInternet-Drafts >>> >>> >>> Hi, >>> >>> Actually this thread is about two separate things: >>> - Event filtering >>> - Multimedia message adaptation >>> >>> Neither of them appears currently on any sippish WG charter >>> currently. >>> >>> Event filtering has been discussed several times and it is >>> even mentioned in (but out of scope of) SIP Events RFC. My >>> impression has been that people think that it is needed, but >>> there has been debate about scope and feasibility. I hope the >>> requirements draft will help in that discussion. My own >>> opinion is that what is concretely needed in short term is >>> some simple filtering definitions for Presence event package. >>> More wide-scoped and complex things could be worked upon as >>> the understanding accumulates. >>> >>> Multimedia message adaptation hasn't been yet discussed much. >>> I think it is in general a desirable feature, especially for >>> relatively small and dumb terminals, which are not easily >>> upgradable and may not understand all media formats. >>> >>> So I propose the WG chairs think where these items would be >>> appropriate, and if there is enough interest for them, let's >>> put them on the charters. >>> >>> Markus >>> >>>> -----Original Message----- >>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com] >>>> Sent: 08 November, 2002 5:11 >>>> To: Drage, Keith (Keith) >>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com >>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message >>>> adaptationInternet-Drafts >>>> >>>> >>>> Well, I'd like to hear opinions from the participants here . . . >>>> >>>> Clearly they aren't explicitly on the charter for either >>>> group. Do we as >>>> yet have a consensus that we need to work on these >>> problems? If so, we >>>> can consider WHERE to work on them. I suspect SIPPING is >> closer to a >>>> matching scope than is SIMPLE, but the relevant ADs may have >>>> suggestions to make there as well. >>>> >>>> -- >>>> Dean >>>> >>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: >>>>> I am getting a bit confused as to which group should be >>>> discussing these filtering issues. >>>>> >>>>> Could we have a statement from the WG chairs of SIPPING or >>>> SIMPLE as to whether this, and the moran drafts, are part of >>>> the scope of SIPPING or SIMPLE. >>>>> >>>>> And before you say these are both author drafts, I think we >>>> do need to charter one of the WGs to do some work in this >>>> area - I am just not sure of the exact scope yet. >>>>> >>>>> Keith >>>>> >>>>> Keith Drage >>>>> Lucent Technologies >>>>> Tel: +44 1793 776249 >>>>> Email: drage@lucent.com >>>>> >>>>>> -----Original Message----- >>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] >>>>>> Sent: 06 November 2002 18:24 >>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com >>>>>> Subject: [Simple] Multimedia message adaptation >> Internet-Drafts >>>>>> >>>>>> >>>>>> While these drafts concern event filtering, >>> too, the subject was >>>>>> a bit misleading because I lazily just followed >>> up Tim's e-mail. >>>>>> >>>>>> Pekka >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada >>>>>> ptation-framework-00.txt >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada >>>>>> ptation-requirements-00.txt >>>>>> >>>>>> Pekka Pessi writes: >>>>>>> We have submitted two drafts regarding multimedia message >>>>>>> adaptation. A multimedia message is typically a message >>>>>>> containing images, audio or video clips and their >> presentation >>>>>>> information, e.g., smil. Also, even XML-formatted text may >>>>>>> require adaptation in some cases. >>>>>> >>>>>>> Our goal is to have a framework using SIP, HTTP and >> MIME that >>>>>>> allows a person sending multimedia message to adapt >> the message >>>>>>> contents suitable to all the recipients. In some cases the >>>>>>> adaptation can be done by the sending terminal, but >> we also see >>>>>>> that an adaptation service would be very useful in >> many cases. >>>>>>> Such an adaptation mechanism is used by MMS service >> provided by >>>>>>> cellular networks nowadays. >>>>>> >>>>>>> The message adaptation work concerns both SIPPING >> and SIMPLE, >>>>>>> the requirements I-D lists use cases and requirements for >>>>>>> multimedia messaging and message adaptation >> solutions and the >>>>>>> framework I-D tries to explore possible solutions. >>>>>> >>>>>> _______________________________________________ >>>>>> simple mailing list >>>>>> simple@mailman.dynamicsoft.com >>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple >>>>>> >>>>> _______________________________________________ >>>>> Sipping mailing list >>> https://www1.ietf.org/mailman/listinfo/sipping >>>>> This list is for NEW development of the application of SIP Use >>>>> sip-implementors@cs.columbia.edu for questions on >> current sip Use >>>>> sip@ietf.org for new developments of core SIP >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current >> sip Use sip@ietf.org for new developments of core SIP >> > > _______________________________________________ > 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 Nov 8 16:04: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 QAA14376 for ; Fri, 8 Nov 2002 16:04: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 gA8L5OcD022776; Fri, 8 Nov 2002 16:05:26 -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 QAA20218; Fri, 8 Nov 2002 16:06:09 -0500 (EST) Received: from fmis402r.omnitel.it (srvcw29.omnitelvodafone.it [194.185.48.252] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA20207 for ; Fri, 8 Nov 2002 16:05:54 -0500 (EST) Received: from fmis440.omnitel.it by fmis402r.omnitel.it via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 8 Nov 2002 21:05:53 UT Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB39A@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Markus.Isomaki@nokia.com'" , dean.willis@softarmor.com, drage@lucent.com, rohan@cisco.com, Gonzalo.Camarillo@lmf.ericsson.se Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet- Drafts MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 8 Nov 2002 07:58:21 -0500 It seems to me that these filtering drafts concern the modification of MIME bodies in SIP messages by intermediaries. This is not exactly an uncontroversial topic in SIP circles, and therefore I don't think it is a foregone conclusion that this is work that some SIP-related WG should charter. At a high level, these drafts also argue that capability negotiation should be administered by intermediaries rather than through an end-to-end process; this approach may attract some similar controversy. Provided that this is work the community would like to pursue, the applicability and impact of this mechanism is larger than the problem of instant messaging and presence. While clearly, from the framework, instant messaging and presence cases are driving this work, it is applicable to the general use of SIP events (messaging, I think, is something of a corner case). While SIMPLE could certainly spend some time refining the framework and requirements related to IM & presence, I imagine that at a mechanism stage this work would need to take place in SIPPING. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Friday, November 08, 2002 3:47 AM > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > Hi, > > Actually this thread is about two separate things: > - Event filtering > - Multimedia message adaptation > > Neither of them appears currently on any sippish WG charter > currently. > > Event filtering has been discussed several times and it is > even mentioned in (but out of scope of) SIP Events RFC. My > impression has been that people think that it is needed, but > there has been debate about scope and feasibility. I hope the > requirements draft will help in that discussion. My own > opinion is that what is concretely needed in short term is > some simple filtering definitions for Presence event package. > More wide-scoped and complex things could be worked upon as > the understanding accumulates. > > Multimedia message adaptation hasn't been yet discussed much. > I think it is in general a desirable feature, especially for > relatively small and dumb terminals, which are not easily > upgradable and may not understand all media formats. > > So I propose the WG chairs think where these items would be > appropriate, and if there is enough interest for them, let's > put them on the charters. > > Markus > > > -----Original Message----- > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: 08 November, 2002 5:11 > > To: Drage, Keith (Keith) > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > Subject: Re: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > Well, I'd like to hear opinions from the participants here . . . > > > > Clearly they aren't explicitly on the charter for either > > group. Do we as > > yet have a consensus that we need to work on these > problems? If so, we > > can consider WHERE to work on them. I suspect SIPPING is closer to a > > matching scope than is SIMPLE, but the relevant ADs may have > > suggestions > > to make there as well. > > > > -- > > Dean > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > > I am getting a bit confused as to which group should be > > discussing these filtering issues. > > > > > > Could we have a statement from the WG chairs of SIPPING or > > SIMPLE as to whether this, and the moran drafts, are part of > > the scope of SIPPING or SIMPLE. > > > > > > And before you say these are both author drafts, I think we > > do need to charter one of the WGs to do some work in this > > area - I am just not sure of the exact scope yet. > > > > > > Keith > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > > > -----Original Message----- > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > Sent: 06 November 2002 18:24 > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > Subject: [Simple] Multimedia message adaptation Internet-Drafts > > > > > > > > > > > > While these drafts concern event filtering, > too, the subject was > > > > a bit misleading because I lazily just followed > up Tim's e-mail. > > > > > > > > Pekka > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > ptation-framework-00.txt > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > ptation-requirements-00.txt > > > > > > > > Pekka Pessi writes: > > > > >We have submitted two drafts regarding multimedia message > > > > >adaptation. A multimedia message is typically a message > > > > >containing images, audio or video clips and their presentation > > > > >information, e.g., smil. Also, even XML-formatted text may > > > > >require adaptation in some cases. > > > > > > > > >Our goal is to have a framework using SIP, HTTP and MIME that > > > > >allows a person sending multimedia message to adapt the message > > > > >contents suitable to all the recipients. In some cases the > > > > >adaptation can be done by the sending terminal, but we also see > > > > >that an adaptation service would be very useful in many cases. > > > > >Such an adaptation mechanism is used by MMS service provided by > > > > >cellular networks nowadays. > > > > > > > > >The message adaptation work concerns both SIPPING and SIMPLE, > > > > >the requirements I-D lists use cases and requirements for > > > > >multimedia messaging and message adaptation solutions and the > > > > >framework I-D tries to explore possible solutions. > > > > > > > > _______________________________________________ > > > > simple mailing list > > > > simple@mailman.dynamicsoft.com > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > > _______________________________________________ > > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 8 16:20: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 QAA15371 for ; Fri, 8 Nov 2002 16:20:14 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gA8LL6cD022898; Fri, 8 Nov 2002 16:21: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 QAA20635; Fri, 8 Nov 2002 16:22:04 -0500 (EST) Received: from fmis402r.omnitel.it (srvcw29.omnitelvodafone.it [194.185.48.252] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA20619 for ; Fri, 8 Nov 2002 16:21:27 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from fmis440.omnitel.it by fmis402r.omnitel.it via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 8 Nov 2002 21:21:26 UT Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Message-ID: Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKHJxfnqq4Cok0gRuuISgD/1VlMGgAChXcw To: , , , , Cc: , X-OriginalArrivalTime: 08 Nov 2002 14:29:30.0757 (UTC) FILETIME=[400E8350:01C28733] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA8ETbv28657 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 8 Nov 2002 16:29:29 +0200 Content-Transfer-Encoding: 8bit Hi, Is this analogous to media transcoding within a session? Maybe these two cases should be handled somewhat similarly. The general framework is something like this: - There is a UA supporting media type X/Y (content in SIP message bodies, media setup with SDP offer-answer) - There is another UA supporting media type X/Z - There is a resource somewhere which can convert X/Y to X/Z and vice versa The things to consider: - Should it be a proxy or a UA who needs to detect the need for the conversion? - If it is a UA, how can it manage to discover and use a suitable converter? - If it is a proxy, what information can it use to do the detection? - What about end-to-end security and trust models? - What is the efficiency in the access network, i.e. how many times the content needs to be sent from UA to proxy or proxy to UA? (In theory only once, but in end-to-end scenarios trial and error may the way, and that may not be acceptable.) Are there any BCP-type-of call flows somewhere how media transcoding can or should be handled using current SIP and SDP specifications, taking also into account the possible use of S/MIME? Are similar practices applicaple to SIP payload adaptation? Markus > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 08 November, 2002 14:58 > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > > It seems to me that these filtering drafts concern the > modification of MIME > bodies in SIP messages by intermediaries. This is not exactly an > uncontroversial topic in SIP circles, and therefore I don't > think it is a > foregone conclusion that this is work that some SIP-related WG should > charter. At a high level, these drafts also argue that capability > negotiation should be administered by intermediaries rather > than through an > end-to-end process; this approach may attract some similar > controversy. > > Provided that this is work the community would like to pursue, the > applicability and impact of this mechanism is larger than the > problem of > instant messaging and presence. While clearly, from the > framework, instant > messaging and presence cases are driving this work, it is > applicable to the > general use of SIP events (messaging, I think, is something > of a corner > case). While SIMPLE could certainly spend some time refining > the framework > and requirements related to IM & presence, I imagine that at > a mechanism > stage this work would need to take place in SIPPING. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > Sent: Friday, November 08, 2002 3:47 AM > > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > > Gonzalo.Camarillo@lmf.ericsson.se > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > Hi, > > > > Actually this thread is about two separate things: > > - Event filtering > > - Multimedia message adaptation > > > > Neither of them appears currently on any sippish WG charter > > currently. > > > > Event filtering has been discussed several times and it is > > even mentioned in (but out of scope of) SIP Events RFC. My > > impression has been that people think that it is needed, but > > there has been debate about scope and feasibility. I hope the > > requirements draft will help in that discussion. My own > > opinion is that what is concretely needed in short term is > > some simple filtering definitions for Presence event package. > > More wide-scoped and complex things could be worked upon as > > the understanding accumulates. > > > > Multimedia message adaptation hasn't been yet discussed much. > > I think it is in general a desirable feature, especially for > > relatively small and dumb terminals, which are not easily > > upgradable and may not understand all media formats. > > > > So I propose the WG chairs think where these items would be > > appropriate, and if there is enough interest for them, let's > > put them on the charters. > > > > Markus > > > > > -----Original Message----- > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: 08 November, 2002 5:11 > > > To: Drage, Keith (Keith) > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message > > > adaptationInternet-Drafts > > > > > > > > > Well, I'd like to hear opinions from the participants here . . . > > > > > > Clearly they aren't explicitly on the charter for either > > > group. Do we as > > > yet have a consensus that we need to work on these > > problems? If so, we > > > can consider WHERE to work on them. I suspect SIPPING is > closer to a > > > matching scope than is SIMPLE, but the relevant ADs may have > > > suggestions > > > to make there as well. > > > > > > -- > > > Dean > > > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > > > I am getting a bit confused as to which group should be > > > discussing these filtering issues. > > > > > > > > Could we have a statement from the WG chairs of SIPPING or > > > SIMPLE as to whether this, and the moran drafts, are part of > > > the scope of SIPPING or SIMPLE. > > > > > > > > And before you say these are both author drafts, I think we > > > do need to charter one of the WGs to do some work in this > > > area - I am just not sure of the exact scope yet. > > > > > > > > Keith > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > Tel: +44 1793 776249 > > > > Email: drage@lucent.com > > > > > > > > > -----Original Message----- > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > Sent: 06 November 2002 18:24 > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > > Subject: [Simple] Multimedia message adaptation > Internet-Drafts > > > > > > > > > > > > > > > While these drafts concern event filtering, > > too, the subject was > > > > > a bit misleading because I lazily just followed > > up Tim's e-mail. > > > > > > > > > > Pekka > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > ptation-framework-00.txt > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > ptation-requirements-00.txt > > > > > > > > > > Pekka Pessi writes: > > > > > >We have submitted two drafts regarding multimedia message > > > > > >adaptation. A multimedia message is typically a message > > > > > >containing images, audio or video clips and their > presentation > > > > > >information, e.g., smil. Also, even XML-formatted text may > > > > > >require adaptation in some cases. > > > > > > > > > > >Our goal is to have a framework using SIP, HTTP and MIME that > > > > > >allows a person sending multimedia message to adapt > the message > > > > > >contents suitable to all the recipients. In some cases the > > > > > >adaptation can be done by the sending terminal, but > we also see > > > > > >that an adaptation service would be very useful in > many cases. > > > > > >Such an adaptation mechanism is used by MMS service > provided by > > > > > >cellular networks nowadays. > > > > > > > > > > >The message adaptation work concerns both SIPPING and SIMPLE, > > > > > >the requirements I-D lists use cases and requirements for > > > > > >multimedia messaging and message adaptation solutions and the > > > > > >framework I-D tries to explore possible solutions. > > > > > > > > > > _______________________________________________ > > > > > simple mailing list > > > > > simple@mailman.dynamicsoft.com > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 8 16:32: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 QAA15963 for ; Fri, 8 Nov 2002 16:32: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 gA8LX3cD023010; Fri, 8 Nov 2002 16:33: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 QAA21040; Fri, 8 Nov 2002 16:34:03 -0500 (EST) Received: from fmis401r.omnitel.it (srvcw29.omnitelvodafone.it [194.185.48.252] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA21024 for ; Fri, 8 Nov 2002 16:33:05 -0500 (EST) Received: from fmis440.omnitel.it by fmis401r.omnitel.it via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 8 Nov 2002 21:33:04 UT Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) X-Authentication-Warning: kevlar.softarmor.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: Re: [Sipping] RE: [Simple] Multimedia message adaptation Internet-Drafts From: Dean Willis To: "Drage"@vodafoneomnitel.it Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com In-Reply-To: <475FF955A05DD411980D00508B6D5FB00696E509@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00696E509@en0033exch001u.uk.lucent.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Message-Id: <1036725050.20411.2.camel@kevlar.softarmor.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 07 Nov 2002 21:10:50 -0600 Content-Transfer-Encoding: 7bit Well, I'd like to hear opinions from the participants here . . . Clearly they aren't explicitly on the charter for either group. Do we as yet have a consensus that we need to work on these problems? If so, we can consider WHERE to work on them. I suspect SIPPING is closer to a matching scope than is SIMPLE, but the relevant ADs may have suggestions to make there as well. -- Dean On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > I am getting a bit confused as to which group should be discussing these filtering issues. > > Could we have a statement from the WG chairs of SIPPING or SIMPLE as to whether this, and the moran drafts, are part of the scope of SIPPING or SIMPLE. > > And before you say these are both author drafts, I think we do need to charter one of the WGs to do some work in this area - I am just not sure of the exact scope yet. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > Sent: 06 November 2002 18:24 > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > Subject: [Simple] Multimedia message adaptation Internet-Drafts > > > > > > While these drafts concern event filtering, too, the subject was > > a bit misleading because I lazily just followed up Tim's e-mail. > > > > Pekka > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > ptation-framework-00.txt > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > ptation-requirements-00.txt > > > > Pekka Pessi writes: > > >We have submitted two drafts regarding multimedia message > > >adaptation. A multimedia message is typically a message > > >containing images, audio or video clips and their presentation > > >information, e.g., smil. Also, even XML-formatted text may > > >require adaptation in some cases. > > > > >Our goal is to have a framework using SIP, HTTP and MIME that > > >allows a person sending multimedia message to adapt the message > > >contents suitable to all the recipients. In some cases the > > >adaptation can be done by the sending terminal, but we also see > > >that an adaptation service would be very useful in many cases. > > >Such an adaptation mechanism is used by MMS service provided by > > >cellular networks nowadays. > > > > >The message adaptation work concerns both SIPPING and SIMPLE, > > >the requirements I-D lists use cases and requirements for > > >multimedia messaging and message adaptation solutions and the > > >framework I-D tries to explore possible solutions. > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 8 16: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 QAA18072 for ; Fri, 8 Nov 2002 16: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 gA8M04cD023242; Fri, 8 Nov 2002 17: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 RAA21449; Fri, 8 Nov 2002 17:01:04 -0500 (EST) Received: from fmis402r.omnitel.it (srvcw29.omnitelvodafone.it [194.185.48.252] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA21430 for ; Fri, 8 Nov 2002 17:00:40 -0500 (EST) Received: from fmis439.omnitel.it by fmis402r.omnitel.it via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 8 Nov 2002 22:00:40 UT Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) From: Henry Sinnreich Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts In-reply-to: <15A2739B7DAA624D8091C65981D7DA815EB39A@stntexch2.va.neustar.com> To: "'Peterson"@vodafoneomnitel.it Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com Message-id: <000201c28744$b66196d0$8ea023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 08 Nov 2002 10:34:29 -0600 Content-Transfer-Encoding: 7bit I don't think it is a foregone > conclusion that this is work that some SIP-related WG should > charter. I agree that anything that conflicts with e2e should not be ligitimized by any IETF WG. Think of NATs and firewalls... If folks want to implement B2BUA, it should be done on their own responsibility and then live with the consequences. My two cents. Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Peterson, Jon > Sent: Friday, November 08, 2002 6:58 AM > To: 'Markus.Isomaki@nokia.com'; dean.willis@softarmor.com; > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > > It seems to me that these filtering drafts concern the > modification of MIME bodies in SIP messages by > intermediaries. This is not exactly an uncontroversial topic > in SIP circles, and therefore I don't think it is a foregone > conclusion that this is work that some SIP-related WG should > charter. At a high level, these drafts also argue that > capability negotiation should be administered by > intermediaries rather than through an end-to-end process; > this approach may attract some similar controversy. > > Provided that this is work the community would like to > pursue, the applicability and impact of this mechanism is > larger than the problem of instant messaging and presence. > While clearly, from the framework, instant messaging and > presence cases are driving this work, it is applicable to the > general use of SIP events (messaging, I think, is something > of a corner case). While SIMPLE could certainly spend some > time refining the framework and requirements related to IM & > presence, I imagine that at a mechanism stage this work would > need to take place in SIPPING. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > Sent: Friday, November 08, 2002 3:47 AM > > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > > Gonzalo.Camarillo@lmf.ericsson.se > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > Hi, > > > > Actually this thread is about two separate things: > > - Event filtering > > - Multimedia message adaptation > > > > Neither of them appears currently on any sippish WG charter > > currently. > > > > Event filtering has been discussed several times and it is > > even mentioned in (but out of scope of) SIP Events RFC. My > > impression has been that people think that it is needed, but > > there has been debate about scope and feasibility. I hope the > > requirements draft will help in that discussion. My own > > opinion is that what is concretely needed in short term is > > some simple filtering definitions for Presence event package. > > More wide-scoped and complex things could be worked upon as > > the understanding accumulates. > > > > Multimedia message adaptation hasn't been yet discussed much. > > I think it is in general a desirable feature, especially for > > relatively small and dumb terminals, which are not easily > > upgradable and may not understand all media formats. > > > > So I propose the WG chairs think where these items would be > > appropriate, and if there is enough interest for them, let's > > put them on the charters. > > > > Markus > > > > > -----Original Message----- > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: 08 November, 2002 5:11 > > > To: Drage, Keith (Keith) > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message > > > adaptationInternet-Drafts > > > > > > > > > Well, I'd like to hear opinions from the participants here . . . > > > > > > Clearly they aren't explicitly on the charter for either > > > group. Do we as > > > yet have a consensus that we need to work on these > > problems? If so, we > > > can consider WHERE to work on them. I suspect SIPPING is > closer to a > > > matching scope than is SIMPLE, but the relevant ADs may have > > > suggestions to make there as well. > > > > > > -- > > > Dean > > > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > > > I am getting a bit confused as to which group should be > > > discussing these filtering issues. > > > > > > > > Could we have a statement from the WG chairs of SIPPING or > > > SIMPLE as to whether this, and the moran drafts, are part of > > > the scope of SIPPING or SIMPLE. > > > > > > > > And before you say these are both author drafts, I think we > > > do need to charter one of the WGs to do some work in this > > > area - I am just not sure of the exact scope yet. > > > > > > > > Keith > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > Tel: +44 1793 776249 > > > > Email: drage@lucent.com > > > > > > > > > -----Original Message----- > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > Sent: 06 November 2002 18:24 > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > > Subject: [Simple] Multimedia message adaptation > Internet-Drafts > > > > > > > > > > > > > > > While these drafts concern event filtering, > > too, the subject was > > > > > a bit misleading because I lazily just followed > > up Tim's e-mail. > > > > > > > > > > Pekka > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > ptation-framework-00.txt > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > ptation-requirements-00.txt > > > > > > > > > > Pekka Pessi writes: > > > > > >We have submitted two drafts regarding multimedia message > > > > > >adaptation. A multimedia message is typically a message > > > > > >containing images, audio or video clips and their > presentation > > > > > >information, e.g., smil. Also, even XML-formatted text may > > > > > >require adaptation in some cases. > > > > > > > > > > >Our goal is to have a framework using SIP, HTTP and > MIME that > > > > > >allows a person sending multimedia message to adapt > the message > > > > > >contents suitable to all the recipients. In some cases the > > > > > >adaptation can be done by the sending terminal, but > we also see > > > > > >that an adaptation service would be very useful in > many cases. > > > > > >Such an adaptation mechanism is used by MMS service > provided by > > > > > >cellular networks nowadays. > > > > > > > > > > >The message adaptation work concerns both SIPPING > and SIMPLE, > > > > > >the requirements I-D lists use cases and requirements for > > > > > >multimedia messaging and message adaptation > solutions and the > > > > > >framework I-D tries to explore possible solutions. > > > > > > > > > > _______________________________________________ > > > > > simple mailing list > > > > > simple@mailman.dynamicsoft.com > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP Use > > > > sip-implementors@cs.columbia.edu for questions on > current sip Use > > > > sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 8 17:56: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 RAA21081 for ; Fri, 8 Nov 2002 17:56: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 gA8Mv7cD023468; Fri, 8 Nov 2002 17:57: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 RAA21960; Fri, 8 Nov 2002 17:58:04 -0500 (EST) Received: from fmis402r.omnitel.it (srvcw29.omnitelvodafone.it [194.185.48.252] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA21949 for ; Fri, 8 Nov 2002 17:57:13 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from fmis439.omnitel.it by fmis402r.omnitel.it via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 8 Nov 2002 22:57:13 UT Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Message-ID: Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKG1KTa2SE/J0KdTJCVUzzcD3eDCAARX8MA To: , , , Cc: , X-OriginalArrivalTime: 08 Nov 2002 11:46:37.0845 (UTC) FILETIME=[7EF27C50:01C2871C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA8Bkiv17070 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 8 Nov 2002 13:46:36 +0200 Content-Transfer-Encoding: 8bit Hi, Actually this thread is about two separate things: - Event filtering - Multimedia message adaptation Neither of them appears currently on any sippish WG charter currently. Event filtering has been discussed several times and it is even mentioned in (but out of scope of) SIP Events RFC. My impression has been that people think that it is needed, but there has been debate about scope and feasibility. I hope the requirements draft will help in that discussion. My own opinion is that what is concretely needed in short term is some simple filtering definitions for Presence event package. More wide-scoped and complex things could be worked upon as the understanding accumulates. Multimedia message adaptation hasn't been yet discussed much. I think it is in general a desirable feature, especially for relatively small and dumb terminals, which are not easily upgradable and may not understand all media formats. So I propose the WG chairs think where these items would be appropriate, and if there is enough interest for them, let's put them on the charters. Markus > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 08 November, 2002 5:11 > To: Drage, Keith (Keith) > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > Subject: Re: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > Well, I'd like to hear opinions from the participants here . . . > > Clearly they aren't explicitly on the charter for either > group. Do we as > yet have a consensus that we need to work on these problems? If so, we > can consider WHERE to work on them. I suspect SIPPING is closer to a > matching scope than is SIMPLE, but the relevant ADs may have > suggestions > to make there as well. > > -- > Dean > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > I am getting a bit confused as to which group should be > discussing these filtering issues. > > > > Could we have a statement from the WG chairs of SIPPING or > SIMPLE as to whether this, and the moran drafts, are part of > the scope of SIPPING or SIMPLE. > > > > And before you say these are both author drafts, I think we > do need to charter one of the WGs to do some work in this > area - I am just not sure of the exact scope yet. > > > > Keith > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > > -----Original Message----- > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > Sent: 06 November 2002 18:24 > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > Subject: [Simple] Multimedia message adaptation Internet-Drafts > > > > > > > > > While these drafts concern event filtering, too, the subject was > > > a bit misleading because I lazily just followed up Tim's e-mail. > > > > > > Pekka > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > ptation-framework-00.txt > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > ptation-requirements-00.txt > > > > > > Pekka Pessi writes: > > > >We have submitted two drafts regarding multimedia message > > > >adaptation. A multimedia message is typically a message > > > >containing images, audio or video clips and their presentation > > > >information, e.g., smil. Also, even XML-formatted text may > > > >require adaptation in some cases. > > > > > > >Our goal is to have a framework using SIP, HTTP and MIME that > > > >allows a person sending multimedia message to adapt the message > > > >contents suitable to all the recipients. In some cases the > > > >adaptation can be done by the sending terminal, but we also see > > > >that an adaptation service would be very useful in many cases. > > > >Such an adaptation mechanism is used by MMS service provided by > > > >cellular networks nowadays. > > > > > > >The message adaptation work concerns both SIPPING and SIMPLE, > > > >the requirements I-D lists use cases and requirements for > > > >multimedia messaging and message adaptation solutions and the > > > >framework I-D tries to explore possible solutions. > > > > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 8 18:49: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 SAA22808 for ; Fri, 8 Nov 2002 18:49:16 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gA8No7cD023695; Fri, 8 Nov 2002 18:50: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 SAA22531; Fri, 8 Nov 2002 18:51:04 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22519 for ; Fri, 8 Nov 2002 18:50:11 -0500 (EST) From: Stephane.Coulombe@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA8Np9X18053 for ; Fri, 8 Nov 2002 17:51:09 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Nov 2002 17:50:10 -0600 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 15:50:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Message-ID: <97C16120D52CD249ADE310B69842D5B9796982@daebe004.americas.nokia.com> Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKHa5CNEMtfRz3cQRuNgd/C/YnuKwADld2A To: , , , , , Cc: , , , X-OriginalArrivalTime: 08 Nov 2002 23:50:09.0871 (UTC) FILETIME=[9287F5F0:01C28781] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id SAA22519 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 Nov 2002 17:50:08 -0600 Content-Transfer-Encoding: 8bit Hi, > At a high level, these drafts also argue that capability > negotiation should be administered by intermediaries rather than through an > end-to-end process; this approach may attract some similar controversy. Proposed capability negotiation can be used both ways (end-to-end or administered by intermediaries). 1) end-to-end: Someone who wants to send an Instant Message to another user can send an OPTION query to learn about its terminal capabilities and then create a message within its capabilities. I guess this is not controversial. However how realistic and usable is it in practice? When composing a message, would a user really want to take into consideration the image formats to use, message size limitation, etc? For instance, you want to send a PNG image to a friend and his terminal only supports GIF format. What are you supposed to do? Find an image conversion tool to convert to GIF? This is annoying if you are using a PC, imagine with a mobile phone or handheld? For usability reasons, the user wants to send a message without caring "too much" about what the other end is supporting. 2)administered by intermediaries: this is discussed in detail in one of the drafts. Performing adaptation in the network is controversial but this is the only way to support interoperability and good user experience. > the applicability and impact of this mechanism is larger than the problem of > instant messaging and presence. While clearly, from the framework, instant > messaging and presence cases are driving this work, it is applicable to the > general use of SIP events (messaging, I think, is something of a corner case). Yes, applicability and impact is larger than IM and presence. It applies to many other applications including the case of audio/video conferencing (for instance when there is no common audio or video codec between two ends). The drafts use the "corner case" of SIP IM for a few reasons: 1) In SIP IM, there is no concept of capability negotiation (unlike the case of sessions using SDP). A user sends a message without knowing anything about the recipient's terminal capabilities. 2) In SIP IM, it easier to argue that there will be interoperability problems because of the variety of content types that could be sent (in audio/video session codecs are typically more agreed on). Right now text is mostly used but richer content will soon be used as is the case in Multimedia Messaging Service (MMS). By the way, message adaptation is a serious issue in MMS because of fast product capability evolution. It's hard to keep interoperability while not restricting new phones to send just "low-end" content. 3) It is easier to explain the problem and propose a solution with a smaller well-defined problem. Once we agree that SIP message adaptation is required, the requirements and solutions should be established from global perspective; not just SIP IM. For that reason, SIPPING may be the most appropriate place to initiate this activity. Stephane -----Original Message----- From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, November 08, 2002 6:58 AM To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts It seems to me that these filtering drafts concern the modification of MIME bodies in SIP messages by intermediaries. This is not exactly an uncontroversial topic in SIP circles, and therefore I don't think it is a foregone conclusion that this is work that some SIP-related WG should charter. At a high level, these drafts also argue that capability negotiation should be administered by intermediaries rather than through an end-to-end process; this approach may attract some similar controversy. Provided that this is work the community would like to pursue, the applicability and impact of this mechanism is larger than the problem of instant messaging and presence. While clearly, from the framework, instant messaging and presence cases are driving this work, it is applicable to the general use of SIP events (messaging, I think, is something of a corner case). While SIMPLE could certainly spend some time refining the framework and requirements related to IM & presence, I imagine that at a mechanism stage this work would need to take place in SIPPING. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Friday, November 08, 2002 3:47 AM > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > Hi, > > Actually this thread is about two separate things: > - Event filtering > - Multimedia message adaptation > > Neither of them appears currently on any sippish WG charter > currently. > > Event filtering has been discussed several times and it is > even mentioned in (but out of scope of) SIP Events RFC. My > impression has been that people think that it is needed, but > there has been debate about scope and feasibility. I hope the > requirements draft will help in that discussion. My own > opinion is that what is concretely needed in short term is > some simple filtering definitions for Presence event package. > More wide-scoped and complex things could be worked upon as > the understanding accumulates. > > Multimedia message adaptation hasn't been yet discussed much. > I think it is in general a desirable feature, especially for > relatively small and dumb terminals, which are not easily > upgradable and may not understand all media formats. > > So I propose the WG chairs think where these items would be > appropriate, and if there is enough interest for them, let's > put them on the charters. > > Markus > > > -----Original Message----- > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: 08 November, 2002 5:11 > > To: Drage, Keith (Keith) > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > Subject: Re: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > Well, I'd like to hear opinions from the participants here . . . > > > > Clearly they aren't explicitly on the charter for either > > group. Do we as > > yet have a consensus that we need to work on these > problems? If so, we > > can consider WHERE to work on them. I suspect SIPPING is closer to a > > matching scope than is SIMPLE, but the relevant ADs may have > > suggestions > > to make there as well. > > > > -- > > Dean > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > > I am getting a bit confused as to which group should be > > discussing these filtering issues. > > > > > > Could we have a statement from the WG chairs of SIPPING or > > SIMPLE as to whether this, and the moran drafts, are part of > > the scope of SIPPING or SIMPLE. > > > > > > And before you say these are both author drafts, I think we > > do need to charter one of the WGs to do some work in this > > area - I am just not sure of the exact scope yet. > > > > > > Keith > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > > > -----Original Message----- > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > Sent: 06 November 2002 18:24 > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > Subject: [Simple] Multimedia message adaptation Internet-Drafts > > > > > > > > > > > > While these drafts concern event filtering, > too, the subject was > > > > a bit misleading because I lazily just followed > up Tim's e-mail. > > > > > > > > Pekka > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > ptation-framework-00.txt > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > ptation-requirements-00.txt > > > > > > > > Pekka Pessi writes: > > > > >We have submitted two drafts regarding multimedia message > > > > >adaptation. A multimedia message is typically a message > > > > >containing images, audio or video clips and their presentation > > > > >information, e.g., smil. Also, even XML-formatted text may > > > > >require adaptation in some cases. > > > > > > > > >Our goal is to have a framework using SIP, HTTP and MIME that > > > > >allows a person sending multimedia message to adapt the message > > > > >contents suitable to all the recipients. In some cases the > > > > >adaptation can be done by the sending terminal, but we also see > > > > >that an adaptation service would be very useful in many cases. > > > > >Such an adaptation mechanism is used by MMS service provided by > > > > >cellular networks nowadays. > > > > > > > > >The message adaptation work concerns both SIPPING and SIMPLE, > > > > >the requirements I-D lists use cases and requirements for > > > > >multimedia messaging and message adaptation solutions and the > > > > >framework I-D tries to explore possible solutions. > > > > > > > > _______________________________________________ > > > > simple mailing list > > > > simple@mailman.dynamicsoft.com > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > > _______________________________________________ > > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ 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 Nov 11 09:49: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 JAA20766 for ; Mon, 11 Nov 2002 09:49:09 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gABEnZ5r000952; Mon, 11 Nov 2002 09:49: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 JAA01134; Mon, 11 Nov 2002 09:49:06 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25624 for ; Sat, 9 Nov 2002 12:21:07 -0500 (EST) From: Jose.Costa-Requena@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA9HLeB00006 for ; Sat, 9 Nov 2002 19:21:41 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 9 Nov 2002 19:21:05 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 9 Nov 2002 19:21:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Message-ID: <07A6D72550C5E0459DE676439EE53846CC49C8@esebe012.ntc.nokia.com> Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKHa5CNEMtfRz3cQRuNgd/C/YnuKwADld2AACYMJkA= To: , , , , , , Cc: , , X-OriginalArrivalTime: 09 Nov 2002 17:21:05.0541 (UTC) FILETIME=[62A3A350:01C28814] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA25624 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 Nov 2002 19:21:04 +0200 Content-Transfer-Encoding: 8bit Hi, In addition to Stephane's clarification about the "content adaptation" I-D, I would like to remark the difference between this draft (from Coulombe et al.) and the "filtering" draft (from Tim Moran et al). The aim of "filtering" draft is to define a framework for building the appropriate mechanism within the semantics of SUBS/NOTIF for presence information filtering. Nevertheless, "content adaptation" I-D has a wider scope since it is considering any content-type and it is taking into account the terminal/user preferences. So I would say that it fits into SIPPING WG while the filtering I-D is mainly dealing with presence and I think it should be handled at SIMPLE WG. BR Jose -----Original Message----- From: Coulombe Stephane (NRC/Dallas) Sent: 09. November 2002 1:50 To: ext Peterson, Jon; Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; Pessi Pekka (NRC/Helsinki); Costa-Requena Jose (NMP/Helsinki) Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Hi, > At a high level, these drafts also argue that capability > negotiation should be administered by intermediaries rather than through an > end-to-end process; this approach may attract some similar controversy. Proposed capability negotiation can be used both ways (end-to-end or administered by intermediaries). 1) end-to-end: Someone who wants to send an Instant Message to another user can send an OPTION query to learn about its terminal capabilities and then create a message within its capabilities. I guess this is not controversial. However how realistic and usable is it in practice? When composing a message, would a user really want to take into consideration the image formats to use, message size limitation, etc? For instance, you want to send a PNG image to a friend and his terminal only supports GIF format. What are you supposed to do? Find an image conversion tool to convert to GIF? This is annoying if you are using a PC, imagine with a mobile phone or handheld? For usability reasons, the user wants to send a message without caring "too much" about what the other end is supporting. 2)administered by intermediaries: this is discussed in detail in one of the drafts. Performing adaptation in the network is controversial but this is the only way to support interoperability and good user experience. > the applicability and impact of this mechanism is larger than the problem of > instant messaging and presence. While clearly, from the framework, instant > messaging and presence cases are driving this work, it is applicable to the > general use of SIP events (messaging, I think, is something of a corner case). Yes, applicability and impact is larger than IM and presence. It applies to many other applications including the case of audio/video conferencing (for instance when there is no common audio or video codec between two ends). The drafts use the "corner case" of SIP IM for a few reasons: 1) In SIP IM, there is no concept of capability negotiation (unlike the case of sessions using SDP). A user sends a message without knowing anything about the recipient's terminal capabilities. 2) In SIP IM, it easier to argue that there will be interoperability problems because of the variety of content types that could be sent (in audio/video session codecs are typically more agreed on). Right now text is mostly used but richer content will soon be used as is the case in Multimedia Messaging Service (MMS). By the way, message adaptation is a serious issue in MMS because of fast product capability evolution. It's hard to keep interoperability while not restricting new phones to send just "low-end" content. 3) It is easier to explain the problem and propose a solution with a smaller well-defined problem. Once we agree that SIP message adaptation is required, the requirements and solutions should be established from global perspective; not just SIP IM. For that reason, SIPPING may be the most appropriate place to initiate this activity. Stephane -----Original Message----- From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, November 08, 2002 6:58 AM To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts It seems to me that these filtering drafts concern the modification of MIME bodies in SIP messages by intermediaries. This is not exactly an uncontroversial topic in SIP circles, and therefore I don't think it is a foregone conclusion that this is work that some SIP-related WG should charter. At a high level, these drafts also argue that capability negotiation should be administered by intermediaries rather than through an end-to-end process; this approach may attract some similar controversy. Provided that this is work the community would like to pursue, the applicability and impact of this mechanism is larger than the problem of instant messaging and presence. While clearly, from the framework, instant messaging and presence cases are driving this work, it is applicable to the general use of SIP events (messaging, I think, is something of a corner case). While SIMPLE could certainly spend some time refining the framework and requirements related to IM & presence, I imagine that at a mechanism stage this work would need to take place in SIPPING. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Friday, November 08, 2002 3:47 AM > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > Hi, > > Actually this thread is about two separate things: > - Event filtering > - Multimedia message adaptation > > Neither of them appears currently on any sippish WG charter > currently. > > Event filtering has been discussed several times and it is > even mentioned in (but out of scope of) SIP Events RFC. My > impression has been that people think that it is needed, but > there has been debate about scope and feasibility. I hope the > requirements draft will help in that discussion. My own > opinion is that what is concretely needed in short term is > some simple filtering definitions for Presence event package. > More wide-scoped and complex things could be worked upon as > the understanding accumulates. > > Multimedia message adaptation hasn't been yet discussed much. > I think it is in general a desirable feature, especially for > relatively small and dumb terminals, which are not easily > upgradable and may not understand all media formats. > > So I propose the WG chairs think where these items would be > appropriate, and if there is enough interest for them, let's > put them on the charters. > > Markus > > > -----Original Message----- > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: 08 November, 2002 5:11 > > To: Drage, Keith (Keith) > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > Subject: Re: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > Well, I'd like to hear opinions from the participants here . . . > > > > Clearly they aren't explicitly on the charter for either > > group. Do we as > > yet have a consensus that we need to work on these > problems? If so, we > > can consider WHERE to work on them. I suspect SIPPING is closer to a > > matching scope than is SIMPLE, but the relevant ADs may have > > suggestions > > to make there as well. > > > > -- > > Dean > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > > I am getting a bit confused as to which group should be > > discussing these filtering issues. > > > > > > Could we have a statement from the WG chairs of SIPPING or > > SIMPLE as to whether this, and the moran drafts, are part of > > the scope of SIPPING or SIMPLE. > > > > > > And before you say these are both author drafts, I think we > > do need to charter one of the WGs to do some work in this > > area - I am just not sure of the exact scope yet. > > > > > > Keith > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > > > -----Original Message----- > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > Sent: 06 November 2002 18:24 > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > Subject: [Simple] Multimedia message adaptation Internet-Drafts > > > > > > > > > > > > While these drafts concern event filtering, > too, the subject was > > > > a bit misleading because I lazily just followed > up Tim's e-mail. > > > > > > > > Pekka > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > ptation-framework-00.txt > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > ptation-requirements-00.txt > > > > > > > > Pekka Pessi writes: > > > > >We have submitted two drafts regarding multimedia message > > > > >adaptation. A multimedia message is typically a message > > > > >containing images, audio or video clips and their presentation > > > > >information, e.g., smil. Also, even XML-formatted text may > > > > >require adaptation in some cases. > > > > > > > > >Our goal is to have a framework using SIP, HTTP and MIME that > > > > >allows a person sending multimedia message to adapt the message > > > > >contents suitable to all the recipients. In some cases the > > > > >adaptation can be done by the sending terminal, but we also see > > > > >that an adaptation service would be very useful in many cases. > > > > >Such an adaptation mechanism is used by MMS service provided by > > > > >cellular networks nowadays. > > > > > > > > >The message adaptation work concerns both SIPPING and SIMPLE, > > > > >the requirements I-D lists use cases and requirements for > > > > >multimedia messaging and message adaptation solutions and the > > > > >framework I-D tries to explore possible solutions. > > > > > > > > _______________________________________________ > > > > simple mailing list > > > > simple@mailman.dynamicsoft.com > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > > _______________________________________________ > > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ 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 Nov 11 10:49: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 KAA22848 for ; Mon, 11 Nov 2002 10:49: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 gABFoh5r001261; Mon, 11 Nov 2002 10:50:43 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01378; Mon, 11 Nov 2002 10:51:06 -0500 (EST) Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01365 for ; Mon, 11 Nov 2002 10:50:21 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gABFoM114434 for ; Mon, 11 Nov 2002 09:50:22 -0600 From: Robert Sparks To: simple@mailman.dynamicsoft.com In-Reply-To: <1036698869.12174.51.camel@RjS.localdomain> References: <1036698869.12174.51.camel@RjS.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Message-Id: <1037029451.920.60.camel@RjS.localdomain> Mime-Version: 1.0 Subject: [Simple] Draft agenda SIMPLE IETF55 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: 11 Nov 2002 09:44:07 -0600 Content-Transfer-Encoding: 7bit Folks - Here's a first cut at an agenda for next week's meeting. If I've missed a request, let me know immediately. RjS ------------------------------------------------------------ Monday, Nov 18 2002 1530-1730 Salon III 1530 Administrivia/Agenda Bashing - Chairs 1540 Publish - Sean Olson/Aki Niemi draft-olson-simple-publish-01.txt draft-niemi-simple-publish-framework-00.txt 1600 3GPP IM&P requirements - Aki Niemi draft-niemi-simple-im-wireless-reqs-00.txt draft-kiss-simple-presence-wireless-reqs-01.txt 1610 SIP Presence Extension requirements - Paul Kyzivat draft-kyzivat-simple-prescaps-reqts-00.txt 1620 List Event Templates - Adam Roach draft-roach-sip-list-template-00.txt 1630 Data Requirements - Jonathan Rosenberg draft-ietf-simple-data-req-00.txt 1640 List Manipulation Operations - Markus Isomaki draft-isomaki-simple-list-man-sem-00.txt 1700 Message Sessions - Ben Campbell draft-campbell-simple-im-sessions-00.txt draft-campbell-simple-cpimmsg-sessions-00.txt draft-sparks-simple-jabber-sessions-00.txt _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 12 09:59:23 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 JAA01855 for ; Tue, 12 Nov 2002 09:59: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 gACF055r005412; Tue, 12 Nov 2002 10:00: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 KAA05432; Tue, 12 Nov 2002 10:01:04 -0500 (EST) Received: from snowshore.com (keeper.snowshore.com [216.57.133.4]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05375 for ; Tue, 12 Nov 2002 09:49:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Message-ID: <4A3384433CE2AB46A63468CB207E209D55A7@zoe.office.snowshore.com> Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKHa5CNEMtfRz3cQRuNgd/C/YnuKwADld2AACYMJkAAi+Nw0A== From: "Eric Burger" To: , , , , , , , Cc: , , , "IETF OPES (E-mail)" , "IETF LEMONADE (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA05375 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 Nov 2002 09:49:15 -0500 Content-Transfer-Encoding: 8bit There are already TWO work groups that are considering EXACTLY these transcoding requirements. They are OPES and LEMONADE. I would offer that discussion of these capabilities happen in those groups. If SIP is the appropriate mechanism, then those groups will submit the appropriate drafts to SIPPING, outlining the requirements. > -----Original Message----- From: Jose.Costa-Requena@nokia.com [snip] > Nevertheless, "content adaptation" I-D has a wider scope > since it is considering any content-type and it is taking > into account the terminal/user preferences. So I would say > that it fits into SIPPING WG while the filtering I-D is > mainly dealing with presence and I think it should be handled > at SIMPLE WG. > BR > Jose > > -----Original Message----- From: Coulombe Stephane (NRC/Dallas) > > At a high level, these drafts also argue that capability > > negotiation should be administered by intermediaries rather > than through an > > end-to-end process; this approach may attract some similar > controversy. > > Proposed capability negotiation can be used both ways (end-to-end or > administered by intermediaries). > 1) end-to-end: Someone who wants to send an Instant Message > to another user > can send an OPTION query to learn about its terminal > capabilities and > then create a message within its capabilities. > > I guess this is not controversial. However how > realistic and usable is it in practice? > When composing a message, would a user really want to > take into consideration > the image formats to use, message size limitation, etc? > > For instance, you want to send a PNG image to a friend > and his terminal only supports > GIF format. What are you supposed to do? Find an image > conversion tool to convert to GIF? > This is annoying if you are using a PC, imagine with a > mobile phone or handheld? > > For usability reasons, the user wants to send a message > without caring "too much" about > what the other end is supporting. > > 2)administered by intermediaries: this is discussed in detail > in one of the drafts. > > Performing adaptation in the network is controversial > but this is the only way to support > interoperability and good user experience. > > > the applicability and impact of this mechanism is larger > than the problem of > > instant messaging and presence. While clearly, from the > framework, instant > > messaging and presence cases are driving this work, it is > applicable to the > > general use of SIP events (messaging, I think, is something > of a corner case). > > Yes, applicability and impact is larger than IM and presence. > It applies to many other > applications including the case of audio/video conferencing > (for instance when there is > no common audio or video codec between two ends). > > The drafts use the "corner case" of SIP IM for a few reasons: > 1) In SIP IM, there is no concept of capability negotiation > (unlike the case of sessions using SDP). > A user sends a message without knowing anything about > the recipient's terminal capabilities. > 2) In SIP IM, it easier to argue that there will be > interoperability problems because of the variety of content > types that could be sent (in audio/video session codecs are > typically more agreed on). Right now text is mostly used but > richer content will soon be used as is the case in Multimedia > Messaging Service (MMS). By the way, message adaptation is a > serious issue in MMS because of fast product capability > evolution. It's hard to keep interoperability while not > restricting new phones to send just "low-end" content. > 3) It is easier to explain the problem and propose a solution > with a smaller well-defined problem. > > Once we agree that SIP message adaptation is required, the > requirements and solutions should be established from global > perspective; not just SIP IM. For that reason, SIPPING may be > the most appropriate place to initiate this activity. > > Stephane > > -----Original Message----- > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Friday, November 08, 2002 6:58 AM > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > > It seems to me that these filtering drafts concern the > modification of MIME > bodies in SIP messages by intermediaries. This is not exactly an > uncontroversial topic in SIP circles, and therefore I don't > think it is a > foregone conclusion that this is work that some SIP-related WG should > charter. At a high level, these drafts also argue that capability > negotiation should be administered by intermediaries rather > than through an > end-to-end process; this approach may attract some similar > controversy. > > Provided that this is work the community would like to pursue, the > applicability and impact of this mechanism is larger than the > problem of > instant messaging and presence. While clearly, from the > framework, instant > messaging and presence cases are driving this work, it is > applicable to the > general use of SIP events (messaging, I think, is something > of a corner > case). While SIMPLE could certainly spend some time refining > the framework > and requirements related to IM & presence, I imagine that at > a mechanism > stage this work would need to take place in SIPPING. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > Sent: Friday, November 08, 2002 3:47 AM > > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > > Gonzalo.Camarillo@lmf.ericsson.se > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > Hi, > > > > Actually this thread is about two separate things: > > - Event filtering > > - Multimedia message adaptation > > > > Neither of them appears currently on any sippish WG charter > > currently. > > > > Event filtering has been discussed several times and it is > > even mentioned in (but out of scope of) SIP Events RFC. My > > impression has been that people think that it is needed, but > > there has been debate about scope and feasibility. I hope the > > requirements draft will help in that discussion. My own > > opinion is that what is concretely needed in short term is > > some simple filtering definitions for Presence event package. > > More wide-scoped and complex things could be worked upon as > > the understanding accumulates. > > > > Multimedia message adaptation hasn't been yet discussed much. > > I think it is in general a desirable feature, especially for > > relatively small and dumb terminals, which are not easily > > upgradable and may not understand all media formats. > > > > So I propose the WG chairs think where these items would be > > appropriate, and if there is enough interest for them, let's > > put them on the charters. > > > > Markus > > > > > -----Original Message----- > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: 08 November, 2002 5:11 > > > To: Drage, Keith (Keith) > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message > > > adaptationInternet-Drafts > > > > > > > > > Well, I'd like to hear opinions from the participants here . . . > > > > > > Clearly they aren't explicitly on the charter for either > > > group. Do we as > > > yet have a consensus that we need to work on these > > problems? If so, we > > > can consider WHERE to work on them. I suspect SIPPING is > closer to a > > > matching scope than is SIMPLE, but the relevant ADs may have > > > suggestions > > > to make there as well. > > > > > > -- > > > Dean > > > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > > > I am getting a bit confused as to which group should be > > > discussing these filtering issues. > > > > > > > > Could we have a statement from the WG chairs of SIPPING or > > > SIMPLE as to whether this, and the moran drafts, are part of > > > the scope of SIPPING or SIMPLE. > > > > > > > > And before you say these are both author drafts, I think we > > > do need to charter one of the WGs to do some work in this > > > area - I am just not sure of the exact scope yet. > > > > > > > > Keith > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > Tel: +44 1793 776249 > > > > Email: drage@lucent.com > > > > > > > > > -----Original Message----- > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > Sent: 06 November 2002 18:24 > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > > Subject: [Simple] Multimedia message adaptation > Internet-Drafts > > > > > > > > > > > > > > > While these drafts concern event filtering, > > too, the subject was > > > > > a bit misleading because I lazily just followed > > up Tim's e-mail. > > > > > > > > > > Pekka > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > ptation-framework-00.txt > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > ptation-requirements-00.txt > > > > > > > > > > Pekka Pessi writes: > > > > > >We have submitted two drafts regarding multimedia message > > > > > >adaptation. A multimedia message is typically a message > > > > > >containing images, audio or video clips and their > presentation > > > > > >information, e.g., smil. Also, even XML-formatted text may > > > > > >require adaptation in some cases. > > > > > > > > > > >Our goal is to have a framework using SIP, HTTP and MIME that > > > > > >allows a person sending multimedia message to adapt > the message > > > > > >contents suitable to all the recipients. In some cases the > > > > > >adaptation can be done by the sending terminal, but > we also see > > > > > >that an adaptation service would be very useful in > many cases. > > > > > >Such an adaptation mechanism is used by MMS service > provided by > > > > > >cellular networks nowadays. > > > > > > > > > > >The message adaptation work concerns both SIPPING and SIMPLE, > > > > > >the requirements I-D lists use cases and requirements for > > > > > >multimedia messaging and message adaptation solutions and the > > > > > >framework I-D tries to explore possible solutions. > > > > > > > > > > _______________________________________________ > > > > > simple mailing list > > > > > simple@mailman.dynamicsoft.com > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 12 10:41: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 KAA03380 for ; Tue, 12 Nov 2002 10:41: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 gACFg35r005632; Tue, 12 Nov 2002 10:42: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 KAA05604; Tue, 12 Nov 2002 10:43:03 -0500 (EST) Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05593 for ; Tue, 12 Nov 2002 10:42:07 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gACFg7119643 for ; Tue, 12 Nov 2002 09:42:07 -0600 From: Robert Sparks To: simple@mailman.dynamicsoft.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Message-Id: <1037115354.1012.19.camel@RjS.localdomain> Mime-Version: 1.0 Subject: [Simple] Agenda and drafts 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: 12 Nov 2002 09:35:54 -0600 Content-Transfer-Encoding: 7bit The current agenda and links to the pertaining drafts are posted at http://www.softarmor.com/simple Slides will be posted there as well as I get them (try to get slides to me before the meeting). RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 13 10:22: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 KAA04489 for ; Wed, 13 Nov 2002 10:22: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 gADFNG5r010093; Wed, 13 Nov 2002 10:23: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 KAA09764; Wed, 13 Nov 2002 10:24:11 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09753 for ; Wed, 13 Nov 2002 10:23:55 -0500 (EST) From: bindignavile.srinivas@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gADFObx26262 for ; Wed, 13 Nov 2002 09:24:37 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Nov 2002 09:23:53 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 07:23:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Message-ID: Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKHa5CNEMtfRz3cQRuNgd/C/YnuKwADld2AACYMJkAAi+Nw0AA5bELA To: , , , , , , , , Cc: , , , , X-OriginalArrivalTime: 13 Nov 2002 15:23:53.0225 (UTC) FILETIME=[ACB45F90:01C28B28] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA09753 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 Nov 2002 10:23:51 -0500 Content-Transfer-Encoding: 8bit Hi, As Eric has indicated, the OPES WG is considering transcoding issues! However, presently, rather than being protocol-agnostic, it is being designed for HTTP and RTP only. SIP is not being considered here. -Srini > -----Original Message----- > From: ext Eric Burger [mailto:eburger@snowshore.com] > Sent: Tuesday, November 12, 2002 9:49 AM > To: Costa-Requena Jose (NMP/Helsinki); Coulombe Stephane (NRC/Dallas); > jon.peterson@neustar.biz; Isomaki Markus (NRC/Helsinki); > dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; Pessi Pekka > (NRC/Helsinki); IETF OPES (E-mail); IETF LEMONADE (E-mail) > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > > There are already TWO work groups that are considering > EXACTLY these transcoding requirements. > > They are OPES and LEMONADE. > > I would offer that discussion of these capabilities happen in > those groups. If SIP is the appropriate mechanism, then > those groups will submit the appropriate drafts to SIPPING, > outlining the requirements. > > > -----Original Message----- From: Jose.Costa-Requena@nokia.com > [snip] > > Nevertheless, "content adaptation" I-D has a wider scope > > since it is considering any content-type and it is taking > > into account the terminal/user preferences. So I would say > > that it fits into SIPPING WG while the filtering I-D is > > mainly dealing with presence and I think it should be handled > > at SIMPLE WG. > > BR > > Jose > > > > -----Original Message----- From: Coulombe Stephane (NRC/Dallas) > > > At a high level, these drafts also argue that capability > > > negotiation should be administered by intermediaries rather > > than through an > > > end-to-end process; this approach may attract some similar > > controversy. > > > > Proposed capability negotiation can be used both ways (end-to-end or > > administered by intermediaries). > > 1) end-to-end: Someone who wants to send an Instant Message > > to another user > > can send an OPTION query to learn about its terminal > > capabilities and > > then create a message within its capabilities. > > > > I guess this is not controversial. However how > > realistic and usable is it in practice? > > When composing a message, would a user really want to > > take into consideration > > the image formats to use, message size limitation, etc? > > > > For instance, you want to send a PNG image to a friend > > and his terminal only supports > > GIF format. What are you supposed to do? Find an image > > conversion tool to convert to GIF? > > This is annoying if you are using a PC, imagine with a > > mobile phone or handheld? > > > > For usability reasons, the user wants to send a message > > without caring "too much" about > > what the other end is supporting. > > > > 2)administered by intermediaries: this is discussed in detail > > in one of the drafts. > > > > Performing adaptation in the network is controversial > > but this is the only way to support > > interoperability and good user experience. > > > > > the applicability and impact of this mechanism is larger > > than the problem of > > > instant messaging and presence. While clearly, from the > > framework, instant > > > messaging and presence cases are driving this work, it is > > applicable to the > > > general use of SIP events (messaging, I think, is something > > of a corner case). > > > > Yes, applicability and impact is larger than IM and presence. > > It applies to many other > > applications including the case of audio/video conferencing > > (for instance when there is > > no common audio or video codec between two ends). > > > > The drafts use the "corner case" of SIP IM for a few reasons: > > 1) In SIP IM, there is no concept of capability negotiation > > (unlike the case of sessions using SDP). > > A user sends a message without knowing anything about > > the recipient's terminal capabilities. > > 2) In SIP IM, it easier to argue that there will be > > interoperability problems because of the variety of content > > types that could be sent (in audio/video session codecs are > > typically more agreed on). Right now text is mostly used but > > richer content will soon be used as is the case in Multimedia > > Messaging Service (MMS). By the way, message adaptation is a > > serious issue in MMS because of fast product capability > > evolution. It's hard to keep interoperability while not > > restricting new phones to send just "low-end" content. > > 3) It is easier to explain the problem and propose a solution > > with a smaller well-defined problem. > > > > Once we agree that SIP message adaptation is required, the > > requirements and solutions should be established from global > > perspective; not just SIP IM. For that reason, SIPPING may be > > the most appropriate place to initiate this activity. > > > > Stephane > > > > -----Original Message----- > > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Friday, November 08, 2002 6:58 AM > > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; > > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > > > It seems to me that these filtering drafts concern the > > modification of MIME > > bodies in SIP messages by intermediaries. This is not exactly an > > uncontroversial topic in SIP circles, and therefore I don't > > think it is a > > foregone conclusion that this is work that some SIP-related > WG should > > charter. At a high level, these drafts also argue that capability > > negotiation should be administered by intermediaries rather > > than through an > > end-to-end process; this approach may attract some similar > > controversy. > > > > Provided that this is work the community would like to pursue, the > > applicability and impact of this mechanism is larger than the > > problem of > > instant messaging and presence. While clearly, from the > > framework, instant > > messaging and presence cases are driving this work, it is > > applicable to the > > general use of SIP events (messaging, I think, is something > > of a corner > > case). While SIMPLE could certainly spend some time refining > > the framework > > and requirements related to IM & presence, I imagine that at > > a mechanism > > stage this work would need to take place in SIPPING. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > > Sent: Friday, November 08, 2002 3:47 AM > > > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > > > Gonzalo.Camarillo@lmf.ericsson.se > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > > adaptationInternet-Drafts > > > > > > > > > Hi, > > > > > > Actually this thread is about two separate things: > > > - Event filtering > > > - Multimedia message adaptation > > > > > > Neither of them appears currently on any sippish WG charter > > > currently. > > > > > > Event filtering has been discussed several times and it is > > > even mentioned in (but out of scope of) SIP Events RFC. My > > > impression has been that people think that it is needed, but > > > there has been debate about scope and feasibility. I hope the > > > requirements draft will help in that discussion. My own > > > opinion is that what is concretely needed in short term is > > > some simple filtering definitions for Presence event package. > > > More wide-scoped and complex things could be worked upon as > > > the understanding accumulates. > > > > > > Multimedia message adaptation hasn't been yet discussed much. > > > I think it is in general a desirable feature, especially for > > > relatively small and dumb terminals, which are not easily > > > upgradable and may not understand all media formats. > > > > > > So I propose the WG chairs think where these items would be > > > appropriate, and if there is enough interest for them, let's > > > put them on the charters. > > > > > > Markus > > > > > > > -----Original Message----- > > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > > > Sent: 08 November, 2002 5:11 > > > > To: Drage, Keith (Keith) > > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message > > > > adaptationInternet-Drafts > > > > > > > > > > > > Well, I'd like to hear opinions from the participants here . . . > > > > > > > > Clearly they aren't explicitly on the charter for either > > > > group. Do we as > > > > yet have a consensus that we need to work on these > > > problems? If so, we > > > > can consider WHERE to work on them. I suspect SIPPING is > > closer to a > > > > matching scope than is SIMPLE, but the relevant ADs may have > > > > suggestions > > > > to make there as well. > > > > > > > > -- > > > > Dean > > > > > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > > > > I am getting a bit confused as to which group should be > > > > discussing these filtering issues. > > > > > > > > > > Could we have a statement from the WG chairs of SIPPING or > > > > SIMPLE as to whether this, and the moran drafts, are part of > > > > the scope of SIPPING or SIMPLE. > > > > > > > > > > And before you say these are both author drafts, I think we > > > > do need to charter one of the WGs to do some work in this > > > > area - I am just not sure of the exact scope yet. > > > > > > > > > > Keith > > > > > > > > > > Keith Drage > > > > > Lucent Technologies > > > > > Tel: +44 1793 776249 > > > > > Email: drage@lucent.com > > > > > > > > > > > -----Original Message----- > > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > > Sent: 06 November 2002 18:24 > > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > > > Subject: [Simple] Multimedia message adaptation > > Internet-Drafts > > > > > > > > > > > > > > > > > > While these drafts concern event filtering, > > > too, the subject was > > > > > > a bit misleading because I lazily just followed > > > up Tim's e-mail. > > > > > > > > > > > > Pekka > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > > ptation-framework-00.txt > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > > ptation-requirements-00.txt > > > > > > > > > > > > Pekka Pessi writes: > > > > > > >We have submitted two drafts regarding multimedia message > > > > > > >adaptation. A multimedia message is typically a message > > > > > > >containing images, audio or video clips and their > > presentation > > > > > > >information, e.g., smil. Also, even XML-formatted text may > > > > > > >require adaptation in some cases. > > > > > > > > > > > > >Our goal is to have a framework using SIP, HTTP > and MIME that > > > > > > >allows a person sending multimedia message to adapt > > the message > > > > > > >contents suitable to all the recipients. In some cases the > > > > > > >adaptation can be done by the sending terminal, but > > we also see > > > > > > >that an adaptation service would be very useful in > > many cases. > > > > > > >Such an adaptation mechanism is used by MMS service > > provided by > > > > > > >cellular networks nowadays. > > > > > > > > > > > > >The message adaptation work concerns both SIPPING > and SIMPLE, > > > > > > >the requirements I-D lists use cases and requirements for > > > > > > >multimedia messaging and message adaptation > solutions and the > > > > > > >framework I-D tries to explore possible solutions. > > > > > > > > > > > > _______________________________________________ > > > > > > simple mailing list > > > > > > simple@mailman.dynamicsoft.com > > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP > > > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > 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 Nov 13 10:35: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 KAA05023 for ; Wed, 13 Nov 2002 10:35: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 gADFa15r010210; Wed, 13 Nov 2002 10:36: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 KAA09856; Wed, 13 Nov 2002 10:37:04 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09841 for ; Wed, 13 Nov 2002 10:36:12 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gADFZlKV018978; Wed, 13 Nov 2002 16:35:47 +0100 (MET) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.56]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gADFZkCG000970; Wed, 13 Nov 2002 17:35:46 +0200 (EET) Message-ID: <3DD27151.2D2ADEF8@lmf.ericsson.se> From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bindignavile.srinivas@nokia.com CC: eburger@snowshore.com, Jose.Costa-Requena@nokia.com, Stephane.Coulombe@nokia.com, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com, dean.willis@softarmor.com, drage@lucent.com, rohan@cisco.com, sipping@ietf.org, simple@mailman.dynamicsoft.com, Pekka.Pessi@nokia.com, ietf-openproxy@imc.org, um@snowshore.com Subject: Re: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts 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 Nov 2002 17:35:45 +0200 Content-Transfer-Encoding: 7bit Hi, http://www.ietf.org/internet-drafts/draft-camarillo-sip-deaf-01.txt http://www.ietf.org/internet-drafts/draft-camarillo-sip-deaf-01.pdf and http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-source-sink-00.txt deal with transcoding invocation in SIP and SDP. Gonzalo bindignavile.srinivas@nokia.com wrote: > > Hi, > > As Eric has indicated, the OPES WG is considering transcoding issues! However, presently, rather than being protocol-agnostic, it is being designed for HTTP and RTP only. SIP is not being considered here. > > -Srini _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 13 10:52:19 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 KAA05548 for ; Wed, 13 Nov 2002 10:52:19 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gADFrC5r010329; Wed, 13 Nov 2002 10:53:12 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09958; Wed, 13 Nov 2002 10:54:04 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09825 for ; Wed, 13 Nov 2002 10:35:44 -0500 (EST) From: Jose.Costa-Requena@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 gADFZDO16211 for ; Wed, 13 Nov 2002 17:35:13 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Nov 2002 17:35:35 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 17:35:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Message-ID: <07A6D72550C5E0459DE676439EE53846CC49E4@esebe012.ntc.nokia.com> Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKHa5CNEMtfRz3cQRuNgd/C/YnuKwADld2AACYMJkAAi+Nw0AA5bELAAABf5yA= To: , , , , , , , , Cc: , , , , X-OriginalArrivalTime: 13 Nov 2002 15:35:35.0575 (UTC) FILETIME=[4F567A70:01C28B2A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA09825 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 Nov 2002 17:35:33 +0200 Content-Transfer-Encoding: 8bit Hi, According to LEMONADE requirements, it is considering mainly messaging systems and I agree that this proposal could fit into that context at some extent. Nevertheless, the actual proposal deals with content adaptation based on UA capabilities registered with SIP. Thus, I consider that it is within SIPPING scope, as well. Comments? BR Jose -----Original Message----- From: Srinivas Bindignavile (NRC/Boston) Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Hi, As Eric has indicated, the OPES WG is considering transcoding issues! However, presently, rather than being protocol-agnostic, it is being designed for HTTP and RTP only. SIP is not being considered here. -Srini > -----Original Message----- > From: ext Eric Burger [mailto:eburger@snowshore.com] > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > > There are already TWO work groups that are considering > EXACTLY these transcoding requirements. > > They are OPES and LEMONADE. > > I would offer that discussion of these capabilities happen in > those groups. If SIP is the appropriate mechanism, then > those groups will submit the appropriate drafts to SIPPING, > outlining the requirements. > > > -----Original Message----- From: Jose.Costa-Requena@nokia.com > [snip] > > Nevertheless, "content adaptation" I-D has a wider scope > > since it is considering any content-type and it is taking > > into account the terminal/user preferences. So I would say > > that it fits into SIPPING WG while the filtering I-D is > > mainly dealing with presence and I think it should be handled > > at SIMPLE WG. > > BR > > Jose > > > > -----Original Message----- From: Coulombe Stephane (NRC/Dallas) > > > At a high level, these drafts also argue that capability > > > negotiation should be administered by intermediaries rather > > than through an > > > end-to-end process; this approach may attract some similar > > controversy. > > > > Proposed capability negotiation can be used both ways (end-to-end or > > administered by intermediaries). > > 1) end-to-end: Someone who wants to send an Instant Message > > to another user > > can send an OPTION query to learn about its terminal > > capabilities and > > then create a message within its capabilities. > > > > I guess this is not controversial. However how > > realistic and usable is it in practice? > > When composing a message, would a user really want to > > take into consideration > > the image formats to use, message size limitation, etc? > > > > For instance, you want to send a PNG image to a friend > > and his terminal only supports > > GIF format. What are you supposed to do? Find an image > > conversion tool to convert to GIF? > > This is annoying if you are using a PC, imagine with a > > mobile phone or handheld? > > > > For usability reasons, the user wants to send a message > > without caring "too much" about > > what the other end is supporting. > > > > 2)administered by intermediaries: this is discussed in detail > > in one of the drafts. > > > > Performing adaptation in the network is controversial > > but this is the only way to support > > interoperability and good user experience. > > > > > the applicability and impact of this mechanism is larger > > than the problem of > > > instant messaging and presence. While clearly, from the > > framework, instant > > > messaging and presence cases are driving this work, it is > > applicable to the > > > general use of SIP events (messaging, I think, is something > > of a corner case). > > > > Yes, applicability and impact is larger than IM and presence. > > It applies to many other > > applications including the case of audio/video conferencing > > (for instance when there is > > no common audio or video codec between two ends). > > > > The drafts use the "corner case" of SIP IM for a few reasons: > > 1) In SIP IM, there is no concept of capability negotiation > > (unlike the case of sessions using SDP). > > A user sends a message without knowing anything about > > the recipient's terminal capabilities. > > 2) In SIP IM, it easier to argue that there will be > > interoperability problems because of the variety of content > > types that could be sent (in audio/video session codecs are > > typically more agreed on). Right now text is mostly used but > > richer content will soon be used as is the case in Multimedia > > Messaging Service (MMS). By the way, message adaptation is a > > serious issue in MMS because of fast product capability > > evolution. It's hard to keep interoperability while not > > restricting new phones to send just "low-end" content. > > 3) It is easier to explain the problem and propose a solution > > with a smaller well-defined problem. > > > > Once we agree that SIP message adaptation is required, the > > requirements and solutions should be established from global > > perspective; not just SIP IM. For that reason, SIPPING may be > > the most appropriate place to initiate this activity. > > > > Stephane > > > > -----Original Message----- > > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Friday, November 08, 2002 6:58 AM > > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; > > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > > > It seems to me that these filtering drafts concern the > > modification of MIME > > bodies in SIP messages by intermediaries. This is not exactly an > > uncontroversial topic in SIP circles, and therefore I don't > > think it is a > > foregone conclusion that this is work that some SIP-related > WG should > > charter. At a high level, these drafts also argue that capability > > negotiation should be administered by intermediaries rather > > than through an > > end-to-end process; this approach may attract some similar > > controversy. > > > > Provided that this is work the community would like to pursue, the > > applicability and impact of this mechanism is larger than the > > problem of > > instant messaging and presence. While clearly, from the > > framework, instant > > messaging and presence cases are driving this work, it is > > applicable to the > > general use of SIP events (messaging, I think, is something > > of a corner > > case). While SIMPLE could certainly spend some time refining > > the framework > > and requirements related to IM & presence, I imagine that at > > a mechanism > > stage this work would need to take place in SIPPING. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > > Sent: Friday, November 08, 2002 3:47 AM > > > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > > > Gonzalo.Camarillo@lmf.ericsson.se > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > > adaptationInternet-Drafts > > > > > > > > > Hi, > > > > > > Actually this thread is about two separate things: > > > - Event filtering > > > - Multimedia message adaptation > > > > > > Neither of them appears currently on any sippish WG charter > > > currently. > > > > > > Event filtering has been discussed several times and it is > > > even mentioned in (but out of scope of) SIP Events RFC. My > > > impression has been that people think that it is needed, but > > > there has been debate about scope and feasibility. I hope the > > > requirements draft will help in that discussion. My own > > > opinion is that what is concretely needed in short term is > > > some simple filtering definitions for Presence event package. > > > More wide-scoped and complex things could be worked upon as > > > the understanding accumulates. > > > > > > Multimedia message adaptation hasn't been yet discussed much. > > > I think it is in general a desirable feature, especially for > > > relatively small and dumb terminals, which are not easily > > > upgradable and may not understand all media formats. > > > > > > So I propose the WG chairs think where these items would be > > > appropriate, and if there is enough interest for them, let's > > > put them on the charters. > > > > > > Markus > > > > > > > -----Original Message----- > > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > > > Sent: 08 November, 2002 5:11 > > > > To: Drage, Keith (Keith) > > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message > > > > adaptationInternet-Drafts > > > > > > > > > > > > Well, I'd like to hear opinions from the participants here . . . > > > > > > > > Clearly they aren't explicitly on the charter for either > > > > group. Do we as > > > > yet have a consensus that we need to work on these > > > problems? If so, we > > > > can consider WHERE to work on them. I suspect SIPPING is > > closer to a > > > > matching scope than is SIMPLE, but the relevant ADs may have > > > > suggestions > > > > to make there as well. > > > > > > > > -- > > > > Dean > > > > > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > > > > I am getting a bit confused as to which group should be > > > > discussing these filtering issues. > > > > > > > > > > Could we have a statement from the WG chairs of SIPPING or > > > > SIMPLE as to whether this, and the moran drafts, are part of > > > > the scope of SIPPING or SIMPLE. > > > > > > > > > > And before you say these are both author drafts, I think we > > > > do need to charter one of the WGs to do some work in this > > > > area - I am just not sure of the exact scope yet. > > > > > > > > > > Keith > > > > > > > > > > Keith Drage > > > > > Lucent Technologies > > > > > Tel: +44 1793 776249 > > > > > Email: drage@lucent.com > > > > > > > > > > > -----Original Message----- > > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > > Sent: 06 November 2002 18:24 > > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > > > Subject: [Simple] Multimedia message adaptation > > Internet-Drafts > > > > > > > > > > > > > > > > > > While these drafts concern event filtering, > > > too, the subject was > > > > > > a bit misleading because I lazily just followed > > > up Tim's e-mail. > > > > > > > > > > > > Pekka > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > > ptation-framework-00.txt > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > > ptation-requirements-00.txt > > > > > > > > > > > > Pekka Pessi writes: > > > > > > >We have submitted two drafts regarding multimedia message > > > > > > >adaptation. A multimedia message is typically a message > > > > > > >containing images, audio or video clips and their > > presentation > > > > > > >information, e.g., smil. Also, even XML-formatted text may > > > > > > >require adaptation in some cases. > > > > > > > > > > > > >Our goal is to have a framework using SIP, HTTP > and MIME that > > > > > > >allows a person sending multimedia message to adapt > > the message > > > > > > >contents suitable to all the recipients. In some cases the > > > > > > >adaptation can be done by the sending terminal, but > > we also see > > > > > > >that an adaptation service would be very useful in > > many cases. > > > > > > >Such an adaptation mechanism is used by MMS service > > provided by > > > > > > >cellular networks nowadays. > > > > > > > > > > > > >The message adaptation work concerns both SIPPING > and SIMPLE, > > > > > > >the requirements I-D lists use cases and requirements for > > > > > > >multimedia messaging and message adaptation > solutions and the > > > > > > >framework I-D tries to explore possible solutions. > > > > > > > > > > > > _______________________________________________ > > > > > > simple mailing list > > > > > > simple@mailman.dynamicsoft.com > > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP > > > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > 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 Nov 13 17:05: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 RAA19707 for ; Wed, 13 Nov 2002 17:05: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 gADM6O5r012377; Wed, 13 Nov 2002 17:06: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 RAA11110; Wed, 13 Nov 2002 17:07:15 -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 RAA11099 for ; Wed, 13 Nov 2002 17:06:04 -0500 (EST) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gADM5lU1045392; Wed, 13 Nov 2002 16:05:48 -0600 (CST) Message-ID: <3DD2CCB5.7070703@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 16:05:41 -0600 Content-Transfer-Encoding: 7bit Sorry for the delayed response. My gut tells me this is all way more complicated than it appears to be. Perhaps I am missing something big. Specific comments inline. Jonathan Rosenberg wrote: > inline. > > Paul Kyzivat wrote: > > Jonathan, Ben, > > > > I would be pleased if we can find a way to finesse this. The problem > > is that comedia requires some way to infer, from the sip signaling > > and SDP content, when connections should be made/dropped. Both sides > > must make the same inference, or else the connection establishment > > will fail. As soon as we start to pool connections there starts to be > > the potential for race conditions. > > > > This is especially a problem with connections between two > > intermediaries. The hard question is: when can you ever drop a > > connection between two intermediaries? > > I don't see this as that critical. I would guess that the passive side > of a connection can always close, and the active side would just reopen > if the session isn't terminated. No? I think comedia says you shouldnt > close the connection before the session ends, but sometimes that happens > for a variety of reasons. It should say something about retrying. > > > f course an intermediary > > never knows if its peer in the connection is also an intermediary or > > not, so it must act as if the peer is a UA following the comedia spec > > plus whatever additional rules we can come up with for simple. > > Right. > > > We > > can't drop a connection until we know that there are no sessions > > using it. A corollary to that is that we can't reuse a connection > > that has no sessions using it, because it might be dropped. And so we > > should drop a connection as soon as there are no sessions using it, > > because it is then worthless. > > > > That already starts looking suboptimal, because we must drop > > connections between pairs of high traffic intermediaries any time > > there doesn't happen to be some session traversing them. > > I think you want to decouple the connection lifetimes from the session > lifetimes. > > > > > But I'm not sure this is workable even with that limitation. I have a > > hunch there is still a race condition when one end will think there > > is a connection and attempt to reuse it, while the other end has > > decided there is no session using the connection and tries to drop it > > or establish a new one. This is tricky, and probably impossible to > > decide in general except with respect to a precise rule for reuse. > > But here is one case that seems simpler than some others: So, what happens if you attempt to resuse a connection that is dropped? Won't that fact quickly become apparent? Can't we just reconnect? There may be a complication here in that comedia says you can't just reconnect, you must renegotiate SDP--but scenario under discussion results from an SDP notification, so I am not sure if that requirement is constrainint here. > > > > Suppose we are in the process of establishing a call between > > > > A-----I1-----I2-----B > > > > and there was no connection between I1 and I2. A includes an offer in > > the invite, so I1 and I2 will each rewrite the SDP as the invite goes > > by. But neither I1 nor I2 yet knows if the invite will succeed, so > > don't know if this will result in establishing a connection. > > > > Meanwhile, we start to establish a new call > > > > C-----I1-----I2-----D > > > > C includes an offer in the invite. I1 needs to rewrite the SDP in the > > offer, and would like to reuse the connection it has proposed > > establishing with I2. But it doesn't yet know if that call will > > succeed and so doesn't know if the connection will be established. > > Hence I believe it must assume there will be no connection to reuse, > > This is an artifact of a very bad design choice made by comedia. > > What you REALLY want is that whenever I1 modifies an INVITE, it *always* > puts the same port number/IP into the SDP. Multiple connections can be > established onto that IP/port. Thus, both the INVITE from A and from C, > I1 would place the same IP/port into the SDP. > > Now, if either of those should succeed, I1 will try to open a connection > to that IP/port. If it already has one there, that gets reused. > > So, whats the problem? Well, all intermediaries need to maintain a > routing table, which tells them what to do with incoming messages. That > table tells them that if an IM arrives on some specific connection, with > a specific URI/identifier in the outer envelope, to forward to a > different connection with a different URI/identifier in the outer > envelope. THis means that the intermediary has to associate each > connection with a specific dialog used to set it up (since the dialog is > used to exchange the SDP that contains the URI/identifiers). How is this > association done? I am not sure I understand the difficulty here. These intermediaries surely must be SIP aware, if they are in the business of re-writing SDP. Additionally, it seems to me that they must be dialog stateful devices. Why can't they just maintain a table that associates a dialog with a session, and the session with a connection, where the association between session and connection is many-to-one? If we get SDP describing a new _session_, it will contain address, port, and direction information. A device can check the connection table to determine whether it currently has a connection opened to that particular address and port, can't it? If so, why can't it just start interleaving messages for the new session onto the existing connection? Maybe I am being dense, but I do not understand what problem the connection-id mechanism below is trying to solve. > > Right now, its done with the SOURCE ADDRESS. That is, the SDP sent out > by A in your example contains the source IP/port it will make the > connection from. So, when I1 receives the connection request, it can > determine the source, and then match it to the dialog. The problem is, > this doesn't work at all through NAT. If you don't want to use the > source to demux, the intermediary can arrange for each connection to > occur on a different port, and that means no reuse. So, we have a real > problem. > I will note that comedia says you should _not_ use source address this way unless you are certain your network is free of the blight of NATs. But since a connection can carry more than one session, it makes no sense to try to tie a connection request to a particular dialog. The cpim-msgfmt session draft has its own mechanism for identifying the session. Why can a participating device not relate that to the dialog that set upt he session in the first place? > I registered this complaint about comedia/NAT to mmusic some time back, > but it was ignored. IMHO its still a show stopper. Its especially > heinous when you want to add intermediaries, which wasn't considered at > the time. > > My proposal would be to use connection identifiers separate from > addresses. The SDP contains some kind of parameter that identifies the > connection. Its just a random token. Whenever the connection is opened, > the active side sends, as the first bytes, this identifier. THis way, > the passive side knows which dialog its associated with, without needing > to rely on source IP. > > So, lets go through an example of how this works with a single > intermediary. We've got A----I-----B: > > * A sends an INVITE. SDP has a connection identifier of CID-A1 and a URI > of sip:A1. Through comedia it says it can be both active or passive. Of > course we want it to be active in case its natted. This goes to I. > > * I rewrites the SDP. It places a different IP/port (some common one > used in all requests), and a new connection ID, CID-I1. It rewrites the > address to sip:I1. It also indicates passive only. Note that, since its > passive, the connection ID isn't important. This goes to B. > > * B sends a 200 OK. It indicates active in its SDP. It includes a > connection ID of CID-B1 and URI of sip:B1. > > * I rewrites the SDP in the 200 OK. It includes the same common IP/port, > but yet another connection ID, CID-I2 and URI sip:I2. Forwards to A. > Now, I knows that messages from sip:A1 on either connection CID-I2 or > CID-A1 go to sip:B1, on either connection CID-I1 or CID-B1. Which > connection depends on which direction establishes. > > * A opens a connection to I. Once opened, it passes CID-A1 on the > connection. Now, I knows that this connection corresponds to the dialog > it established with A. Similarly, B opens a connection to I, passes > CID-B1, and I knows that this connection is associated with the dialog > opened to B. Forwarding happens. > > > Now, consider the more complex case, of two intermediaries. So its > A---I---IJ---B. Lets say there is already a connection opened between I > and J. I had indicated a connection ID of CID-I1, and J had indicated > CID-J1. > > * A sends an INVITE. connection ID is new, CID-A1. URI is sip:A1. It > indicates direction:both. Includes some IP/port for receiving connections. > > * I gets the INVITE. Rewrites the SDP to CID-I2 (a new ID - since it > doesn't know who will get this, whether a connection is there already). > Rewrites the URI to sip:I2. Direction passive. Includes its common > IP/port. Sends to J. > > * J gets the INVITE. Rewrites the SDP to CID-J2, also a new ID. Rewrites > the URI to sip:J2. Direction, passive. Includes its common IP/port. > Sends to B. > > * B gets the INVITE. Sends a 200 OK. B notices it doesn't have a > connection to the IP/port indicated by J in the SDP. So, it creates a > new CID, CID-B1, and places that in its SDP, along with direction:active. > > * J gets the 200 OK. J notices that it does have a connection to the > IP/port in the INVITE it received. So, it decides it can reuse that > connection. So, it rewrites the SDP in the 200 OK with CID-J1 (the ID it > had formerly exchanged with I), and indicates a direction of active. > FOrwards to I. > > * I gets the 200 OK. I sees that it DOESNT have a connection to the > IP/port that A provided, so it creates a new connection ID, CID-I3, and > places that in the 200 OK. It indicates a direction of passive. Places > its common IP/port in the SDP, sends to A. > > * Now, the SDP that A got indicated passive. So, it opens a connection > to the IP/port provided by I. It sends its proposed connection ID, > CID-A1 once the connection is opened. > > * The SDP that B got indicated passive. So, it opens a connection to the > IP/port that J provided. It sends its proposed connection ID, CID-B1, > once the connection is opened. > > * I and J realize that the connection IDs exchanged betwen them relate > to an existing connection, so they don't open a new one. > > > If the connection between I and J should close, either side would > re-initiate, and it would reuse the connection ID it had stored and > remembered as associated with the destiation IP/port it needs to open a > connection to. > > > Now, I *think* this works. I'm a bit hazy on the precise rules of usage > and reuse of these connection IDs. THe aim is to do something that > doesnt require a re-INVITE when a new connection is opened. Again - we > want to separate connection lifetime from session lifetime. > > This solution allows for connection reuse and also works smoothly > through NAT without any pains. > > Thoughts? > > -Jonathan R. > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 13 21:00: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 VAA24373 for ; Wed, 13 Nov 2002 21:00: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 gAE21A5r013143; Wed, 13 Nov 2002 21:01: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 VAA11801; Wed, 13 Nov 2002 21:02:07 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA11790 for ; Wed, 13 Nov 2002 21:01:19 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gAE20eu4015989; Wed, 13 Nov 2002 18:00:40 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABH19643; Wed, 13 Nov 2002 17:58:20 -0800 (PST) Subject: Re: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: , , , , , , , , , , , , To: Jose.Costa-Requena@nokia.com From: Rohan Mahy In-Reply-To: <07A6D72550C5E0459DE676439EE53846CC49E4@esebe012.ntc.nokia.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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 Nov 2002 18:00:46 -0800 Content-Transfer-Encoding: 7bit hello, please cease an desist cross posting when you reply. sipping seems like the default wg, so please send your comments only to sipping@ietf.org. thanks, -rohan On Wednesday, November 13, 2002, at 07:35 AM, Jose.Costa-Requena@nokia.com wrote: > Hi, > > According to LEMONADE requirements, it is considering mainly messaging > systems and I agree that this proposal could fit into that context at > some extent. Nevertheless, the actual proposal deals with content > adaptation based on UA capabilities registered with SIP. Thus, I > consider that it is within SIPPING scope, as well. > Comments? > BR > Jose > > -----Original Message----- > From: Srinivas Bindignavile (NRC/Boston) > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > Hi, > > As Eric has indicated, the OPES WG is considering transcoding issues! > However, presently, rather than being protocol-agnostic, it is being > designed for HTTP and RTP only. SIP is not being considered here. > > -Srini > >> -----Original Message----- >> From: ext Eric Burger [mailto:eburger@snowshore.com] >> Subject: RE: [Sipping] RE: [Simple] Multimedia message >> adaptationInternet-Drafts >> >> >> >> There are already TWO work groups that are considering >> EXACTLY these transcoding requirements. >> >> They are OPES and LEMONADE. >> >> I would offer that discussion of these capabilities happen in >> those groups. If SIP is the appropriate mechanism, then >> those groups will submit the appropriate drafts to SIPPING, >> outlining the requirements. >> >>> -----Original Message----- From: Jose.Costa-Requena@nokia.com >> [snip] >>> Nevertheless, "content adaptation" I-D has a wider scope >>> since it is considering any content-type and it is taking >>> into account the terminal/user preferences. So I would say >>> that it fits into SIPPING WG while the filtering I-D is >>> mainly dealing with presence and I think it should be handled >>> at SIMPLE WG. >>> BR >>> Jose >>> >>> -----Original Message----- From: Coulombe Stephane (NRC/Dallas) >>>> At a high level, these drafts also argue that capability >>>> negotiation should be administered by intermediaries rather >>> than through an >>>> end-to-end process; this approach may attract some similar >>> controversy. >>> >>> Proposed capability negotiation can be used both ways (end-to-end or >>> administered by intermediaries). >>> 1) end-to-end: Someone who wants to send an Instant Message >>> to another user >>> can send an OPTION query to learn about its terminal >>> capabilities and >>> then create a message within its capabilities. >>> >>> I guess this is not controversial. However how >>> realistic and usable is it in practice? >>> When composing a message, would a user really want to >>> take into consideration >>> the image formats to use, message size limitation, etc? >>> >>> For instance, you want to send a PNG image to a friend >>> and his terminal only supports >>> GIF format. What are you supposed to do? Find an image >>> conversion tool to convert to GIF? >>> This is annoying if you are using a PC, imagine with a >>> mobile phone or handheld? >>> >>> For usability reasons, the user wants to send a message >>> without caring "too much" about >>> what the other end is supporting. >>> >>> 2)administered by intermediaries: this is discussed in detail >>> in one of the drafts. >>> >>> Performing adaptation in the network is controversial >>> but this is the only way to support >>> interoperability and good user experience. >>> >>>> the applicability and impact of this mechanism is larger >>> than the problem of >>>> instant messaging and presence. While clearly, from the >>> framework, instant >>>> messaging and presence cases are driving this work, it is >>> applicable to the >>>> general use of SIP events (messaging, I think, is something >>> of a corner case). >>> >>> Yes, applicability and impact is larger than IM and presence. >>> It applies to many other >>> applications including the case of audio/video conferencing >>> (for instance when there is >>> no common audio or video codec between two ends). >>> >>> The drafts use the "corner case" of SIP IM for a few reasons: >>> 1) In SIP IM, there is no concept of capability negotiation >>> (unlike the case of sessions using SDP). >>> A user sends a message without knowing anything about >>> the recipient's terminal capabilities. >>> 2) In SIP IM, it easier to argue that there will be >>> interoperability problems because of the variety of content >>> types that could be sent (in audio/video session codecs are >>> typically more agreed on). Right now text is mostly used but >>> richer content will soon be used as is the case in Multimedia >>> Messaging Service (MMS). By the way, message adaptation is a >>> serious issue in MMS because of fast product capability >>> evolution. It's hard to keep interoperability while not >>> restricting new phones to send just "low-end" content. >>> 3) It is easier to explain the problem and propose a solution >>> with a smaller well-defined problem. >>> >>> Once we agree that SIP message adaptation is required, the >>> requirements and solutions should be established from global >>> perspective; not just SIP IM. For that reason, SIPPING may be >>> the most appropriate place to initiate this activity. >>> >>> Stephane >>> >>> -----Original Message----- >>> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] >>> Sent: Friday, November 08, 2002 6:58 AM >>> To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; >>> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se >>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com >>> Subject: RE: [Sipping] RE: [Simple] Multimedia message >>> adaptationInternet-Drafts >>> >>> >>> >>> It seems to me that these filtering drafts concern the >>> modification of MIME >>> bodies in SIP messages by intermediaries. This is not exactly an >>> uncontroversial topic in SIP circles, and therefore I don't >>> think it is a >>> foregone conclusion that this is work that some SIP-related >> WG should >>> charter. At a high level, these drafts also argue that capability >>> negotiation should be administered by intermediaries rather >>> than through an >>> end-to-end process; this approach may attract some similar >>> controversy. >>> >>> Provided that this is work the community would like to pursue, the >>> applicability and impact of this mechanism is larger than the >>> problem of >>> instant messaging and presence. While clearly, from the >>> framework, instant >>> messaging and presence cases are driving this work, it is >>> applicable to the >>> general use of SIP events (messaging, I think, is something >>> of a corner >>> case). While SIMPLE could certainly spend some time refining >>> the framework >>> and requirements related to IM & presence, I imagine that at >>> a mechanism >>> stage this work would need to take place in SIPPING. >>> >>> Jon Peterson >>> NeuStar, Inc. >>> >>>> -----Original Message----- >>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>> Sent: Friday, November 08, 2002 3:47 AM >>>> To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; >>>> Gonzalo.Camarillo@lmf.ericsson.se >>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com >>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message >>>> adaptationInternet-Drafts >>>> >>>> >>>> Hi, >>>> >>>> Actually this thread is about two separate things: >>>> - Event filtering >>>> - Multimedia message adaptation >>>> >>>> Neither of them appears currently on any sippish WG charter >>>> currently. >>>> >>>> Event filtering has been discussed several times and it is >>>> even mentioned in (but out of scope of) SIP Events RFC. My >>>> impression has been that people think that it is needed, but >>>> there has been debate about scope and feasibility. I hope the >>>> requirements draft will help in that discussion. My own >>>> opinion is that what is concretely needed in short term is >>>> some simple filtering definitions for Presence event package. >>>> More wide-scoped and complex things could be worked upon as >>>> the understanding accumulates. >>>> >>>> Multimedia message adaptation hasn't been yet discussed much. >>>> I think it is in general a desirable feature, especially for >>>> relatively small and dumb terminals, which are not easily >>>> upgradable and may not understand all media formats. >>>> >>>> So I propose the WG chairs think where these items would be >>>> appropriate, and if there is enough interest for them, let's >>>> put them on the charters. >>>> >>>> Markus >>>> >>>>> -----Original Message----- >>>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com] >>>>> Sent: 08 November, 2002 5:11 >>>>> To: Drage, Keith (Keith) >>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com >>>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message >>>>> adaptationInternet-Drafts >>>>> >>>>> >>>>> Well, I'd like to hear opinions from the participants here . . . >>>>> >>>>> Clearly they aren't explicitly on the charter for either >>>>> group. Do we as >>>>> yet have a consensus that we need to work on these >>>> problems? If so, we >>>>> can consider WHERE to work on them. I suspect SIPPING is >>> closer to a >>>>> matching scope than is SIMPLE, but the relevant ADs may have >>>>> suggestions >>>>> to make there as well. >>>>> >>>>> -- >>>>> Dean >>>>> >>>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: >>>>>> I am getting a bit confused as to which group should be >>>>> discussing these filtering issues. >>>>>> >>>>>> Could we have a statement from the WG chairs of SIPPING or >>>>> SIMPLE as to whether this, and the moran drafts, are part of >>>>> the scope of SIPPING or SIMPLE. >>>>>> >>>>>> And before you say these are both author drafts, I think we >>>>> do need to charter one of the WGs to do some work in this >>>>> area - I am just not sure of the exact scope yet. >>>>>> >>>>>> Keith >>>>>> >>>>>> Keith Drage >>>>>> Lucent Technologies >>>>>> Tel: +44 1793 776249 >>>>>> Email: drage@lucent.com >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] >>>>>>> Sent: 06 November 2002 18:24 >>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com >>>>>>> Subject: [Simple] Multimedia message adaptation >>> Internet-Drafts >>>>>>> >>>>>>> >>>>>>> While these drafts concern event filtering, >>>> too, the subject was >>>>>>> a bit misleading because I lazily just followed >>>> up Tim's e-mail. >>>>>>> >>>>>>> Pekka >>>>>>> >>>>>>> >> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada >>>>>>> ptation-framework-00.txt >>>>>>> >>>>>>> >> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada >>>>>>> ptation-requirements-00.txt >>>>>>> >>>>>>> Pekka Pessi writes: >>>>>>>> We have submitted two drafts regarding multimedia message >>>>>>>> adaptation. A multimedia message is typically a message >>>>>>>> containing images, audio or video clips and their >>> presentation >>>>>>>> information, e.g., smil. Also, even XML-formatted text may >>>>>>>> require adaptation in some cases. >>>>>>> >>>>>>>> Our goal is to have a framework using SIP, HTTP >> and MIME that >>>>>>>> allows a person sending multimedia message to adapt >>> the message >>>>>>>> contents suitable to all the recipients. In some cases the >>>>>>>> adaptation can be done by the sending terminal, but >>> we also see >>>>>>>> that an adaptation service would be very useful in >>> many cases. >>>>>>>> Such an adaptation mechanism is used by MMS service >>> provided by >>>>>>>> cellular networks nowadays. >>>>>>> >>>>>>>> The message adaptation work concerns both SIPPING >> and SIMPLE, >>>>>>>> the requirements I-D lists use cases and requirements for >>>>>>>> multimedia messaging and message adaptation >> solutions and the >>>>>>>> framework I-D tries to explore possible solutions. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> simple mailing list >>>>>>> simple@mailman.dynamicsoft.com >>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple >>>>>>> >>>>>> _______________________________________________ >>>>>> Sipping mailing list >>>> https://www1.ietf.org/mailman/listinfo/sipping >>>>>> This list is for NEW development of the application of SIP >>>>>> Use sip-implementors@cs.columbia.edu for questions on >>> current sip >>>>>> Use sip@ietf.org for new developments of core SIP >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >>> _______________________________________________ >>> simple mailing list >>> simple@mailman.dynamicsoft.com >>> http://mailman.dynamicsoft.com/mailman/listinfo/simple >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >>> >> _______________________________________________ >> simple mailing list >> simple@mailman.dynamicsoft.com >> http://mailman.dynamicsoft.com/mailman/listinfo/simple >> > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 13 21:04:54 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 VAA24484 for ; Wed, 13 Nov 2002 21:04:53 -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 gAE2435r013165; Wed, 13 Nov 2002 21:04: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 VAA11830; Wed, 13 Nov 2002 21:05:05 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA11813 for ; Wed, 13 Nov 2002 21:03:35 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAE23Y5V029878 for ; Wed, 13 Nov 2002 18:03:34 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABH19663; Wed, 13 Nov 2002 18:01:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v546) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: pls stop cross posting (was Fwd: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts From: Rohan Mahy To: simple@mailman.dynamicsoft.com Content-Transfer-Encoding: 7bit Message-Id: <4890CF3A-F775-11D6-B86C-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.546) 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 Nov 2002 18:03:35 -0800 Content-Transfer-Encoding: 7bit Begin forwarded message: > hello, > > please cease an desist cross posting when you reply. sipping seems > like the default wg, so please send your comments only to > sipping@ietf.org. > > thanks, > -rohan > > On Wednesday, November 13, 2002, at 07:35 AM, > Jose.Costa-Requena@nokia.com wrote: > >> Hi, >> >> According to LEMONADE requirements, it is considering mainly >> messaging systems and I agree that this proposal could fit into that >> context at some extent. Nevertheless, the actual proposal deals with >> content adaptation based on UA capabilities registered with SIP. >> Thus, I consider that it is within SIPPING scope, as well. >> Comments? >> BR >> Jose >> >> -----Original Message----- >> From: Srinivas Bindignavile (NRC/Boston) >> Subject: RE: [Sipping] RE: [Simple] Multimedia message >> adaptationInternet-Drafts >> >> >> Hi, >> >> As Eric has indicated, the OPES WG is considering transcoding issues! >> However, presently, rather than being protocol-agnostic, it is being >> designed for HTTP and RTP only. SIP is not being considered here. >> >> -Srini >> >>> -----Original Message----- >>> From: ext Eric Burger [mailto:eburger@snowshore.com] >>> Subject: RE: [Sipping] RE: [Simple] Multimedia message >>> adaptationInternet-Drafts >>> >>> >>> >>> There are already TWO work groups that are considering >>> EXACTLY these transcoding requirements. >>> >>> They are OPES and LEMONADE. >>> >>> I would offer that discussion of these capabilities happen in >>> those groups. If SIP is the appropriate mechanism, then >>> those groups will submit the appropriate drafts to SIPPING, >>> outlining the requirements. >>> >>>> -----Original Message----- From: Jose.Costa-Requena@nokia.com >>> [snip] >>>> Nevertheless, "content adaptation" I-D has a wider scope >>>> since it is considering any content-type and it is taking >>>> into account the terminal/user preferences. So I would say >>>> that it fits into SIPPING WG while the filtering I-D is >>>> mainly dealing with presence and I think it should be handled >>>> at SIMPLE WG. >>>> BR >>>> Jose >>>> >>>> -----Original Message----- From: Coulombe Stephane (NRC/Dallas) >>>>> At a high level, these drafts also argue that capability >>>>> negotiation should be administered by intermediaries rather >>>> than through an >>>>> end-to-end process; this approach may attract some similar >>>> controversy. >>>> >>>> Proposed capability negotiation can be used both ways (end-to-end or >>>> administered by intermediaries). >>>> 1) end-to-end: Someone who wants to send an Instant Message >>>> to another user >>>> can send an OPTION query to learn about its terminal >>>> capabilities and >>>> then create a message within its capabilities. >>>> >>>> I guess this is not controversial. However how >>>> realistic and usable is it in practice? >>>> When composing a message, would a user really want to >>>> take into consideration >>>> the image formats to use, message size limitation, etc? >>>> >>>> For instance, you want to send a PNG image to a friend >>>> and his terminal only supports >>>> GIF format. What are you supposed to do? Find an image >>>> conversion tool to convert to GIF? >>>> This is annoying if you are using a PC, imagine with a >>>> mobile phone or handheld? >>>> >>>> For usability reasons, the user wants to send a message >>>> without caring "too much" about >>>> what the other end is supporting. >>>> >>>> 2)administered by intermediaries: this is discussed in detail >>>> in one of the drafts. >>>> >>>> Performing adaptation in the network is controversial >>>> but this is the only way to support >>>> interoperability and good user experience. >>>> >>>>> the applicability and impact of this mechanism is larger >>>> than the problem of >>>>> instant messaging and presence. While clearly, from the >>>> framework, instant >>>>> messaging and presence cases are driving this work, it is >>>> applicable to the >>>>> general use of SIP events (messaging, I think, is something >>>> of a corner case). >>>> >>>> Yes, applicability and impact is larger than IM and presence. >>>> It applies to many other >>>> applications including the case of audio/video conferencing >>>> (for instance when there is >>>> no common audio or video codec between two ends). >>>> >>>> The drafts use the "corner case" of SIP IM for a few reasons: >>>> 1) In SIP IM, there is no concept of capability negotiation >>>> (unlike the case of sessions using SDP). >>>> A user sends a message without knowing anything about >>>> the recipient's terminal capabilities. >>>> 2) In SIP IM, it easier to argue that there will be >>>> interoperability problems because of the variety of content >>>> types that could be sent (in audio/video session codecs are >>>> typically more agreed on). Right now text is mostly used but >>>> richer content will soon be used as is the case in Multimedia >>>> Messaging Service (MMS). By the way, message adaptation is a >>>> serious issue in MMS because of fast product capability >>>> evolution. It's hard to keep interoperability while not >>>> restricting new phones to send just "low-end" content. >>>> 3) It is easier to explain the problem and propose a solution >>>> with a smaller well-defined problem. >>>> >>>> Once we agree that SIP message adaptation is required, the >>>> requirements and solutions should be established from global >>>> perspective; not just SIP IM. For that reason, SIPPING may be >>>> the most appropriate place to initiate this activity. >>>> >>>> Stephane >>>> >>>> -----Original Message----- >>>> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] >>>> Sent: Friday, November 08, 2002 6:58 AM >>>> To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; >>>> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se >>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com >>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message >>>> adaptationInternet-Drafts >>>> >>>> >>>> >>>> It seems to me that these filtering drafts concern the >>>> modification of MIME >>>> bodies in SIP messages by intermediaries. This is not exactly an >>>> uncontroversial topic in SIP circles, and therefore I don't >>>> think it is a >>>> foregone conclusion that this is work that some SIP-related >>> WG should >>>> charter. At a high level, these drafts also argue that capability >>>> negotiation should be administered by intermediaries rather >>>> than through an >>>> end-to-end process; this approach may attract some similar >>>> controversy. >>>> >>>> Provided that this is work the community would like to pursue, the >>>> applicability and impact of this mechanism is larger than the >>>> problem of >>>> instant messaging and presence. While clearly, from the >>>> framework, instant >>>> messaging and presence cases are driving this work, it is >>>> applicable to the >>>> general use of SIP events (messaging, I think, is something >>>> of a corner >>>> case). While SIMPLE could certainly spend some time refining >>>> the framework >>>> and requirements related to IM & presence, I imagine that at >>>> a mechanism >>>> stage this work would need to take place in SIPPING. >>>> >>>> Jon Peterson >>>> NeuStar, Inc. >>>> >>>>> -----Original Message----- >>>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>>> Sent: Friday, November 08, 2002 3:47 AM >>>>> To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; >>>>> Gonzalo.Camarillo@lmf.ericsson.se >>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com >>>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message >>>>> adaptationInternet-Drafts >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Actually this thread is about two separate things: >>>>> - Event filtering >>>>> - Multimedia message adaptation >>>>> >>>>> Neither of them appears currently on any sippish WG charter >>>>> currently. >>>>> >>>>> Event filtering has been discussed several times and it is >>>>> even mentioned in (but out of scope of) SIP Events RFC. My >>>>> impression has been that people think that it is needed, but >>>>> there has been debate about scope and feasibility. I hope the >>>>> requirements draft will help in that discussion. My own >>>>> opinion is that what is concretely needed in short term is >>>>> some simple filtering definitions for Presence event package. >>>>> More wide-scoped and complex things could be worked upon as >>>>> the understanding accumulates. >>>>> >>>>> Multimedia message adaptation hasn't been yet discussed much. >>>>> I think it is in general a desirable feature, especially for >>>>> relatively small and dumb terminals, which are not easily >>>>> upgradable and may not understand all media formats. >>>>> >>>>> So I propose the WG chairs think where these items would be >>>>> appropriate, and if there is enough interest for them, let's >>>>> put them on the charters. >>>>> >>>>> Markus >>>>> >>>>>> -----Original Message----- >>>>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com] >>>>>> Sent: 08 November, 2002 5:11 >>>>>> To: Drage, Keith (Keith) >>>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com >>>>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message >>>>>> adaptationInternet-Drafts >>>>>> >>>>>> >>>>>> Well, I'd like to hear opinions from the participants here . . . >>>>>> >>>>>> Clearly they aren't explicitly on the charter for either >>>>>> group. Do we as >>>>>> yet have a consensus that we need to work on these >>>>> problems? If so, we >>>>>> can consider WHERE to work on them. I suspect SIPPING is >>>> closer to a >>>>>> matching scope than is SIMPLE, but the relevant ADs may have >>>>>> suggestions >>>>>> to make there as well. >>>>>> >>>>>> -- >>>>>> Dean >>>>>> >>>>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: >>>>>>> I am getting a bit confused as to which group should be >>>>>> discussing these filtering issues. >>>>>>> >>>>>>> Could we have a statement from the WG chairs of SIPPING or >>>>>> SIMPLE as to whether this, and the moran drafts, are part of >>>>>> the scope of SIPPING or SIMPLE. >>>>>>> >>>>>>> And before you say these are both author drafts, I think we >>>>>> do need to charter one of the WGs to do some work in this >>>>>> area - I am just not sure of the exact scope yet. >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>> Keith Drage >>>>>>> Lucent Technologies >>>>>>> Tel: +44 1793 776249 >>>>>>> Email: drage@lucent.com >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] >>>>>>>> Sent: 06 November 2002 18:24 >>>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com >>>>>>>> Subject: [Simple] Multimedia message adaptation >>>> Internet-Drafts >>>>>>>> >>>>>>>> >>>>>>>> While these drafts concern event filtering, >>>>> too, the subject was >>>>>>>> a bit misleading because I lazily just followed >>>>> up Tim's e-mail. >>>>>>>> >>>>>>>> Pekka >>>>>>>> >>>>>>>> >>> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada >>>>>>>> ptation-framework-00.txt >>>>>>>> >>>>>>>> >>> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada >>>>>>>> ptation-requirements-00.txt >>>>>>>> >>>>>>>> Pekka Pessi writes: >>>>>>>>> We have submitted two drafts regarding multimedia message >>>>>>>>> adaptation. A multimedia message is typically a message >>>>>>>>> containing images, audio or video clips and their >>>> presentation >>>>>>>>> information, e.g., smil. Also, even XML-formatted text may >>>>>>>>> require adaptation in some cases. >>>>>>>> >>>>>>>>> Our goal is to have a framework using SIP, HTTP >>> and MIME that >>>>>>>>> allows a person sending multimedia message to adapt >>>> the message >>>>>>>>> contents suitable to all the recipients. In some cases the >>>>>>>>> adaptation can be done by the sending terminal, but >>>> we also see >>>>>>>>> that an adaptation service would be very useful in >>>> many cases. >>>>>>>>> Such an adaptation mechanism is used by MMS service >>>> provided by >>>>>>>>> cellular networks nowadays. >>>>>>>> >>>>>>>>> The message adaptation work concerns both SIPPING >>> and SIMPLE, >>>>>>>>> the requirements I-D lists use cases and requirements for >>>>>>>>> multimedia messaging and message adaptation >>> solutions and the >>>>>>>>> framework I-D tries to explore possible solutions. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> simple mailing list >>>>>>>> simple@mailman.dynamicsoft.com >>>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Sipping mailing list >>>>> https://www1.ietf.org/mailman/listinfo/sipping >>>>>>> This list is for NEW development of the application of SIP >>>>>>> Use sip-implementors@cs.columbia.edu for questions on >>>> current sip >>>>>>> Use sip@ietf.org for new developments of core SIP >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> _______________________________________________ >>>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>> This list is for NEW development of the application of SIP >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sip@ietf.org for new developments of core SIP >>>> _______________________________________________ >>>> simple mailing list >>>> simple@mailman.dynamicsoft.com >>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple >>>> _______________________________________________ >>>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>> This list is for NEW development of the application of SIP >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sip@ietf.org for new developments of core SIP >>>> >>> _______________________________________________ >>> simple mailing list >>> simple@mailman.dynamicsoft.com >>> http://mailman.dynamicsoft.com/mailman/listinfo/simple >>> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 14 09:45:19 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 JAA20653 for ; Thu, 14 Nov 2002 09:45: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 gAEEk75r015206; Thu, 14 Nov 2002 09:46: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 JAA14137; Thu, 14 Nov 2002 09:47:07 -0500 (EST) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10120 for ; Wed, 13 Nov 2002 11:16:16 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gADGFF019940; Wed, 13 Nov 2002 11:15:15 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Nov 2002 11:15:16 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD7540420D561@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: bindignavile.srinivas@nokia.com, eburger@snowshore.com, Jose.Costa-Requena@nokia.com, Stephane.Coulombe@nokia.com, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com, dean.willis@softarmor.com, drage@lucent.com, rohan@cisco.com, Gonzalo.Camarillo@lmf.ericsson.se Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com, Pekka.Pessi@nokia.com, ietf-openproxy@imc.org, um@snowshore.com Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet- Drafts MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28B2F.D67BD55E" 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 Nov 2002 11:15:09 -0500 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_01C28B2F.D67BD55E Content-Type: text/plain Hi, The current work focuses on HTTP as the default protocol for OPES services. thanks abbie > -----Original Message----- > From: bindignavile.srinivas@nokia.com > [mailto:bindignavile.srinivas@nokia.com] > Sent: Wednesday, November 13, 2002 10:24 AM > To: eburger@snowshore.com; Jose.Costa-Requena@nokia.com; > Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; > Markus.Isomaki@nokia.com; dean.willis@softarmor.com; > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; > Pekka.Pessi@nokia.com; ietf-openproxy@imc.org; um@snowshore.com > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > > Hi, > > As Eric has indicated, the OPES WG is considering transcoding > issues! However, presently, rather than being > protocol-agnostic, it is being designed for HTTP and RTP > only. SIP is not being considered here. > > -Srini > > > -----Original Message----- > > From: ext Eric Burger [mailto:eburger@snowshore.com] > > Sent: Tuesday, November 12, 2002 9:49 AM > > To: Costa-Requena Jose (NMP/Helsinki); Coulombe Stephane > (NRC/Dallas); > > jon.peterson@neustar.biz; Isomaki Markus (NRC/Helsinki); > > dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; > > Gonzalo.Camarillo@lmf.ericsson.se > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; Pessi Pekka > > (NRC/Helsinki); IETF OPES (E-mail); IETF LEMONADE (E-mail) > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > > > There are already TWO work groups that are considering > > EXACTLY these transcoding requirements. > > > > They are OPES and LEMONADE. > > > > I would offer that discussion of these capabilities happen in > > those groups. If SIP is the appropriate mechanism, then > > those groups will submit the appropriate drafts to SIPPING, > > outlining the requirements. > > > > > -----Original Message----- From: Jose.Costa-Requena@nokia.com > > [snip] > > > Nevertheless, "content adaptation" I-D has a wider scope > > > since it is considering any content-type and it is taking > > > into account the terminal/user preferences. So I would say > > > that it fits into SIPPING WG while the filtering I-D is > > > mainly dealing with presence and I think it should be handled > > > at SIMPLE WG. > > > BR > > > Jose > > > > > > -----Original Message----- From: Coulombe Stephane (NRC/Dallas) > > > > At a high level, these drafts also argue that capability > > > > negotiation should be administered by intermediaries rather > > > than through an > > > > end-to-end process; this approach may attract some similar > > > controversy. > > > > > > Proposed capability negotiation can be used both ways > (end-to-end or > > > administered by intermediaries). > > > 1) end-to-end: Someone who wants to send an Instant Message > > > to another user > > > can send an OPTION query to learn about its terminal > > > capabilities and > > > then create a message within its capabilities. > > > > > > I guess this is not controversial. However how > > > realistic and usable is it in practice? > > > When composing a message, would a user really want to > > > take into consideration > > > the image formats to use, message size limitation, etc? > > > > > > For instance, you want to send a PNG image to a friend > > > and his terminal only supports > > > GIF format. What are you supposed to do? Find an image > > > conversion tool to convert to GIF? > > > This is annoying if you are using a PC, imagine with a > > > mobile phone or handheld? > > > > > > For usability reasons, the user wants to send a message > > > without caring "too much" about > > > what the other end is supporting. > > > > > > 2)administered by intermediaries: this is discussed in detail > > > in one of the drafts. > > > > > > Performing adaptation in the network is controversial > > > but this is the only way to support > > > interoperability and good user experience. > > > > > > > the applicability and impact of this mechanism is larger > > > than the problem of > > > > instant messaging and presence. While clearly, from the > > > framework, instant > > > > messaging and presence cases are driving this work, it is > > > applicable to the > > > > general use of SIP events (messaging, I think, is something > > > of a corner case). > > > > > > Yes, applicability and impact is larger than IM and presence. > > > It applies to many other > > > applications including the case of audio/video conferencing > > > (for instance when there is > > > no common audio or video codec between two ends). > > > > > > The drafts use the "corner case" of SIP IM for a few reasons: > > > 1) In SIP IM, there is no concept of capability negotiation > > > (unlike the case of sessions using SDP). > > > A user sends a message without knowing anything about > > > the recipient's terminal capabilities. > > > 2) In SIP IM, it easier to argue that there will be > > > interoperability problems because of the variety of content > > > types that could be sent (in audio/video session codecs are > > > typically more agreed on). Right now text is mostly used but > > > richer content will soon be used as is the case in Multimedia > > > Messaging Service (MMS). By the way, message adaptation is a > > > serious issue in MMS because of fast product capability > > > evolution. It's hard to keep interoperability while not > > > restricting new phones to send just "low-end" content. > > > 3) It is easier to explain the problem and propose a solution > > > with a smaller well-defined problem. > > > > > > Once we agree that SIP message adaptation is required, the > > > requirements and solutions should be established from global > > > perspective; not just SIP IM. For that reason, SIPPING may be > > > the most appropriate place to initiate this activity. > > > > > > Stephane > > > > > > -----Original Message----- > > > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > Sent: Friday, November 08, 2002 6:58 AM > > > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; > > > drage@lucent.com; rohan@cisco.com; > Gonzalo.Camarillo@lmf.ericsson.se > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > > adaptationInternet-Drafts > > > > > > > > > > > > It seems to me that these filtering drafts concern the > > > modification of MIME > > > bodies in SIP messages by intermediaries. This is not exactly an > > > uncontroversial topic in SIP circles, and therefore I don't > > > think it is a > > > foregone conclusion that this is work that some SIP-related > > WG should > > > charter. At a high level, these drafts also argue that capability > > > negotiation should be administered by intermediaries rather than > > > through an end-to-end process; this approach may attract some > > > similar controversy. > > > > > > Provided that this is work the community would like to > pursue, the > > > applicability and impact of this mechanism is larger than the > > > problem of instant messaging and presence. While clearly, from the > > > framework, instant > > > messaging and presence cases are driving this work, it is > > > applicable to the > > > general use of SIP events (messaging, I think, is something > > > of a corner > > > case). While SIMPLE could certainly spend some time refining > > > the framework > > > and requirements related to IM & presence, I imagine that at > > > a mechanism > > > stage this work would need to take place in SIPPING. > > > > > > Jon Peterson > > > NeuStar, Inc. > > > > > > > -----Original Message----- > > > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > > > > Sent: Friday, November 08, 2002 3:47 AM > > > > To: dean.willis@softarmor.com; drage@lucent.com; > rohan@cisco.com; > > > > Gonzalo.Camarillo@lmf.ericsson.se > > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > > > adaptationInternet-Drafts > > > > > > > > > > > > Hi, > > > > > > > > Actually this thread is about two separate things: > > > > - Event filtering > > > > - Multimedia message adaptation > > > > > > > > Neither of them appears currently on any sippish WG charter > > > > currently. > > > > > > > > Event filtering has been discussed several times and it is > > > > even mentioned in (but out of scope of) SIP Events RFC. My > > > > impression has been that people think that it is needed, but > > > > there has been debate about scope and feasibility. I hope the > > > > requirements draft will help in that discussion. My own > > > > opinion is that what is concretely needed in short term is > > > > some simple filtering definitions for Presence event package. > > > > More wide-scoped and complex things could be worked upon as > > > > the understanding accumulates. > > > > > > > > Multimedia message adaptation hasn't been yet discussed much. > > > > I think it is in general a desirable feature, especially for > > > > relatively small and dumb terminals, which are not easily > > > > upgradable and may not understand all media formats. > > > > > > > > So I propose the WG chairs think where these items would be > > > > appropriate, and if there is enough interest for them, let's > > > > put them on the charters. > > > > > > > > Markus > > > > > > > > > -----Original Message----- > > > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > > > > Sent: 08 November, 2002 5:11 > > > > > To: Drage, Keith (Keith) > > > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message > > > > > adaptationInternet-Drafts > > > > > > > > > > > > > > > Well, I'd like to hear opinions from the participants > here . . . > > > > > > > > > > Clearly they aren't explicitly on the charter for either > > > > > group. Do we as > > > > > yet have a consensus that we need to work on these > > > > problems? If so, we > > > > > can consider WHERE to work on them. I suspect SIPPING is > > > closer to a > > > > > matching scope than is SIMPLE, but the relevant ADs may have > > > > > suggestions > > > > > to make there as well. > > > > > > > > > > -- > > > > > Dean > > > > > > > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > > > > > > I am getting a bit confused as to which group should be > > > > > discussing these filtering issues. > > > > > > > > > > > > Could we have a statement from the WG chairs of SIPPING or > > > > > SIMPLE as to whether this, and the moran drafts, are part of > > > > > the scope of SIPPING or SIMPLE. > > > > > > > > > > > > And before you say these are both author drafts, I think we > > > > > do need to charter one of the WGs to do some work in this > > > > > area - I am just not sure of the exact scope yet. > > > > > > > > > > > > Keith > > > > > > > > > > > > Keith Drage > > > > > > Lucent Technologies > > > > > > Tel: +44 1793 776249 > > > > > > Email: drage@lucent.com > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > > > Sent: 06 November 2002 18:24 > > > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com > > > > > > > Subject: [Simple] Multimedia message adaptation > > > Internet-Drafts > > > > > > > > > > > > > > > > > > > > > While these drafts concern event filtering, > > > > too, the subject was > > > > > > > a bit misleading because I lazily just followed > > > > up Tim's e-mail. > > > > > > > > > > > > > > Pekka > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > > > ptation-framework-00.txt > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > > > > > > > ptation-requirements-00.txt > > > > > > > > > > > > > > Pekka Pessi writes: > > > > > > > >We have submitted two drafts regarding > multimedia message > > > > > > > >adaptation. A multimedia message is typically a message > > > > > > > >containing images, audio or video clips and their > > > presentation > > > > > > > >information, e.g., smil. Also, even > XML-formatted text may > > > > > > > >require adaptation in some cases. > > > > > > > > > > > > > > >Our goal is to have a framework using SIP, HTTP > > and MIME that > > > > > > > >allows a person sending multimedia message to adapt > > > the message > > > > > > > >contents suitable to all the recipients. In some > cases the > > > > > > > >adaptation can be done by the sending terminal, but > > > we also see > > > > > > > >that an adaptation service would be very useful in > > > many cases. > > > > > > > >Such an adaptation mechanism is used by MMS service > > > provided by > > > > > > > >cellular networks nowadays. > > > > > > > > > > > > > > >The message adaptation work concerns both SIPPING > > and SIMPLE, > > > > > > > >the requirements I-D lists use cases and > requirements for > > > > > > > >multimedia messaging and message adaptation > > solutions and the > > > > > > > >framework I-D tries to explore possible solutions. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > simple mailing list > > > > > > > simple@mailman.dynamicsoft.com > > > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > > > > > _______________________________________________ > > > > > > Sipping mailing list > > > > https://www1.ietf.org/mailman/listinfo/sipping > > > > > > This list is for NEW development of the application > of SIP Use > > > > > > sip-implementors@cs.columbia.edu for questions on > > > current sip > > > > > > Use sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list > is for NEW development of the application of SIP Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sip@ietf.org for new developments of core SIP > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list > is for NEW development of the application of SIP Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > ------_=_NextPart_001_01C28B2F.D67BD55E Content-Type: text/html RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts

Hi,

The current work focuses on HTTP as the default protocol for OPES services.

thanks
abbie


> -----Original Message-----
> From: bindignavile.srinivas@nokia.com
> [mailto:bindignavile.srinivas@nokia.com]
> Sent: Wednesday, November 13, 2002 10:24 AM
> To: eburger@snowshore.com; Jose.Costa-Requena@nokia.com;
> Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz;
> Markus.Isomaki@nokia.com; dean.willis@softarmor.com;
> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com;
> Pekka.Pessi@nokia.com; ietf-openproxy@imc.org; um@snowshore.com
> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
>
>
>
> Hi,
>
> As Eric has indicated, the OPES WG is considering transcoding
> issues! However, presently, rather than being
> protocol-agnostic, it is being designed for HTTP and RTP
> only. SIP is not being considered here.
>
> -Srini
>
> > -----Original Message-----
> > From: ext Eric Burger [mailto:eburger@snowshore.com]
> > Sent: Tuesday, November 12, 2002 9:49 AM
> > To: Costa-Requena Jose (NMP/Helsinki); Coulombe Stephane
> (NRC/Dallas);
> > jon.peterson@neustar.biz; Isomaki Markus (NRC/Helsinki);
> > dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
> > Gonzalo.Camarillo@lmf.ericsson.se
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; Pessi Pekka
> > (NRC/Helsinki); IETF OPES (E-mail); IETF LEMONADE (E-mail)
> > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > adaptationInternet-Drafts
> >
> >
> >
> > There are already TWO work groups that are considering
> > EXACTLY these transcoding requirements.
> >
> > They are OPES and LEMONADE.
> >
> > I would offer that discussion of these capabilities happen in
> > those groups.  If SIP is the appropriate mechanism, then
> > those groups will submit the appropriate drafts to SIPPING,
> > outlining the requirements.
> >
> > > -----Original Message----- From: Jose.Costa-Requena@nokia.com
> > [snip]
> > > Nevertheless, "content adaptation" I-D has a wider scope
> > > since it is considering any content-type and it is taking
> > > into account the terminal/user preferences. So I would say
> > > that  it fits into SIPPING WG while the filtering I-D is
> > > mainly dealing with presence and I think it should be handled
> > > at SIMPLE WG.
> > > BR
> > > Jose
> > >
> > > -----Original Message----- From: Coulombe Stephane (NRC/Dallas)
> > > > At a high level, these drafts also argue that capability
> > > > negotiation should be administered by intermediaries rather
> > > than through an
> > > > end-to-end process; this approach may attract some similar
> > > controversy.
> > >
> > > Proposed capability negotiation can be used both ways
> (end-to-end or
> > > administered by intermediaries).
> > > 1) end-to-end: Someone who wants to send an Instant Message
> > > to another user
> > >   can send an OPTION query to learn about its terminal
> > > capabilities and
> > >   then create a message within its capabilities.
> > >  
> > >   I guess this is not controversial. However how
> > > realistic and usable is it in practice?
> > >   When composing a message, would a user really want to
> > > take into consideration
> > >   the image formats to use, message size limitation, etc?
> > >
> > >   For instance, you want to send a PNG image to a friend
> > > and his terminal only supports
> > >   GIF format. What are you supposed to do? Find an image
> > > conversion tool to convert to GIF?
> > >   This is annoying if you are using a PC, imagine with a
> > > mobile phone or handheld?
> > >  
> > >   For usability reasons, the user wants to send a message
> > > without caring "too much" about
> > >   what the other end is supporting.
> > > 
> > > 2)administered by intermediaries: this is discussed in detail
> > > in one of the drafts.
> > >
> > >   Performing adaptation in the network is controversial
> > > but this is the only way to support
> > >   interoperability and good user experience.
> > >
> > > > the applicability and impact of this mechanism is larger
> > > than the problem of
> > > > instant messaging and presence. While clearly, from the
> > > framework, instant
> > > > messaging and presence cases are driving this work, it is
> > > applicable to the
> > > > general use of SIP events (messaging, I think, is something
> > > of a corner case).
> > >
> > > Yes, applicability and impact is larger than IM and presence.
> > > It applies to many other
> > > applications including the case of audio/video conferencing
> > > (for instance when there is
> > > no common audio or video codec between two ends). 
> > >
> > > The drafts use the "corner case" of SIP IM for a few reasons:
> > > 1) In SIP IM, there is no concept of capability negotiation
> > > (unlike the case of sessions using SDP).
> > >   A user sends a message without knowing anything about
> > > the recipient's terminal capabilities.
> > > 2) In SIP IM, it easier to argue that there will be
> > > interoperability problems because of the variety of content
> > > types that could be sent (in audio/video session codecs are
> > > typically more agreed on). Right now text is mostly used but
> > > richer content will soon be used as is the case in Multimedia
> > > Messaging Service (MMS). By the way, message adaptation is a
> > > serious issue in MMS because of fast product capability
> > > evolution. It's hard to keep interoperability while not
> > > restricting new phones to send just "low-end" content.
> > > 3) It is easier to explain the problem and propose a solution
> > > with a smaller well-defined problem.
> > >
> > > Once we agree that SIP message adaptation is required, the
> > > requirements and solutions should be established from global
> > > perspective; not just SIP IM. For that reason, SIPPING may be
> > > the most appropriate place to initiate this activity.
> > >
> > > Stephane
> > >
> > > -----Original Message-----
> > > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
> > > Sent: Friday, November 08, 2002 6:58 AM
> > > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com;
> > > drage@lucent.com; rohan@cisco.com;
> Gonzalo.Camarillo@lmf.ericsson.se
> > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > > adaptationInternet-Drafts
> > >
> > >
> > >
> > > It seems to me that these filtering drafts concern the
> > > modification of MIME
> > > bodies in SIP messages by intermediaries. This is not exactly an
> > > uncontroversial topic in SIP circles, and therefore I don't
> > > think it is a
> > > foregone conclusion that this is work that some SIP-related
> > WG should
> > > charter. At a high level, these drafts also argue that capability
> > > negotiation should be administered by intermediaries rather than
> > > through an end-to-end process; this approach may attract some
> > > similar controversy.
> > >
> > > Provided that this is work the community would like to
> pursue, the
> > > applicability and impact of this mechanism is larger than the
> > > problem of instant messaging and presence. While clearly, from the
> > > framework, instant
> > > messaging and presence cases are driving this work, it is
> > > applicable to the
> > > general use of SIP events (messaging, I think, is something
> > > of a corner
> > > case). While SIMPLE could certainly spend some time refining
> > > the framework
> > > and requirements related to IM & presence, I imagine that at
> > > a mechanism
> > > stage this work would need to take place in SIPPING.
> > >
> > > Jon Peterson
> > > NeuStar, Inc.
> > >
> > > > -----Original Message-----
> > > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> > > > Sent: Friday, November 08, 2002 3:47 AM
> > > > To: dean.willis@softarmor.com; drage@lucent.com;
> rohan@cisco.com;
> > > > Gonzalo.Camarillo@lmf.ericsson.se
> > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > > > adaptationInternet-Drafts
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Actually this thread is about two separate things:
> > > > - Event filtering
> > > > - Multimedia message adaptation
> > > >
> > > > Neither of them appears currently on any sippish WG charter
> > > > currently.
> > > >
> > > > Event filtering has been discussed several times and it is
> > > > even mentioned in (but out of scope of) SIP Events RFC. My
> > > > impression has been that people think that it is needed, but
> > > > there has been debate about scope and feasibility. I hope the
> > > > requirements draft will help in that discussion. My own
> > > > opinion is that what is concretely needed in short term is
> > > > some simple filtering definitions for Presence event package.
> > > > More wide-scoped and complex things could be worked upon as
> > > > the understanding accumulates.
> > > >
> > > > Multimedia message adaptation hasn't been yet discussed much.
> > > > I think it is in general a desirable feature, especially for
> > > > relatively small and dumb terminals, which are not easily
> > > > upgradable and may not understand all media formats.
> > > >
> > > > So I propose the WG chairs think where these items would be
> > > > appropriate, and if there is enough interest for them, let's
> > > > put them on the charters.
> > > >
> > > > Markus
> > > >
> > > > > -----Original Message-----
> > > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > > > Sent: 08 November, 2002 5:11
> > > > > To: Drage, Keith (Keith)
> > > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message
> > > > > adaptationInternet-Drafts
> > > > >
> > > > >
> > > > > Well, I'd like to hear opinions from the participants
> here . . .
> > > > >
> > > > > Clearly they aren't explicitly on the charter for either
> > > > > group. Do we as
> > > > > yet have a consensus that we need to work on these
> > > > problems? If so, we
> > > > > can consider WHERE to work on them. I suspect SIPPING is
> > > closer to a
> > > > > matching scope than is SIMPLE, but the relevant ADs may have
> > > > > suggestions
> > > > > to make there as well.
> > > > >
> > > > > --
> > > > > Dean
> > > > >
> > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > > > > I am getting a bit confused as to which group should be
> > > > > discussing these filtering issues.
> > > > > >
> > > > > > Could we have a statement from the WG chairs of SIPPING or
> > > > > SIMPLE as to whether this, and the moran drafts, are part of
> > > > > the scope of SIPPING or SIMPLE.
> > > > > >
> > > > > > And before you say these are both author drafts, I think we
> > > > > do need to charter one of the WGs to do some work in this
> > > > > area - I am just not sure of the exact scope yet.
> > > > > >
> > > > > > Keith
> > > > > >
> > > > > > Keith Drage
> > > > > > Lucent Technologies
> > > > > > Tel: +44 1793 776249
> > > > > > Email: drage@lucent.com
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > > > > Sent: 06 November 2002 18:24
> > > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > > > > Subject: [Simple] Multimedia message adaptation
> > > Internet-Drafts
> > > > > > >
> > > > > > >
> > > > > > >   While these drafts concern event filtering,
> > > > too, the subject was
> > > > > > >   a bit misleading because I lazily just followed
> > > > up Tim's e-mail.
> > > > > > >
> > > > > > >                                   Pekka
> > > > > > >
> > > > > > >
> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > > > ptation-framework-00.txt
> > > > > > >
> > > > > > >
> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > > > ptation-requirements-00.txt
> > > > > > >
> > > > > > > Pekka Pessi <Pekka.Pessi@nokia.com> writes:
> > > > > > > >We have submitted two drafts regarding
> multimedia message
> > > > > > > >adaptation. A multimedia message is typically a message
> > > > > > > >containing images, audio or video clips and their
> > > presentation
> > > > > > > >information, e.g., smil. Also, even
> XML-formatted text may
> > > > > > > >require adaptation in some cases.
> > > > > > >
> > > > > > > >Our goal is to have a framework using SIP, HTTP
> > and MIME that
> > > > > > > >allows a person sending multimedia message to adapt
> > > the message
> > > > > > > >contents suitable to all the recipients. In some
> cases the
> > > > > > > >adaptation can be done by the sending terminal, but
> > > we also see
> > > > > > > >that an adaptation service would be very useful in
> > > many cases.
> > > > > > > >Such an adaptation mechanism is used by MMS service
> > > provided by
> > > > > > > >cellular networks nowadays.
> > > > > > >
> > > > > > > >The message adaptation work concerns both SIPPING
> > and SIMPLE,
> > > > > > > >the requirements I-D lists use cases and
> requirements for
> > > > > > > >multimedia messaging and message adaptation
> > solutions and the
> > > > > > > >framework I-D tries to explore possible solutions.
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > simple mailing list
> > > > > > > simple@mailman.dynamicsoft.com
> > > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > > > >
> > > > > > _______________________________________________
> > > > > > Sipping mailing list
> > > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > > This list is for NEW development of the application
> of SIP Use
> > > > > > sip-implementors@cs.columbia.edu for questions on
> > > current sip
> > > > > > Use sip@ietf.org for new developments of core SIP
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > 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
> > > >
> > > _______________________________________________
> > > Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list
> is for NEW development of the application of SIP Use
> > > sip-implementors@cs.columbia.edu for questions on current sip Use
> > > sip@ietf.org for new developments of core SIP
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > _______________________________________________
> > > Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list
> is for NEW development of the application of SIP Use
> > > sip-implementors@cs.columbia.edu for questions on current sip Use
> > > sip@ietf.org for new developments of core SIP
> > >
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >
>

------_=_NextPart_001_01C28B2F.D67BD55E-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 14 09:47: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 JAA20735 for ; Thu, 14 Nov 2002 09:47: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 gAEEmo5r015259; Thu, 14 Nov 2002 09:48:50 -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 JAA14177; Thu, 14 Nov 2002 09:49:53 -0500 (EST) Received: from snowshore.com (keeper.snowshore.com [216.57.133.4]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14009 for ; Thu, 14 Nov 2002 09:17:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-ID: <4A3384433CE2AB46A63468CB207E209D097B6C@zoe.office.snowshore.com> Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts Thread-Index: AcKL2DsO6cWYXZciS8qGVAN+WtLnQQADoget From: "Eric Burger" To: Cc: , , , , , , , , , , , "UM list" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mailman.dynamicsoft.com id JAA14009 Subject: [Simple] RE: [Sipping] Multimedia message adaptationInternet-Drafts 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 Nov 2002 09:17:40 -0500 Content-Transfer-Encoding: 8bit I understand the sentiment. Neither opes nor lemonade are perfect fits for the current proposals. However, I would offer that the proper home for media adaptation is either opes or lemonade. My rationale is simple. Sipping is a transport area work group. The experts in the group are transport experts. The AD's are transport AD's. Media transformation is an application. Opes and lemonade are application work groups. The experts in the groups are application experts. The AD's are application AD's. I agree that there may be refinement or conventions that will be needed in SIP to support real-time media transformation. The correct place for that to happen is sipping. However, the right people with expertise in media transformation are in the opes and lemonade groups. From a charter point of view, media transformation (IMHO) is way out of scope for sipping. We've heard from Abbie that it is sort of out of scope for opes, as opes is focusing on HTTP. On the other hand, the mechanism being proposed is rather close to the lemonade work. I think this work fits into lemonade charter items 1 (retrieval protocols) and 5 (translation services). We can refine the language to explicitly contain the real-time adaptation work items, if that would make everyone happy. -- - Eric SIPPING is for SIP. OPES and LEMONADE are specifically for media transformation. Said differently, we have transport experts in SIPPING and application experts in OPES and LEMONADE. -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Wed 11/13/2002 9:00 PM To: Jose.Costa-Requena@nokia.com Cc: bindignavile.srinivas@nokia.com; Eric Burger; Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; Markus.Isomaki@nokia.com; dean.willis@softarmor.com; drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se; sipping@ietf.org; Pekka.Pessi@nokia.com; simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM list Subject: Re: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts hello, please cease an desist cross posting when you reply. sipping seems like the default wg, so please send your comments only to sipping@ietf.org. thanks, -rohan On Wednesday, November 13, 2002, at 07:35 AM, Jose.Costa-Requena@nokia.com wrote: > Hi, > > According to LEMONADE requirements, it is considering mainly messaging > systems and I agree that this proposal could fit into that context at > some extent. Nevertheless, the actual proposal deals with content > adaptation based on UA capabilities registered with SIP. Thus, I > consider that it is within SIPPING scope, as well. > Comments? > BR > Jose > > -----Original Message----- > From: Srinivas Bindignavile (NRC/Boston) > Subject: RE: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > Hi, > > As Eric has indicated, the OPES WG is considering transcoding issues! > However, presently, rather than being protocol-agnostic, it is being > designed for HTTP and RTP only. SIP is not being considered here. > > -Srini > >> -----Original Message----- >> From: ext Eric Burger [mailto:eburger@snowshore.com] >> Subject: RE: [Sipping] RE: [Simple] Multimedia message >> adaptationInternet-Drafts >> >> >> >> There are already TWO work groups that are considering >> EXACTLY these transcoding requirements. >> >> They are OPES and LEMONADE. >> >> I would offer that discussion of these capabilities happen in >> those groups. If SIP is the appropriate mechanism, then >> those groups will submit the appropriate drafts to SIPPING, >> outlining the requirements. >> >>> -----Original Message----- From: Jose.Costa-Requena@nokia.com >> [snip] >>> Nevertheless, "content adaptation" I-D has a wider scope >>> since it is considering any content-type and it is taking >>> into account the terminal/user preferences. So I would say >>> that it fits into SIPPING WG while the filtering I-D is >>> mainly dealing with presence and I think it should be handled >>> at SIMPLE WG. >>> BR >>> Jose >>> >>> -----Original Message----- From: Coulombe Stephane (NRC/Dallas) >>>> At a high level, these drafts also argue that capability >>>> negotiation should be administered by intermediaries rather >>> than through an >>>> end-to-end process; this approach may attract some similar >>> controversy. >>> >>> Proposed capability negotiation can be used both ways (end-to-end or >>> administered by intermediaries). >>> 1) end-to-end: Someone who wants to send an Instant Message >>> to another user >>> can send an OPTION query to learn about its terminal >>> capabilities and >>> then create a message within its capabilities. >>> >>> I guess this is not controversial. However how >>> realistic and usable is it in practice? >>> When composing a message, would a user really want to >>> take into consideration >>> the image formats to use, message size limitation, etc? >>> >>> For instance, you want to send a PNG image to a friend >>> and his terminal only supports >>> GIF format. What are you supposed to do? Find an image >>> conversion tool to convert to GIF? >>> This is annoying if you are using a PC, imagine with a >>> mobile phone or handheld? >>> >>> For usability reasons, the user wants to send a message >>> without caring "too much" about >>> what the other end is supporting. >>> >>> 2)administered by intermediaries: this is discussed in detail >>> in one of the drafts. >>> >>> Performing adaptation in the network is controversial >>> but this is the only way to support >>> interoperability and good user experience. >>> >>>> the applicability and impact of this mechanism is larger >>> than the problem of >>>> instant messaging and presence. While clearly, from the >>> framework, instant >>>> messaging and presence cases are driving this work, it is >>> applicable to the >>>> general use of SIP events (messaging, I think, is something >>> of a corner case). >>> >>> Yes, applicability and impact is larger than IM and presence. >>> It applies to many other >>> applications including the case of audio/video conferencing >>> (for instance when there is >>> no common audio or video codec between two ends). >>> >>> The drafts use the "corner case" of SIP IM for a few reasons: >>> 1) In SIP IM, there is no concept of capability negotiation >>> (unlike the case of sessions using SDP). >>> A user sends a message without knowing anything about >>> the recipient's terminal capabilities. >>> 2) In SIP IM, it easier to argue that there will be >>> interoperability problems because of the variety of content >>> types that could be sent (in audio/video session codecs are >>> typically more agreed on). Right now text is mostly used but >>> richer content will soon be used as is the case in Multimedia >>> Messaging Service (MMS). By the way, message adaptation is a >>> serious issue in MMS because of fast product capability >>> evolution. It's hard to keep interoperability while not >>> restricting new phones to send just "low-end" content. >>> 3) It is easier to explain the problem and propose a solution >>> with a smaller well-defined problem. >>> >>> Once we agree that SIP message adaptation is required, the >>> requirements and solutions should be established from global >>> perspective; not just SIP IM. For that reason, SIPPING may be >>> the most appropriate place to initiate this activity. >>> >>> Stephane >>> >>> -----Original Message----- >>> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] >>> Sent: Friday, November 08, 2002 6:58 AM >>> To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; >>> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se >>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com >>> Subject: RE: [Sipping] RE: [Simple] Multimedia message >>> adaptationInternet-Drafts >>> >>> >>> >>> It seems to me that these filtering drafts concern the >>> modification of MIME >>> bodies in SIP messages by intermediaries. This is not exactly an >>> uncontroversial topic in SIP circles, and therefore I don't >>> think it is a >>> foregone conclusion that this is work that some SIP-related >> WG should >>> charter. At a high level, these drafts also argue that capability >>> negotiation should be administered by intermediaries rather >>> than through an >>> end-to-end process; this approach may attract some similar >>> controversy. >>> >>> Provided that this is work the community would like to pursue, the >>> applicability and impact of this mechanism is larger than the >>> problem of >>> instant messaging and presence. While clearly, from the >>> framework, instant >>> messaging and presence cases are driving this work, it is >>> applicable to the >>> general use of SIP events (messaging, I think, is something >>> of a corner >>> case). While SIMPLE could certainly spend some time refining >>> the framework >>> and requirements related to IM & presence, I imagine that at >>> a mechanism >>> stage this work would need to take place in SIPPING. >>> >>> Jon Peterson >>> NeuStar, Inc. >>> >>>> -----Original Message----- >>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >>>> Sent: Friday, November 08, 2002 3:47 AM >>>> To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; >>>> Gonzalo.Camarillo@lmf.ericsson.se >>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com >>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message >>>> adaptationInternet-Drafts >>>> >>>> >>>> Hi, >>>> >>>> Actually this thread is about two separate things: >>>> - Event filtering >>>> - Multimedia message adaptation >>>> >>>> Neither of them appears currently on any sippish WG charter >>>> currently. >>>> >>>> Event filtering has been discussed several times and it is >>>> even mentioned in (but out of scope of) SIP Events RFC. My >>>> impression has been that people think that it is needed, but >>>> there has been debate about scope and feasibility. I hope the >>>> requirements draft will help in that discussion. My own >>>> opinion is that what is concretely needed in short term is >>>> some simple filtering definitions for Presence event package. >>>> More wide-scoped and complex things could be worked upon as >>>> the understanding accumulates. >>>> >>>> Multimedia message adaptation hasn't been yet discussed much. >>>> I think it is in general a desirable feature, especially for >>>> relatively small and dumb terminals, which are not easily >>>> upgradable and may not understand all media formats. >>>> >>>> So I propose the WG chairs think where these items would be >>>> appropriate, and if there is enough interest for them, let's >>>> put them on the charters. >>>> >>>> Markus >>>> >>>>> -----Original Message----- >>>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com] >>>>> Sent: 08 November, 2002 5:11 >>>>> To: Drage, Keith (Keith) >>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com >>>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message >>>>> adaptationInternet-Drafts >>>>> >>>>> >>>>> Well, I'd like to hear opinions from the participants here . . . >>>>> >>>>> Clearly they aren't explicitly on the charter for either >>>>> group. Do we as >>>>> yet have a consensus that we need to work on these >>>> problems? If so, we >>>>> can consider WHERE to work on them. I suspect SIPPING is >>> closer to a >>>>> matching scope than is SIMPLE, but the relevant ADs may have >>>>> suggestions >>>>> to make there as well. >>>>> >>>>> -- >>>>> Dean >>>>> >>>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: >>>>>> I am getting a bit confused as to which group should be >>>>> discussing these filtering issues. >>>>>> >>>>>> Could we have a statement from the WG chairs of SIPPING or >>>>> SIMPLE as to whether this, and the moran drafts, are part of >>>>> the scope of SIPPING or SIMPLE. >>>>>> >>>>>> And before you say these are both author drafts, I think we >>>>> do need to charter one of the WGs to do some work in this >>>>> area - I am just not sure of the exact scope yet. >>>>>> >>>>>> Keith >>>>>> >>>>>> Keith Drage >>>>>> Lucent Technologies >>>>>> Tel: +44 1793 776249 >>>>>> Email: drage@lucent.com >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] >>>>>>> Sent: 06 November 2002 18:24 >>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com >>>>>>> Subject: [Simple] Multimedia message adaptation >>> Internet-Drafts >>>>>>> >>>>>>> >>>>>>> While these drafts concern event filtering, >>>> too, the subject was >>>>>>> a bit misleading because I lazily just followed >>>> up Tim's e-mail. >>>>>>> >>>>>>> Pekka >>>>>>> >>>>>>> >> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada >>>>>>> ptation-framework-00.txt >>>>>>> >>>>>>> >> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada >>>>>>> ptation-requirements-00.txt >>>>>>> >>>>>>> Pekka Pessi writes: >>>>>>>> We have submitted two drafts regarding multimedia message >>>>>>>> adaptation. A multimedia message is typically a message >>>>>>>> containing images, audio or video clips and their >>> presentation >>>>>>>> information, e.g., smil. Also, even XML-formatted text may >>>>>>>> require adaptation in some cases. >>>>>>> >>>>>>>> Our goal is to have a framework using SIP, HTTP >> and MIME that >>>>>>>> allows a person sending multimedia message to adapt >>> the message >>>>>>>> contents suitable to all the recipients. In some cases the >>>>>>>> adaptation can be done by the sending terminal, but >>> we also see >>>>>>>> that an adaptation service would be very useful in >>> many cases. >>>>>>>> Such an adaptation mechanism is used by MMS service >>> provided by >>>>>>>> cellular networks nowadays. >>>>>>> >>>>>>>> The message adaptation work concerns both SIPPING >> and SIMPLE, >>>>>>>> the requirements I-D lists use cases and requirements for >>>>>>>> multimedia messaging and message adaptation >> solutions and the >>>>>>>> framework I-D tries to explore possible solutions. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> simple mailing list >>>>>>> simple@mailman.dynamicsoft.com >>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple >>>>>>> >>>>>> _______________________________________________ >>>>>> Sipping mailing list >>>> https://www1.ietf.org/mailman/listinfo/sipping >>>>>> This list is for NEW development of the application of SIP >>>>>> Use sip-implementors@cs.columbia.edu for questions on >>> current sip >>>>>> Use sip@ietf.org for new developments of core SIP >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >>> _______________________________________________ >>> simple mailing list >>> simple@mailman.dynamicsoft.com >>> http://mailman.dynamicsoft.com/mailman/listinfo/simple >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >>> >> _______________________________________________ >> simple mailing list >> simple@mailman.dynamicsoft.com >> http://mailman.dynamicsoft.com/mailman/listinfo/simple >> > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 14 09:56: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 JAA20913 for ; Thu, 14 Nov 2002 09:56: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 gAEEv45r015408; Thu, 14 Nov 2002 09:57: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 JAA14300; Thu, 14 Nov 2002 09:58:06 -0500 (EST) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14130 for ; Thu, 14 Nov 2002 09:47:05 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAEEkbZ11534; Thu, 14 Nov 2002 09:46:37 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Nov 2002 09:46:37 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD7540425FFB9@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Eric Burger , Jose.Costa-Requena@nokia.com Cc: bindignavile.srinivas@nokia.com, Stephane.Coulombe@nokia.com, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com, dean.willis@softarmor.com, drage@lucent.com, Gonzalo.Camarillo@lmf.ericsson.se, sipping@ietf.org, Pekka.Pessi@nokia.com, simple@mailman.dynamicsoft.com, ietf-openproxy@imc.org, UM list , um@snowshore.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28BEC.A0ADAA16" Subject: [Simple] RE: [Sipping] Multimedia message adaptationInternet-Drafts 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 Nov 2002 09:46:34 -0500 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_01C28BEC.A0ADAA16 Content-Type: text/plain Eric, Thanks We have to be careful here, since some of the work would also fit or is being done in W3C and other bodies. abbie > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Thursday, November 14, 2002 9:18 AM > To: Jose.Costa-Requena@nokia.com > Cc: bindignavile.srinivas@nokia.com; > Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; > Markus.Isomaki@nokia.com; dean.willis@softarmor.com; > drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se; > sipping@ietf.org; Pekka.Pessi@nokia.com; > simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM > list; um@snowshore.com > Subject: RE: [Sipping] Multimedia message adaptationInternet-Drafts > > > > I understand the sentiment. Neither opes nor lemonade are > perfect fits for the current proposals. However, I would > offer that the proper home for media adaptation is either > opes or lemonade. > > My rationale is simple. Sipping is a transport area work > group. The experts in the group are transport experts. The > AD's are transport AD's. Media transformation is an > application. Opes and lemonade are application work groups. > The experts in the groups are application experts. The AD's > are application AD's. > > I agree that there may be refinement or conventions that will > be needed in SIP to support real-time media transformation. > The correct place for that to happen is sipping. However, > the right people with expertise in media transformation are > in the opes and lemonade groups. > > From a charter point of view, media transformation (IMHO) is > way out of scope for sipping. We've heard from Abbie that it > is sort of out of scope for opes, as opes is focusing on > HTTP. On the other hand, the mechanism being proposed is > rather close to the lemonade work. > > I think this work fits into lemonade charter items 1 > (retrieval protocols) and 5 (translation services). We can > refine the language to explicitly contain the real-time > adaptation work items, if that would make everyone happy. > > -- > - Eric > > > > > SIPPING is for SIP. OPES and LEMONADE are specifically for > media transformation. Said differently, we have transport > experts in SIPPING and application experts in OPES and LEMONADE. > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Wed 11/13/2002 9:00 PM > To: Jose.Costa-Requena@nokia.com > Cc: bindignavile.srinivas@nokia.com; Eric Burger; > Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; > Markus.Isomaki@nokia.com; dean.willis@softarmor.com; > drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se; > sipping@ietf.org; Pekka.Pessi@nokia.com; > simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM list > Subject: Re: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > > hello, > > please cease an desist cross posting when you reply. > sipping seems > like the default wg, so please send your comments only to > sipping@ietf.org. > > thanks, > -rohan > > On Wednesday, November 13, 2002, at 07:35 AM, > Jose.Costa-Requena@nokia.com wrote: > > > Hi, > > > > According to LEMONADE requirements, it is considering > mainly messaging > > systems and I agree that this proposal could fit into > that context at > > some extent. Nevertheless, the actual proposal deals > with content > > adaptation based on UA capabilities registered with > SIP. Thus, I > > consider that it is within SIPPING scope, as well. > > Comments? > > BR > > Jose > > > > -----Original Message----- > > From: Srinivas Bindignavile (NRC/Boston) > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > Hi, > > > > As Eric has indicated, the OPES WG is considering > transcoding issues! > > However, presently, rather than being > protocol-agnostic, it is being > > designed for HTTP and RTP only. SIP is not being > considered here. > > > > -Srini > > > >> -----Original Message----- > >> From: ext Eric Burger [mailto:eburger@snowshore.com] > >> Subject: RE: [Sipping] RE: [Simple] Multimedia message > >> adaptationInternet-Drafts > >> > >> > >> > >> There are already TWO work groups that are considering > >> EXACTLY these transcoding requirements. > >> > >> They are OPES and LEMONADE. > >> > >> I would offer that discussion of these capabilities happen in > >> those groups. If SIP is the appropriate mechanism, then > >> those groups will submit the appropriate drafts to SIPPING, > >> outlining the requirements. > >> > >>> -----Original Message----- From: > Jose.Costa-Requena@nokia.com > >> [snip] > >>> Nevertheless, "content adaptation" I-D has a wider scope > >>> since it is considering any content-type and it is taking > >>> into account the terminal/user preferences. So I would say > >>> that it fits into SIPPING WG while the filtering I-D is > >>> mainly dealing with presence and I think it should > be handled > >>> at SIMPLE WG. > >>> BR > >>> Jose > >>> > >>> -----Original Message----- From: Coulombe Stephane > (NRC/Dallas) > >>>> At a high level, these drafts also argue that capability > >>>> negotiation should be administered by intermediaries rather > >>> than through an > >>>> end-to-end process; this approach may attract some similar > >>> controversy. > >>> > >>> Proposed capability negotiation can be used both > ways (end-to-end or > >>> administered by intermediaries). > >>> 1) end-to-end: Someone who wants to send an Instant Message > >>> to another user > >>> can send an OPTION query to learn about its terminal > >>> capabilities and > >>> then create a message within its capabilities. > >>> > >>> I guess this is not controversial. However how > >>> realistic and usable is it in practice? > >>> When composing a message, would a user really want to > >>> take into consideration > >>> the image formats to use, message size limitation, etc? > >>> > >>> For instance, you want to send a PNG image to a friend > >>> and his terminal only supports > >>> GIF format. What are you supposed to do? Find an image > >>> conversion tool to convert to GIF? > >>> This is annoying if you are using a PC, imagine with a > >>> mobile phone or handheld? > >>> > >>> For usability reasons, the user wants to send a message > >>> without caring "too much" about > >>> what the other end is supporting. > >>> > >>> 2)administered by intermediaries: this is discussed > in detail > >>> in one of the drafts. > >>> > >>> Performing adaptation in the network is controversial > >>> but this is the only way to support > >>> interoperability and good user experience. > >>> > >>>> the applicability and impact of this mechanism is larger > >>> than the problem of > >>>> instant messaging and presence. While clearly, from the > >>> framework, instant > >>>> messaging and presence cases are driving this work, it is > >>> applicable to the > >>>> general use of SIP events (messaging, I think, is something > >>> of a corner case). > >>> > >>> Yes, applicability and impact is larger than IM and > presence. > >>> It applies to many other > >>> applications including the case of audio/video conferencing > >>> (for instance when there is > >>> no common audio or video codec between two ends). > >>> > >>> The drafts use the "corner case" of SIP IM for a > few reasons: > >>> 1) In SIP IM, there is no concept of capability negotiation > >>> (unlike the case of sessions using SDP). > >>> A user sends a message without knowing anything about > >>> the recipient's terminal capabilities. > >>> 2) In SIP IM, it easier to argue that there will be > >>> interoperability problems because of the variety of content > >>> types that could be sent (in audio/video session codecs are > >>> typically more agreed on). Right now text is mostly used but > >>> richer content will soon be used as is the case in > Multimedia > >>> Messaging Service (MMS). By the way, message adaptation is a > >>> serious issue in MMS because of fast product capability > >>> evolution. It's hard to keep interoperability while not > >>> restricting new phones to send just "low-end" content. > >>> 3) It is easier to explain the problem and propose > a solution > >>> with a smaller well-defined problem. > >>> > >>> Once we agree that SIP message adaptation is required, the > >>> requirements and solutions should be established from global > >>> perspective; not just SIP IM. For that reason, > SIPPING may be > >>> the most appropriate place to initiate this activity. > >>> > >>> Stephane > >>> > >>> -----Original Message----- > >>> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > >>> Sent: Friday, November 08, 2002 6:58 AM > >>> To: Isomaki Markus (NRC/Helsinki); > dean.willis@softarmor.com; > >>> drage@lucent.com; rohan@cisco.com; > Gonzalo.Camarillo@lmf.ericsson.se > >>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > >>> Subject: RE: [Sipping] RE: [Simple] Multimedia message > >>> adaptationInternet-Drafts > >>> > >>> > >>> > >>> It seems to me that these filtering drafts concern the > >>> modification of MIME > >>> bodies in SIP messages by intermediaries. This is > not exactly an > >>> uncontroversial topic in SIP circles, and therefore I don't > >>> think it is a > >>> foregone conclusion that this is work that some SIP-related > >> WG should > >>> charter. At a high level, these drafts also argue > that capability > >>> negotiation should be administered by intermediaries rather > >>> than through an > >>> end-to-end process; this approach may attract some similar > >>> controversy. > >>> > >>> Provided that this is work the community would like > to pursue, the > >>> applicability and impact of this mechanism is > larger than the > >>> problem of > >>> instant messaging and presence. While clearly, from the > >>> framework, instant > >>> messaging and presence cases are driving this work, it is > >>> applicable to the > >>> general use of SIP events (messaging, I think, is something > >>> of a corner > >>> case). While SIMPLE could certainly spend some time refining > >>> the framework > >>> and requirements related to IM & presence, I imagine that at > >>> a mechanism > >>> stage this work would need to take place in SIPPING. > >>> > >>> Jon Peterson > >>> NeuStar, Inc. > >>> > >>>> -----Original Message----- > >>>> From: Markus.Isomaki@nokia.com > [mailto:Markus.Isomaki@nokia.com] > >>>> Sent: Friday, November 08, 2002 3:47 AM > >>>> To: dean.willis@softarmor.com; drage@lucent.com; > rohan@cisco.com; > >>>> Gonzalo.Camarillo@lmf.ericsson.se > >>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > >>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message > >>>> adaptationInternet-Drafts > >>>> > >>>> > >>>> Hi, > >>>> > >>>> Actually this thread is about two separate things: > >>>> - Event filtering > >>>> - Multimedia message adaptation > >>>> > >>>> Neither of them appears currently on any sippish WG charter > >>>> currently. > >>>> > >>>> Event filtering has been discussed several times and it is > >>>> even mentioned in (but out of scope of) SIP Events RFC. My > >>>> impression has been that people think that it is > needed, but > >>>> there has been debate about scope and feasibility. > I hope the > >>>> requirements draft will help in that discussion. My own > >>>> opinion is that what is concretely needed in short term is > >>>> some simple filtering definitions for Presence > event package. > >>>> More wide-scoped and complex things could be worked upon as > >>>> the understanding accumulates. > >>>> > >>>> Multimedia message adaptation hasn't been yet > discussed much. > >>>> I think it is in general a desirable feature, > especially for > >>>> relatively small and dumb terminals, which are not easily > >>>> upgradable and may not understand all media formats. > >>>> > >>>> So I propose the WG chairs think where these items would be > >>>> appropriate, and if there is enough interest for > them, let's > >>>> put them on the charters. > >>>> > >>>> Markus > >>>> > >>>>> -----Original Message----- > >>>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com] > >>>>> Sent: 08 November, 2002 5:11 > >>>>> To: Drage, Keith (Keith) > >>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > >>>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message > >>>>> adaptationInternet-Drafts > >>>>> > >>>>> > >>>>> Well, I'd like to hear opinions from the > participants here . . . > >>>>> > >>>>> Clearly they aren't explicitly on the charter for either > >>>>> group. Do we as > >>>>> yet have a consensus that we need to work on these > >>>> problems? If so, we > >>>>> can consider WHERE to work on them. I suspect SIPPING is > >>> closer to a > >>>>> matching scope than is SIMPLE, but the relevant > ADs may have > >>>>> suggestions > >>>>> to make there as well. > >>>>> > >>>>> -- > >>>>> Dean > >>>>> > >>>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > >>>>>> I am getting a bit confused as to which group should be > >>>>> discussing these filtering issues. > >>>>>> > >>>>>> Could we have a statement from the WG chairs of > SIPPING or > >>>>> SIMPLE as to whether this, and the moran drafts, > are part of > >>>>> the scope of SIPPING or SIMPLE. > >>>>>> > >>>>>> And before you say these are both author drafts, > I think we > >>>>> do need to charter one of the WGs to do some work in this > >>>>> area - I am just not sure of the exact scope yet. > >>>>>> > >>>>>> Keith > >>>>>> > >>>>>> Keith Drage > >>>>>> Lucent Technologies > >>>>>> Tel: +44 1793 776249 > >>>>>> Email: drage@lucent.com > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > >>>>>>> Sent: 06 November 2002 18:24 > >>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com > >>>>>>> Subject: [Simple] Multimedia message adaptation > >>> Internet-Drafts > >>>>>>> > >>>>>>> > >>>>>>> While these drafts concern event filtering, > >>>> too, the subject was > >>>>>>> a bit misleading because I lazily just followed > >>>> up Tim's e-mail. > >>>>>>> > >>>>>>> Pekka > >>>>>>> > >>>>>>> > >> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > >>>>>>> ptation-framework-00.txt > >>>>>>> > >>>>>>> > >> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > >>>>>>> ptation-requirements-00.txt > >>>>>>> > >>>>>>> Pekka Pessi writes: > >>>>>>>> We have submitted two drafts regarding > multimedia message > >>>>>>>> adaptation. A multimedia message is typically a message > >>>>>>>> containing images, audio or video clips and their > >>> presentation > >>>>>>>> information, e.g., smil. Also, even > XML-formatted text may > >>>>>>>> require adaptation in some cases. > >>>>>>> > >>>>>>>> Our goal is to have a framework using SIP, HTTP > >> and MIME that > >>>>>>>> allows a person sending multimedia message to adapt > >>> the message > >>>>>>>> contents suitable to all the recipients. In > some cases the > >>>>>>>> adaptation can be done by the sending terminal, but > >>> we also see > >>>>>>>> that an adaptation service would be very useful in > >>> many cases. > >>>>>>>> Such an adaptation mechanism is used by MMS service > >>> provided by > >>>>>>>> cellular networks nowadays. > >>>>>>> > >>>>>>>> The message adaptation work concerns both SIPPING > >> and SIMPLE, > >>>>>>>> the requirements I-D lists use cases and > requirements for > >>>>>>>> multimedia messaging and message adaptation > >> solutions and the > >>>>>>>> framework I-D tries to explore possible solutions. > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> simple mailing list > >>>>>>> simple@mailman.dynamicsoft.com > >>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> Sipping mailing list > >>>> https://www1.ietf.org/mailman/listinfo/sipping > >>>>>> This list is for NEW development of the > application of SIP > >>>>>> Use sip-implementors@cs.columbia.edu for questions on > >>> current sip > >>>>>> Use sip@ietf.org for new developments of core SIP > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> _______________________________________________ > >>> Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > >>> > This list is for NEW development of the application of SIP > >>> Use sip-implementors@cs.columbia.edu for questions > on current sip > >>> Use sip@ietf.org for new developments of core SIP > >>> _______________________________________________ > >>> simple mailing list > >>> simple@mailman.dynamicsoft.com > >>> http://mailman.dynamicsoft.com/mailman/listinfo/simple > >>> _______________________________________________ > >>> Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > >>> > This list is for NEW development of the application of SIP > >>> Use sip-implementors@cs.columbia.edu for questions > on current sip > >>> Use sip@ietf.org for new developments of core SIP > >>> > >> _______________________________________________ > >> simple mailing list > >> simple@mailman.dynamicsoft.com > >> http://mailman.dynamicsoft.com/mailman/listinfo/simple > >> > > _______________________________________________ > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > This > list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > This > list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on > current sip > Use sip@ietf.org for new developments of core SIP > > > ------_=_NextPart_001_01C28BEC.A0ADAA16 Content-Type: text/html RE: [Sipping] Multimedia message adaptationInternet-Drafts

Eric,

Thanks

We have to be careful here, since some of the work would also fit or is being done  in W3C and other bodies.

abbie


> -----Original Message-----
> From: Eric Burger [mailto:eburger@snowshore.com]
> Sent: Thursday, November 14, 2002 9:18 AM
> To: Jose.Costa-Requena@nokia.com
> Cc: bindignavile.srinivas@nokia.com;
> Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz;
> Markus.Isomaki@nokia.com; dean.willis@softarmor.com;
> drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se;
> sipping@ietf.org; Pekka.Pessi@nokia.com;
> simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM
> list; um@snowshore.com
> Subject: RE: [Sipping] Multimedia message adaptationInternet-Drafts
>
>
>
> I understand the sentiment.  Neither opes nor lemonade are
> perfect fits for the current proposals.  However, I would
> offer that the proper home for media adaptation is either
> opes or lemonade.
> 
> My rationale is simple.  Sipping is a transport area work
> group.  The experts in the group are transport experts.  The
> AD's are transport AD's.  Media transformation is an
> application.  Opes and lemonade are application work groups. 
> The experts in the groups are application experts.  The AD's
> are application AD's.
> 
> I agree that there may be refinement or conventions that will
> be needed in SIP to support real-time media transformation. 
> The correct place for that to happen is sipping.  However,
> the right people with expertise in media transformation are
> in the opes and lemonade groups.
> 
> From a charter point of view, media transformation (IMHO) is
> way out of scope for sipping.  We've heard from Abbie that it
> is sort of out of scope for opes, as opes is focusing on
> HTTP.  On the other hand, the mechanism being proposed is
> rather close to the lemonade work.
> 
> I think this work fits into lemonade charter items 1
> (retrieval protocols) and 5 (translation services). We can
> refine the language to explicitly contain the real-time
> adaptation work items, if that would make everyone happy.
> 
> --
> - Eric
> 
> 
> 
> 
> SIPPING is for SIP. OPES and LEMONADE are specifically for
> media transformation.  Said differently, we have transport
> experts in SIPPING and application experts in OPES and LEMONADE.
>
>       -----Original Message-----
>       From: Rohan Mahy [mailto:rohan@cisco.com]
>       Sent: Wed 11/13/2002 9:00 PM
>       To: Jose.Costa-Requena@nokia.com
>       Cc: bindignavile.srinivas@nokia.com; Eric Burger;
> Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz;
> Markus.Isomaki@nokia.com; dean.willis@softarmor.com;
> drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se;
> sipping@ietf.org; Pekka.Pessi@nokia.com;
> simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM list
>       Subject: Re: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
>      
>      
>
>       hello,
>      
>       please cease an desist cross posting when you reply. 
> sipping seems
>       like the default wg, so please send your comments only to
>       sipping@ietf.org.
>      
>       thanks,
>       -rohan
>      
>       On Wednesday, November 13, 2002, at 07:35 AM,
>       Jose.Costa-Requena@nokia.com wrote:
>      
>       > Hi,
>       >
>       > According to LEMONADE requirements, it is considering
> mainly messaging
>       > systems and I agree that this proposal could fit into
> that context at
>       > some extent. Nevertheless, the actual proposal deals
> with content
>       > adaptation based on UA capabilities registered with
> SIP. Thus, I
>       > consider that it is within SIPPING scope, as well.
>       > Comments?
>       > BR
>       > Jose
>       >
>       > -----Original Message-----
>       > From: Srinivas Bindignavile (NRC/Boston)
>       > Subject: RE: [Sipping] RE: [Simple] Multimedia message
>       > adaptationInternet-Drafts
>       >
>       >
>       > Hi,
>       >
>       > As Eric has indicated, the OPES WG is considering
> transcoding issues!
>       > However, presently, rather than being
> protocol-agnostic, it is being
>       > designed for HTTP and RTP only. SIP is not being
> considered here.
>       >
>       > -Srini
>       >
>       >> -----Original Message-----
>       >> From: ext Eric Burger [mailto:eburger@snowshore.com]
>       >> Subject: RE: [Sipping] RE: [Simple] Multimedia message
>       >> adaptationInternet-Drafts
>       >>
>       >>
>       >>
>       >> There are already TWO work groups that are considering
>       >> EXACTLY these transcoding requirements.
>       >>
>       >> They are OPES and LEMONADE.
>       >>
>       >> I would offer that discussion of these capabilities happen in
>       >> those groups.  If SIP is the appropriate mechanism, then
>       >> those groups will submit the appropriate drafts to SIPPING,
>       >> outlining the requirements.
>       >>
>       >>> -----Original Message----- From:
> Jose.Costa-Requena@nokia.com
>       >> [snip]
>       >>> Nevertheless, "content adaptation" I-D has a wider scope
>       >>> since it is considering any content-type and it is taking
>       >>> into account the terminal/user preferences. So I would say
>       >>> that  it fits into SIPPING WG while the filtering I-D is
>       >>> mainly dealing with presence and I think it should
> be handled
>       >>> at SIMPLE WG.
>       >>> BR
>       >>> Jose
>       >>>
>       >>> -----Original Message----- From: Coulombe Stephane
> (NRC/Dallas)
>       >>>> At a high level, these drafts also argue that capability
>       >>>> negotiation should be administered by intermediaries rather
>       >>> than through an
>       >>>> end-to-end process; this approach may attract some similar
>       >>> controversy.
>       >>>
>       >>> Proposed capability negotiation can be used both
> ways (end-to-end or
>       >>> administered by intermediaries).
>       >>> 1) end-to-end: Someone who wants to send an Instant Message
>       >>> to another user
>       >>>     can send an OPTION query to learn about its terminal
>       >>> capabilities and
>       >>>     then create a message within its capabilities.
>       >>>   
>       >>>     I guess this is not controversial. However how
>       >>> realistic and usable is it in practice?
>       >>>     When composing a message, would a user really want to
>       >>> take into consideration
>       >>>     the image formats to use, message size limitation, etc?
>       >>>
>       >>>     For instance, you want to send a PNG image to a friend
>       >>> and his terminal only supports
>       >>>     GIF format. What are you supposed to do? Find an image
>       >>> conversion tool to convert to GIF?
>       >>>     This is annoying if you are using a PC, imagine with a
>       >>> mobile phone or handheld?
>       >>>   
>       >>>     For usability reasons, the user wants to send a message
>       >>> without caring "too much" about
>       >>>     what the other end is supporting.
>       >>>
>       >>> 2)administered by intermediaries: this is discussed
> in detail
>       >>> in one of the drafts.
>       >>>
>       >>>     Performing adaptation in the network is controversial
>       >>> but this is the only way to support
>       >>>     interoperability and good user experience.
>       >>>
>       >>>> the applicability and impact of this mechanism is larger
>       >>> than the problem of
>       >>>> instant messaging and presence. While clearly, from the
>       >>> framework, instant
>       >>>> messaging and presence cases are driving this work, it is
>       >>> applicable to the
>       >>>> general use of SIP events (messaging, I think, is something
>       >>> of a corner case).
>       >>>
>       >>> Yes, applicability and impact is larger than IM and
> presence.
>       >>> It applies to many other
>       >>> applications including the case of audio/video conferencing
>       >>> (for instance when there is
>       >>> no common audio or video codec between two ends).
>       >>>
>       >>> The drafts use the "corner case" of SIP IM for a
> few reasons:
>       >>> 1) In SIP IM, there is no concept of capability negotiation
>       >>> (unlike the case of sessions using SDP).
>       >>>     A user sends a message without knowing anything about
>       >>> the recipient's terminal capabilities.
>       >>> 2) In SIP IM, it easier to argue that there will be
>       >>> interoperability problems because of the variety of content
>       >>> types that could be sent (in audio/video session codecs are
>       >>> typically more agreed on). Right now text is mostly used but
>       >>> richer content will soon be used as is the case in
> Multimedia
>       >>> Messaging Service (MMS). By the way, message adaptation is a
>       >>> serious issue in MMS because of fast product capability
>       >>> evolution. It's hard to keep interoperability while not
>       >>> restricting new phones to send just "low-end" content.
>       >>> 3) It is easier to explain the problem and propose
> a solution
>       >>> with a smaller well-defined problem.
>       >>>
>       >>> Once we agree that SIP message adaptation is required, the
>       >>> requirements and solutions should be established from global
>       >>> perspective; not just SIP IM. For that reason,
> SIPPING may be
>       >>> the most appropriate place to initiate this activity.
>       >>>
>       >>> Stephane
>       >>>
>       >>> -----Original Message-----
>       >>> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
>       >>> Sent: Friday, November 08, 2002 6:58 AM
>       >>> To: Isomaki Markus (NRC/Helsinki);
> dean.willis@softarmor.com;
>       >>> drage@lucent.com; rohan@cisco.com;
> Gonzalo.Camarillo@lmf.ericsson.se
>       >>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
>       >>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
>       >>> adaptationInternet-Drafts
>       >>>
>       >>>
>       >>>
>       >>> It seems to me that these filtering drafts concern the
>       >>> modification of MIME
>       >>> bodies in SIP messages by intermediaries. This is
> not exactly an
>       >>> uncontroversial topic in SIP circles, and therefore I don't
>       >>> think it is a
>       >>> foregone conclusion that this is work that some SIP-related
>       >> WG should
>       >>> charter. At a high level, these drafts also argue
> that capability
>       >>> negotiation should be administered by intermediaries rather
>       >>> than through an
>       >>> end-to-end process; this approach may attract some similar
>       >>> controversy.
>       >>>
>       >>> Provided that this is work the community would like
> to pursue, the
>       >>> applicability and impact of this mechanism is
> larger than the
>       >>> problem of
>       >>> instant messaging and presence. While clearly, from the
>       >>> framework, instant
>       >>> messaging and presence cases are driving this work, it is
>       >>> applicable to the
>       >>> general use of SIP events (messaging, I think, is something
>       >>> of a corner
>       >>> case). While SIMPLE could certainly spend some time refining
>       >>> the framework
>       >>> and requirements related to IM & presence, I imagine that at
>       >>> a mechanism
>       >>> stage this work would need to take place in SIPPING.
>       >>>
>       >>> Jon Peterson
>       >>> NeuStar, Inc.
>       >>>
>       >>>> -----Original Message-----
>       >>>> From: Markus.Isomaki@nokia.com
> [mailto:Markus.Isomaki@nokia.com]
>       >>>> Sent: Friday, November 08, 2002 3:47 AM
>       >>>> To: dean.willis@softarmor.com; drage@lucent.com;
> rohan@cisco.com;
>       >>>> Gonzalo.Camarillo@lmf.ericsson.se
>       >>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
>       >>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
>       >>>> adaptationInternet-Drafts
>       >>>>
>       >>>>
>       >>>> Hi,
>       >>>>
>       >>>> Actually this thread is about two separate things:
>       >>>> - Event filtering
>       >>>> - Multimedia message adaptation
>       >>>>
>       >>>> Neither of them appears currently on any sippish WG charter
>       >>>> currently.
>       >>>>
>       >>>> Event filtering has been discussed several times and it is
>       >>>> even mentioned in (but out of scope of) SIP Events RFC. My
>       >>>> impression has been that people think that it is
> needed, but
>       >>>> there has been debate about scope and feasibility.
> I hope the
>       >>>> requirements draft will help in that discussion. My own
>       >>>> opinion is that what is concretely needed in short term is
>       >>>> some simple filtering definitions for Presence
> event package.
>       >>>> More wide-scoped and complex things could be worked upon as
>       >>>> the understanding accumulates.
>       >>>>
>       >>>> Multimedia message adaptation hasn't been yet
> discussed much.
>       >>>> I think it is in general a desirable feature,
> especially for
>       >>>> relatively small and dumb terminals, which are not easily
>       >>>> upgradable and may not understand all media formats.
>       >>>>
>       >>>> So I propose the WG chairs think where these items would be
>       >>>> appropriate, and if there is enough interest for
> them, let's
>       >>>> put them on the charters.
>       >>>>
>       >>>> Markus
>       >>>>
>       >>>>> -----Original Message-----
>       >>>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
>       >>>>> Sent: 08 November, 2002 5:11
>       >>>>> To: Drage, Keith (Keith)
>       >>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
>       >>>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message
>       >>>>> adaptationInternet-Drafts
>       >>>>>
>       >>>>>
>       >>>>> Well, I'd like to hear opinions from the
> participants here . . .
>       >>>>>
>       >>>>> Clearly they aren't explicitly on the charter for either
>       >>>>> group. Do we as
>       >>>>> yet have a consensus that we need to work on these
>       >>>> problems? If so, we
>       >>>>> can consider WHERE to work on them. I suspect SIPPING is
>       >>> closer to a
>       >>>>> matching scope than is SIMPLE, but the relevant
> ADs may have
>       >>>>> suggestions
>       >>>>> to make there as well.
>       >>>>>
>       >>>>> --
>       >>>>> Dean
>       >>>>>
>       >>>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
>       >>>>>> I am getting a bit confused as to which group should be
>       >>>>> discussing these filtering issues.
>       >>>>>>
>       >>>>>> Could we have a statement from the WG chairs of
> SIPPING or
>       >>>>> SIMPLE as to whether this, and the moran drafts,
> are part of
>       >>>>> the scope of SIPPING or SIMPLE.
>       >>>>>>
>       >>>>>> And before you say these are both author drafts,
> I think we
>       >>>>> do need to charter one of the WGs to do some work in this
>       >>>>> area - I am just not sure of the exact scope yet.
>       >>>>>>
>       >>>>>> Keith
>       >>>>>>
>       >>>>>> Keith Drage
>       >>>>>> Lucent Technologies
>       >>>>>> Tel: +44 1793 776249
>       >>>>>> Email: drage@lucent.com
>       >>>>>>
>       >>>>>>> -----Original Message-----
>       >>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
>       >>>>>>> Sent: 06 November 2002 18:24
>       >>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com
>       >>>>>>> Subject: [Simple] Multimedia message adaptation
>       >>> Internet-Drafts
>       >>>>>>>
>       >>>>>>>
>       >>>>>>>         While these drafts concern event filtering,
>       >>>> too, the subject was
>       >>>>>>>         a bit misleading because I lazily just followed
>       >>>> up Tim's e-mail.
>       >>>>>>>
>       >>>>>>>                                         Pekka
>       >>>>>>>
>       >>>>>>>
>       >>
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
>       >>>>>>> ptation-framework-00.txt
>       >>>>>>>
>       >>>>>>>
>       >>
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
>       >>>>>>> ptation-requirements-00.txt
>       >>>>>>>
>       >>>>>>> Pekka Pessi <Pekka.Pessi@nokia.com> writes:
>       >>>>>>>> We have submitted two drafts regarding
> multimedia message
>       >>>>>>>> adaptation. A multimedia message is typically a message
>       >>>>>>>> containing images, audio or video clips and their
>       >>> presentation
>       >>>>>>>> information, e.g., smil. Also, even
> XML-formatted text may
>       >>>>>>>> require adaptation in some cases.
>       >>>>>>>
>       >>>>>>>> Our goal is to have a framework using SIP, HTTP
>       >> and MIME that
>       >>>>>>>> allows a person sending multimedia message to adapt
>       >>> the message
>       >>>>>>>> contents suitable to all the recipients. In
> some cases the
>       >>>>>>>> adaptation can be done by the sending terminal, but
>       >>> we also see
>       >>>>>>>> that an adaptation service would be very useful in
>       >>> many cases.
>       >>>>>>>> Such an adaptation mechanism is used by MMS service
>       >>> provided by
>       >>>>>>>> cellular networks nowadays.
>       >>>>>>>
>       >>>>>>>> The message adaptation work concerns both SIPPING
>       >> and SIMPLE,
>       >>>>>>>> the requirements I-D lists use cases and
> requirements for
>       >>>>>>>> multimedia messaging and message adaptation
>       >> solutions and the
>       >>>>>>>> framework I-D tries to explore possible solutions.
>       >>>>>>>
>       >>>>>>> _______________________________________________
>       >>>>>>> simple mailing list
>       >>>>>>> simple@mailman.dynamicsoft.com
>       >>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>       >>>>>>>
>       >>>>>> _______________________________________________
>       >>>>>> Sipping mailing list
>       >>>> https://www1.ietf.org/mailman/listinfo/sipping
>       >>>>>> This list is for NEW development of the
> application of SIP
>       >>>>>> Use sip-implementors@cs.columbia.edu for questions on
>       >>> current sip
>       >>>>>> Use sip@ietf.org for new developments of core SIP
>       >>>>>>
>       >>>>>
>       >>>>> _______________________________________________
>       >>>>> 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
>       >>>>
>       >>> _______________________________________________
>       >>> Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping
>       >>>
> This list is for NEW development of the application of SIP
>       >>> Use sip-implementors@cs.columbia.edu for questions
> on current sip
>       >>> Use sip@ietf.org for new developments of core SIP
>       >>> _______________________________________________
>       >>> simple mailing list
>       >>> simple@mailman.dynamicsoft.com
>       >>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>       >>> _______________________________________________
>       >>> Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping
>       >>>
> This list is for NEW development of the application of SIP
>       >>> Use sip-implementors@cs.columbia.edu for questions
> on current sip
>       >>> Use sip@ietf.org for new developments of core SIP
>       >>>
>       >> _______________________________________________
>       >> simple mailing list
>       >> simple@mailman.dynamicsoft.com
>       >> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>       >>
>       > _______________________________________________
>       > Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping
>       > This
> list is for NEW development of the application of SIP
>       > Use sip-implementors@cs.columbia.edu for questions on
> current sip
>       > Use sip@ietf.org for new developments of core SIP
>      
>       _______________________________________________
>       Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping
>       This
> list is for NEW development of the application of SIP
>       Use sip-implementors@cs.columbia.edu for questions on
> current sip
>       Use sip@ietf.org for new developments of core SIP
>      
>
>

------_=_NextPart_001_01C28BEC.A0ADAA16-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 14 10:00: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 KAA21038 for ; Thu, 14 Nov 2002 10:00: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 gAEF1Y5r015524; Thu, 14 Nov 2002 10:01:34 -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 KAA14389; Thu, 14 Nov 2002 10:02:36 -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 JAA14317 for ; Thu, 14 Nov 2002 09:59:44 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAEExv7G003903; Thu, 14 Nov 2002 09:59:58 -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 AAU85139; Thu, 14 Nov 2002 10:04:30 -0500 (EST) Message-ID: <3DD3BA57.1BFC0BA0@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: Jonathan Rosenberg , Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@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: Thu, 14 Nov 2002 09:59:35 -0500 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > > > But I'm not sure this is workable even with that limitation. I have a > > > hunch there is still a race condition when one end will think there > > > is a connection and attempt to reuse it, while the other end has > > > decided there is no session using the connection and tries to drop it > > > or establish a new one. This is tricky, and probably impossible to > > > decide in general except with respect to a precise rule for reuse. > > > But here is one case that seems simpler than some others: > > So, what happens if you attempt to resuse a connection that is dropped? > Won't that fact quickly become apparent? Can't we just reconnect? > > There may be a complication here in that comedia says you can't just > reconnect, you must renegotiate SDP--but scenario under discussion > results from an SDP notification, so I am not sure if that requirement > is constrainint here. Comedia currently says you start listening for a connection when you need one, and you stop listening when you get one. And after you stop, you can recycle the port on which you were listening for the connection. And the connection you got then isn't dropped until a BYE or reinvite. This logic doesn't work for intermediaries that are multiplexing connections. They need a different rule for when to reuse a connection and when to create one. This is where the race conditions come in. > > So, whats the problem? Well, all intermediaries need to maintain a > > routing table, which tells them what to do with incoming messages. That > > table tells them that if an IM arrives on some specific connection, with > > a specific URI/identifier in the outer envelope, to forward to a > > different connection with a different URI/identifier in the outer > > envelope. THis means that the intermediary has to associate each > > connection with a specific dialog used to set it up (since the dialog is > > used to exchange the SDP that contains the URI/identifiers). How is this > > association done? > > I am not sure I understand the difficulty here. These intermediaries > surely must be SIP aware, if they are in the business of re-writing SDP. > Additionally, it seems to me that they must be dialog stateful devices. > Why can't they just maintain a table that associates a dialog with a > session, and the session with a connection, where the association > between session and connection is many-to-one? > > If we get SDP describing a new _session_, it will contain address, port, > and direction information. A device can check the connection table to > determine whether it currently has a connection opened to that > particular address and port, can't it? If so, why can't it just start > interleaving messages for the new session onto the existing connection? > Maybe I am being dense, but I do not understand what problem the > connection-id mechanism below is trying to solve. That's ok on the inbound side, multiplexing traffic. But its not sufficient on the outbound side, where the traffic needs to be demultiplexed. On that side, the intermediary needs to have a mapping between something in the multiplexed media stream and the outbound session. > > > > > Right now, its done with the SOURCE ADDRESS. That is, the SDP sent out > > by A in your example contains the source IP/port it will make the > > connection from. So, when I1 receives the connection request, it can > > determine the source, and then match it to the dialog. The problem is, > > this doesn't work at all through NAT. If you don't want to use the > > source to demux, the intermediary can arrange for each connection to > > occur on a different port, and that means no reuse. So, we have a real > > problem. > > > > I will note that comedia says you should _not_ use source address this > way unless you are certain your network is free of the blight of NATs. > > But since a connection can carry more than one session, it makes no > sense to try to tie a connection request to a particular dialog. The > cpim-msgfmt session draft has its own mechanism for identifying the > session. Why can a participating device not relate that to the dialog > that set upt he session in the first place? What you have done is identify the mismatch between the semantics of comedia and the semantics of cpim. comedia was faced with the need to set up the media stream without any constraint over the content of that stream. It leads to a different solution that isn't ideal here. (In fact, it may not be ideal for anything.) _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 14 10:35: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 KAA21818 for ; Thu, 14 Nov 2002 10:35: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 gAEFa35r015716; Thu, 14 Nov 2002 10:36: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 KAA14536; Thu, 14 Nov 2002 10:37:05 -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 KAA14525 for ; Thu, 14 Nov 2002 10:36:26 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAEFZuO13912 for ; Thu, 14 Nov 2002 17:35:56 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 14 Nov 2002 17:36:24 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 14 Nov 2002 17:36:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FC1@esebe019.ntc.nokia.com> Thread-Topic: Comments on Data Manipulation Requirements Thread-Index: AcKL85dqzLy9xVf9RliH26JjKgQMzg== To: X-OriginalArrivalTime: 14 Nov 2002 15:36:26.0092 (UTC) FILETIME=[97DC82C0:01C28BF3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA14525 Subject: [Simple] Comments on Data Manipulation Requirements 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 Nov 2002 17:36:25 +0200 Content-Transfer-Encoding: 8bit Hi, Section 5.1 REQ 2: This requirement is talking about rejecting a subscriber not belonging in an "Allowed Watchers" list. Should rejecting only be based on subscribers belonging to "Blocked Watchers". In this case, REQ 2 would be changed to talk about adding that subscriber to a "Pending Watchers" list and accepting the subscription. (Or do we need both REQ 2 as it stands and REQ 2 as I suggest?) REQ 7.7: This is similar to REQ 7 in section 4, should both requirements carry the same strength (MUST or SHOULD)? REQ 7.8: should it continue specifying that "If the URI cannot be allocated (because it already exists, for example), it MUST be possible to inform the client of the failure, and the reason for it"? This aligns it with REQ 2 in section 4. REQ 7.9: This is similar to REQ 3 in section 4, should both requirements carry the same strength (MUST or SHOULD)? REQ 7.9: should it continue specifying that this happens in case user does not provide one? This aligns it with REQ 3 in section 4. Section 5.2 REQ 4: I don't quite understand this one. Is it talking about filters in subscribe specifying higher rate that the minimum? Section 5.3 REQ 3: This can result in a NOTIFY with no tuples. Is that Ok? should the NOTIFY be sent? if so, what does it mean? REQ 4: Tuples cannot be meaningfully identified. Communication means might be a better choice. Back to section 3: It states that a PA can receive a subscription with presence list uri. Are we assuming that a PA is a PLS? Does a PA's definition allow for this? This is irrelevant to this draft anyway. Regards, Hisham _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 14 17:26: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 RAA03169 for ; Thu, 14 Nov 2002 17:26: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 gAEMRH5r017581; Thu, 14 Nov 2002 17:27:17 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16025; Thu, 14 Nov 2002 17:28: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 RAA16014 for ; Thu, 14 Nov 2002 17:27:56 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAEMRwYH000537; Thu, 14 Nov 2002 17:27:58 -0500 (EST) Message-ID: <3DD4236B.6070600@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Paul Kyzivat , Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 17:27:55 -0500 Content-Transfer-Encoding: 7bit inline. Ben Campbell wrote: >> So, whats the problem? Well, all intermediaries need to maintain a >> routing table, which tells them what to do with incoming messages. >> That table tells them that if an IM arrives on some specific >> connection, with a specific URI/identifier in the outer envelope, to >> forward to a different connection with a different URI/identifier in >> the outer envelope. THis means that the intermediary has to associate >> each connection with a specific dialog used to set it up (since the >> dialog is used to exchange the SDP that contains the URI/identifiers). >> How is this association done? > > > I am not sure I understand the difficulty here. These intermediaries > surely must be SIP aware, if they are in the business of re-writing SDP. > Additionally, it seems to me that they must be dialog stateful devices. > Why can't they just maintain a table that associates a dialog with a > session, and the session with a connection, where the association > between session and connection is many-to-one? The issue is identifying the connection. Lets say A calls B through intermediary I. Consider the SDP in the 200 OK from I to A. The SDP will indicate to A to open a TCP connection to a well known port on the single IP address of the intermediary I. This is the same port and IP address handed out to every other client. If A is active, and initiates the connection to I, when I receives the connection request, how does it know its associated with the call that was just made? The destination IP provides no information - its to the well known address and port. The source address is useless because of NAT. So, how does it know? It can't, unless it uses a distinct port for each connection, which doesnt work with intermediaries. And thus our dilemma. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 14 17:34: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 RAA04045 for ; Thu, 14 Nov 2002 17:34: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 gAEMV45r017606; Thu, 14 Nov 2002 17:31: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 RAA16056; Thu, 14 Nov 2002 17:32: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 RAA16031 for ; Thu, 14 Nov 2002 17:28:51 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAEMSrYH000540; Thu, 14 Nov 2002 17:28:53 -0500 (EST) Message-ID: <3DD423A2.9080502@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Ben Campbell , Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com> <3DD3BA57.1BFC0BA0@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 17:28:50 -0500 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > >> But since a connection can carry more than one session, it makes no >> sense to try to tie a connection request to a particular dialog. >> The cpim-msgfmt session draft has its own mechanism for identifying >> the session. Why can a participating device not relate that to the >> dialog that set upt he session in the first place? > > > What you have done is identify the mismatch between the semantics of > comedia and the semantics of cpim. > > comedia was faced with the need to set up the media stream without > any constraint over the content of that stream. It leads to a > different solution that isn't ideal here. (In fact, it may not be > ideal for anything.) > Well, thats a problem I think. I suspect at this point we need to raise these issues in mmusic. At the very least, I'd like to be able to EXTEND comedia to meet our requirements. Its not even clear to me that we can do that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 14 17:47: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 RAA04763 for ; Thu, 14 Nov 2002 17:47: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 gAEMm65r017786; Thu, 14 Nov 2002 17:48: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 RAA16178; Thu, 14 Nov 2002 17:49: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 RAA16167 for ; Thu, 14 Nov 2002 17:48:07 -0500 (EST) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gAEMm0U1052387; Thu, 14 Nov 2002 16:48:00 -0600 (CST) Message-ID: <3DD42816.5020906@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com> <3DD4236B.6070600@dynamicsoft.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 16:47:50 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > inline. > > Ben Campbell wrote: > >>> So, whats the problem? Well, all intermediaries need to maintain a >>> routing table, which tells them what to do with incoming messages. >>> That table tells them that if an IM arrives on some specific >>> connection, with a specific URI/identifier in the outer envelope, to >>> forward to a different connection with a different URI/identifier in >>> the outer envelope. THis means that the intermediary has to associate >>> each connection with a specific dialog used to set it up (since the >>> dialog is used to exchange the SDP that contains the >>> URI/identifiers). How is this association done? >> >> >> >> I am not sure I understand the difficulty here. These intermediaries >> surely must be SIP aware, if they are in the business of re-writing >> SDP. Additionally, it seems to me that they must be dialog stateful >> devices. Why can't they just maintain a table that associates a dialog >> with a session, and the session with a connection, where the >> association between session and connection is many-to-one? > > > The issue is identifying the connection. > > Lets say A calls B through intermediary I. Consider the SDP in the 200 > OK from I to A. The SDP will indicate to A to open a TCP connection to a > well known port on the single IP address of the intermediary I. This is > the same port and IP address handed out to every other client. If A is > active, and initiates the connection to I, when I receives the > connection request, how does it know its associated with the call that > was just made? The destination IP provides no information - its to the > well known address and port. The source address is useless because of > NAT. So, how does it know? > At the risk of appearing even more hopelessly dense, why does it need to know? If I understand your proposal correctly, it must read the connection-ID from the connection after accepting it, which means it cannot decide whether or not to accept the connection based on this information. For cpim-msgfmt sessions, it does not need to know what connection a message arrived on to associate the message with a session--the To: (or msg-ID, or whatever) serves that purpose. Is this just so it can figure out when to stop listening for new connections? > It can't, unless it uses a distinct port for each connection, which > doesnt work with intermediaries. And thus our dilemma. > > -Jonathan R. > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 14 18:09: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 SAA07647 for ; Thu, 14 Nov 2002 18:09:21 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gAENA45r017923; Thu, 14 Nov 2002 18: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 SAA16301; Thu, 14 Nov 2002 18:11:06 -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 SAA16290 for ; Thu, 14 Nov 2002 18:10:38 -0500 (EST) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gAENAYU1054059; Thu, 14 Nov 2002 17:10:35 -0600 (CST) Message-ID: <3DD42D60.7050903@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com> <3DD3BA57.1BFC0BA0@cisco.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 17:10:24 -0600 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > Ben Campbell wrote: > >>> > But I'm not sure this is workable even with that limitation. I have a >>> > hunch there is still a race condition when one end will think there >>> > is a connection and attempt to reuse it, while the other end has >>> > decided there is no session using the connection and tries to drop it >>> > or establish a new one. This is tricky, and probably impossible to >>> > decide in general except with respect to a precise rule for reuse. >>> > But here is one case that seems simpler than some others: >> >>So, what happens if you attempt to resuse a connection that is dropped? >>Won't that fact quickly become apparent? Can't we just reconnect? >> >>There may be a complication here in that comedia says you can't just >>reconnect, you must renegotiate SDP--but scenario under discussion >>results from an SDP notification, so I am not sure if that requirement >>is constrainint here. > > > Comedia currently says you start listening for a connection when you need one, and you stop listening when you get one. And after you stop, you can recycle the port on which you were listening for the connection. And the connection you got then isn't dropped until a BYE or reinvite. > > This logic doesn't work for intermediaries that are multiplexing connections. They need a different rule for when to reuse a connection and when to create one. This is where the race conditions come in. OK, I _may_ be starting to understand--after the server recycles the port, the client cannot just assume that port is still valid for the same purpose--heck, it could recycle it for a purpose completely unrelated to message sessions. That would explain the comedia prohibition against reopening closed connections without a new sdp negotiation. But I am not sure I understand why this is different for an intermediary and an endpoint. > > >>>So, whats the problem? Well, all intermediaries need to maintain a >>>routing table, which tells them what to do with incoming messages. That >>>table tells them that if an IM arrives on some specific connection, with >>>a specific URI/identifier in the outer envelope, to forward to a >>>different connection with a different URI/identifier in the outer >>>envelope. THis means that the intermediary has to associate each >>>connection with a specific dialog used to set it up (since the dialog is >>>used to exchange the SDP that contains the URI/identifiers). How is this >>>association done? >> >>I am not sure I understand the difficulty here. These intermediaries >>surely must be SIP aware, if they are in the business of re-writing SDP. >>Additionally, it seems to me that they must be dialog stateful devices. >>Why can't they just maintain a table that associates a dialog with a >>session, and the session with a connection, where the association >>between session and connection is many-to-one? >> >>If we get SDP describing a new _session_, it will contain address, port, >>and direction information. A device can check the connection table to >>determine whether it currently has a connection opened to that >>particular address and port, can't it? If so, why can't it just start >>interleaving messages for the new session onto the existing connection? >>Maybe I am being dense, but I do not understand what problem the >>connection-id mechanism below is trying to solve. > > > That's ok on the inbound side, multiplexing traffic. But its not sufficient on the outbound side, where the traffic needs to be demultiplexed. On that side, the intermediary needs to have a mapping between something in the multiplexed media stream and the outbound session. Certainly--and that something is, at least for cpim-msgfmt sessions, the To header in the envelope (or a MsgID assuming we change that bit.) That header tells us all by itself which session a message is associated with. I'm not sure it really matters what connection it arrived over. Even if you were to send messages on a given session across more than one connection, the receiving intermediary could still demux them based on the MsgID. (I am _not_ advocating doing that, btw). That intermediary would then need to associate the inbound MsgID with an outbound session, with an associated connection. > > >>>Right now, its done with the SOURCE ADDRESS. That is, the SDP sent out >>>by A in your example contains the source IP/port it will make the >>>connection from. So, when I1 receives the connection request, it can >>>determine the source, and then match it to the dialog. The problem is, >>>this doesn't work at all through NAT. If you don't want to use the >>>source to demux, the intermediary can arrange for each connection to >>>occur on a different port, and that means no reuse. So, we have a real >>>problem. >>> >> >>I will note that comedia says you should _not_ use source address this >>way unless you are certain your network is free of the blight of NATs. >> >>But since a connection can carry more than one session, it makes no >>sense to try to tie a connection request to a particular dialog. The >>cpim-msgfmt session draft has its own mechanism for identifying the >>session. Why can a participating device not relate that to the dialog >>that set upt he session in the first place? > > > What you have done is identify the mismatch between the semantics of comedia and the semantics of cpim. > > comedia was faced with the need to set up the media stream without any constraint over the content of that stream. It leads to a different solution that isn't ideal here. (In fact, it may not be ideal for anything.) _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 14 18:34:20 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 SAA08331 for ; Thu, 14 Nov 2002 18:34:19 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gAENZ65r018059; Thu, 14 Nov 2002 18:35: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 SAA16415; Thu, 14 Nov 2002 18:36: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 SAA16404 for ; Thu, 14 Nov 2002 18:35:32 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAENZcbZ013876; Thu, 14 Nov 2002 18:35:42 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAU90231; Thu, 14 Nov 2002 18:40:11 -0500 (EST) Message-ID: <3DD43334.E3A90B11@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: Jonathan Rosenberg , Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com> <3DD4236B.6070600@dynamicsoft.com> <3DD42816.5020906@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: Thu, 14 Nov 2002 18:35:16 -0500 Content-Transfer-Encoding: 7bit Ben, OK, it has been a long time since the details of this were discussed on the list, so I will try to summarize them. This is just for the general case of comedia, nothing to do with simple. Assume that we have a server (perhaps a gateway) that is going to terminate a bunch of media sessions using comedia. It will be getting lots of concurrent invites with comedia SDP, and responding in kind. It must decide what to put in the sdp it answers with, so that when the connections are made it will be able to associate the connection with corresponding sdp media line. Now we presume that this must work independent of the content of the media stream - thats a groundrule here. So what can it use to associate an incoming connection? The only thing that works consistently is to assign a separate listening port for media session. If it does this, when the connection comes in it knows that it must be for the session it was assigned to. Another possibility we considered was to use a common port for receiving some or all of the incoming connections. But if that is done then some other characteristic of the incoming connection must be used to distinguish one from another. That is where specifying the source address and port in the sdp come in. If they are specified, and used, and unique, and not messed up by NATs, then they can be used to associate connections with sessions. But this list of conditions is so difficult to achieve that this is not a generally practical solution. So we are back to assigning a separate listening port for each expected incoming session. Now comes another question: how long must the server keep listening on this port? The simple answer is that it must listen as long as there is any possibility that the other end might attempt to connect to it. A simple answer would be to say that listening should continue on the port until the session is ended via a reinvite or a bye. If a single port could be used to listen for all pending connections then this would be a reasonable thing to do. But in a server with many sessions this is an expensive answer. It consumes twice as many ports, and resources to listen on those ports. In the case of Java servers prior to java 1.4 this requires a thread for each. (Its not so bad in 1.4.) So to make this tolerable, we arranged the connection setup protocol so that when a server doesn't have a connection it knows whether it must listen for connections, and when it gets a connection it knows it doesn't have to listen for more. On average it has about one port/socket per session - either listening for a connection, or waiting for input on a connection. This also means that the ports themselves can be recycled as soon as they will no longer be needed, reducing the total number of ports needed. One downside (if you consider it that) is that you can only change the connection status by sending a reinvite. I don't consider this a bad thing. Another downside, which we are seeing here, is that there is no way to multiplex traffic from two or more sessions over a single connection, even if the protocol being carried has enough data to support that demultiplexing. Doing so would require somehow enhancing the sdp so that connections can be identified globally, and so an intent to use a specific preexisting connection could be negotiated. This is probably possible. But then there comes the problem of deciding when a shared connection can be shut down. (This has to be done via offer/answer exchanges in sdp, because there is no other avaiable mechanism.) This would be subtle, and probably would require some special endpoint behavior, like reinviting with an unshared connection if the use of a shared connection is refused. But that will only work when the connection is between two endpoints. When the connection involves an intermediary, especially between a pair of intermediaries, it is either going to break entirely or be very complex, because they can't control whether reinvites are sent. Does that make the problem clearer? Now if you change the groundrules, and assume that there is data in the media stream that can frame media from different media sessions and also provide data that can be correlated with a media stream description in sdp, you can come up with a connection establishment protocol that is very different. Maybe we need to talk about this in Atlanta. Paul Ben Campbell wrote: > > At the risk of appearing even more hopelessly dense, why does it need to > know? > > If I understand your proposal correctly, it must read the connection-ID > from the connection after accepting it, which means it cannot decide > whether or not to accept the connection based on this information. For > cpim-msgfmt sessions, it does not need to know what connection a message > arrived on to associate the message with a session--the To: (or msg-ID, > or whatever) serves that purpose. > > Is this just so it can figure out when to stop listening for new > connections? _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 15 13:17: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 NAA14626 for ; Fri, 15 Nov 2002 13:17: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 gAFIIA5r020907; Fri, 15 Nov 2002 13:18: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 NAA19650; Fri, 15 Nov 2002 13:19:09 -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 NAA19639 for ; Fri, 15 Nov 2002 13:18:45 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAFIIlYH000946; Fri, 15 Nov 2002 13:18:47 -0500 (EST) Message-ID: <3DD53A84.5090801@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Paul Kyzivat , Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com> <3DD3BA57.1BFC0BA0@cisco.com> <3DD42D60.7050903@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 15 Nov 2002 13:18:44 -0500 Content-Transfer-Encoding: 7bit Ben Campbell wrote: >> >> Comedia currently says you start listening for a connection when you >> need one, and you stop listening when you get one. And after you stop, >> you can recycle the port on which you were listening for the >> connection. And the connection you got then isn't dropped until a BYE >> or reinvite. >> >> This logic doesn't work for intermediaries that are multiplexing >> connections. They need a different rule for when to reuse a connection >> and when to create one. This is where the race conditions come in. > > > OK, I _may_ be starting to understand--after the server recycles the > port, the client cannot just assume that port is still valid for the > same purpose--heck, it could recycle it for a purpose completely > unrelated to message sessions. That would explain the comedia > prohibition against reopening closed connections without a new sdp > negotiation. But I am not sure I understand why this is different for an > intermediary and an endpoint. An intermediary wants to receive multiple media sessions on the same port. An endpoint doesn't (or may not). > >> >> >>>> So, whats the problem? Well, all intermediaries need to maintain a >>>> routing table, which tells them what to do with incoming messages. That >>>> table tells them that if an IM arrives on some specific connection, >>>> with >>>> a specific URI/identifier in the outer envelope, to forward to a >>>> different connection with a different URI/identifier in the outer >>>> envelope. THis means that the intermediary has to associate each >>>> connection with a specific dialog used to set it up (since the >>>> dialog is >>>> used to exchange the SDP that contains the URI/identifiers). How is >>>> this >>>> association done? >>> >>> >>> I am not sure I understand the difficulty here. These intermediaries >>> surely must be SIP aware, if they are in the business of re-writing SDP. >>> Additionally, it seems to me that they must be dialog stateful devices. >>> Why can't they just maintain a table that associates a dialog with a >>> session, and the session with a connection, where the association >>> between session and connection is many-to-one? >>> >>> If we get SDP describing a new _session_, it will contain address, port, >>> and direction information. A device can check the connection table to >>> determine whether it currently has a connection opened to that >>> particular address and port, can't it? If so, why can't it just start >>> interleaving messages for the new session onto the existing connection? >>> Maybe I am being dense, but I do not understand what problem the >>> connection-id mechanism below is trying to solve. >> >> >> >> That's ok on the inbound side, multiplexing traffic. But its not >> sufficient on the outbound side, where the traffic needs to be >> demultiplexed. On that side, the intermediary needs to have a mapping >> between something in the multiplexed media stream and the outbound >> session. > > > Certainly--and that something is, at least for cpim-msgfmt sessions, the > To header in the envelope (or a MsgID assuming we change that bit.) That > header tells us all by itself which session a message is associated > with. I'm not sure it really matters what connection it arrived over. It doesn't. But, it matters what connection it goes TO. And thus the problem I've been pointing to, which is how a server knows which session an incoming TCP connection is associated with. It cares, since it needs to send IMs onto the right connections. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 15 16: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 QAA20571 for ; Fri, 15 Nov 2002 16:47: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 gAFLl45r021832; Fri, 15 Nov 2002 16:47: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 QAA20244; Fri, 15 Nov 2002 16: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 QAA20233 for ; Fri, 15 Nov 2002 16:47:56 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAFLlvYH001056; Fri, 15 Nov 2002 16:47:57 -0500 (EST) Message-ID: <3DD56B8A.50507@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan Chapman CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Presence & SRV - Problem solved? References: <0FD1B48D522C08408A3CFD737CD35B5512037A@thunder.vancouver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 15 Nov 2002 16:47:54 -0500 Content-Transfer-Encoding: 7bit I'm not sure this ever got answered. Response inline. Ryan Chapman wrote: > Hello all, > > I'm writing a SIMPLE-based presence infrastructure, but I'm having > some difficulty determining exactly how to deal with a presence URI > (e.g., pres:somebody@somewhere.com). > > In the CPIM draft, we are told to query _im._sip.example.com for > im:fred@example.com, and then that the "choice of IM transfer > protocol is a local configuration option for each system." Right. Meaning, the somewhere.com domain decides which SRV entries to place into DNS - _im._sip.somewhere.com and _im._apex.somewhere.com. The sender gets to choose amongst those as it sees fit. > Given > this, which SRV RR should my SIP layer query? If you are always trying to send using SIP, it would be _pres._sip.somwehere.com. > If I translate my > presence URI to a SIP URI as specified (somewhere!) in the mailing > archive Yes, this is something that needs to be described somewhere. I think it belongs in the cpim mapping draft. > by simply replacing "pres" with "sip", then what good was my > first SRV lookup? In other words, my SIP layer would simply lookup > _sip._udp.example.com, ignoring whatever results my previous query > returned. Well, thats an excellent question. Clearly, one thing you get from the initial lookup is whether or not the terminating system even supports SIP. One approach is that you use the initial query just for that purpose, discard the resulting records, translate the SIP URI using some local mechanism (swap pres for sip in the scheme), and then use SIP mechanisms. A second approach would have the translation done by the recipient domain. To some degree, one might argue that URI translation is something that only the server in the relevant domain can do. That is, pres:user@domain.com is a URI that only domain.com should ever try to translate. In that case, the appropriate approach is this: 1. client looks up _pres._sip.somewhere.com in DNS 2. client takes the resulting records, and sends the request there. The r-uri remains a pres URI. 3. the somewhere.com proxy server understands the pres URI, and applies some local policy to translate the URI. 4. Its all sip from there The drawback to this second approach is that the proxy has to understand the pres URI. Arguably, it always will, if someone got a hold of a pres URI in that domain in the first place... > My primary goal is to have my presence server be decoupled from our > proxy/registrar, so the presence URI should send the message to a > different location than a normal SIP URI would. Well, that you can always do. Generally a particular large domain will have a single proxy server that is the "front line" for requests. Its job is to route requests to the appropriate servers. For example, proxying a SUBSCRIBE request to a presence server. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 15 19:23:23 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 TAA24738 for ; Fri, 15 Nov 2002 19:23:23 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gAG0OE5r022491; Fri, 15 Nov 2002 19:24: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 TAA20788; Fri, 15 Nov 2002 19:25:08 -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 TAA20775 for ; Fri, 15 Nov 2002 19:24:01 -0500 (EST) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gAG0NsU1067699; Fri, 15 Nov 2002 18:23:54 -0600 (CST) Message-ID: <3DD59011.6070206@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , Simple Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com> <3DD4236B.6070600@dynamicsoft.com> <3DD42816.5020906@dynamicsoft.com> <3DD43334.E3A90B11@cisco.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 15 Nov 2002 18:23:45 -0600 Content-Transfer-Encoding: 7bit Jonathan/Paul Apologies for my being extra dense this week. Inspiration came to me while trying to explain the controversy to a co-worker. I now understand the issue with connection identification. I had missed the issue of knowing what connection to send an outgoing message on if the connection was opened by the opposite end. We definitely need to discuss it in Atlanta. Paul Kyzivat wrote: > Ben, > > OK, it has been a long time since the details of this were discussed on the list, so I will try to summarize them. This is just for the general case of comedia, nothing to do with simple. > > Assume that we have a server (perhaps a gateway) that is going to terminate a bunch of media sessions using comedia. It will be getting lots of concurrent invites with comedia SDP, and responding in kind. It must decide what to put in the sdp it answers with, so that when the connections are made it will be able to associate the connection with corresponding sdp media line. > > Now we presume that this must work independent of the content of the media stream - thats a groundrule here. So what can it use to associate an incoming connection? The only thing that works consistently is to assign a separate listening port for media session. If it does this, when the connection comes in it knows that it must be for the session it was assigned to. > > Another possibility we considered was to use a common port for receiving some or all of the incoming connections. But if that is done then some other characteristic of the incoming connection must be used to distinguish one from another. That is where specifying the source address and port in the sdp come in. If they are specified, and used, and unique, and not messed up by NATs, then they can be used to associate connections with sessions. But this list of conditions is so difficult to achieve that this is not a generally practical solution. > > So we are back to assigning a separate listening port for each expected incoming session. Now comes another question: how long must the server keep listening on this port? The simple answer is that it must listen as long as there is any possibility that the other end might attempt to connect to it. A simple answer would be to say that listening should continue on the port until the session is ended via a reinvite or a bye. If a single port could be used to listen for all pending connections then this would be a reasonable thing to do. But in a server with many sessions this is an expensive answer. It consumes twice as many ports, and resources to listen on those ports. In the case of Java servers prior to java 1.4 this requires a thread for each. (Its not so bad in 1.4.) > > So to make this tolerable, we arranged the connection setup protocol so that when a server doesn't have a connection it knows whether it must listen for connections, and when it gets a connection it knows it doesn't have to listen for more. On average it has about one port/socket per session - either listening for a connection, or waiting for input on a connection. This also means that the ports themselves can be recycled as soon as they will no longer be needed, reducing the total number of ports needed. > > One downside (if you consider it that) is that you can only change the connection status by sending a reinvite. I don't consider this a bad thing. > > Another downside, which we are seeing here, is that there is no way to multiplex traffic from two or more sessions over a single connection, even if the protocol being carried has enough data to support that demultiplexing. Doing so would require somehow enhancing the sdp so that connections can be identified globally, and so an intent to use a specific preexisting connection could be negotiated. This is probably possible. > > But then there comes the problem of deciding when a shared connection can be shut down. (This has to be done via offer/answer exchanges in sdp, because there is no other avaiable mechanism.) This would be subtle, and probably would require some special endpoint behavior, like reinviting with an unshared connection if the use of a shared connection is refused. But that will only work when the connection is between two endpoints. When the connection involves an intermediary, especially between a pair of intermediaries, it is either going to break entirely or be very complex, because they can't control whether reinvites are sent. > > Does that make the problem clearer? > > Now if you change the groundrules, and assume that there is data in the media stream that can frame media from different media sessions and also provide data that can be correlated with a media stream description in sdp, you can come up with a connection establishment protocol that is very different. > > Maybe we need to talk about this in Atlanta. > > Paul > > Ben Campbell wrote: > >>At the risk of appearing even more hopelessly dense, why does it need to >>know? >> >>If I understand your proposal correctly, it must read the connection-ID >>from the connection after accepting it, which means it cannot decide >>whether or not to accept the connection based on this information. For >>cpim-msgfmt sessions, it does not need to know what connection a message >>arrived on to associate the message with a session--the To: (or msg-ID, >>or whatever) serves that purpose. >> >>Is this just so it can figure out when to stop listening for new >>connections? > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Nov 16 00:14:19 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 AAA00703 for ; Sat, 16 Nov 2002 00:14: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 gAG5E75r023237; Sat, 16 Nov 2002 00:14: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 AAA21573; Sat, 16 Nov 2002 00:15: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 AAA21560 for ; Sat, 16 Nov 2002 00:14:32 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAG5EWYH001197; Sat, 16 Nov 2002 00:14:33 -0500 (EST) Message-ID: <3DD5D436.5080800@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] 3GPP Messaging requirements References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945054@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Sat, 16 Nov 2002 00:14:30 -0500 Content-Transfer-Encoding: 8bit Aki, My apologies for not taking a look at this till now. This is a good collection of requirements. As you know, I think most of them are addressed already. A few comments on some of them: > It MUST be possible to use a single address to identify the recipient > or sender of an instant message or a member in a message session, > irrespective of the messaging system. I wasn't sure what to make of this requirement. Is this asking for something new from SIP? You can put whatever kind of address you want into the From field of a MESSAGE request or an INVITE to set up a session... > Additionally, it MUST be possible to send the entire message body, or > parts of the body in a way that allows the recipient to choose > between receivng the body and ignoring it. parts of the body? What does that mean? Do you mean I can ask to receive the top half of a jpeg only? I hope not. If you are just talking about receiving parts on a body-by-body basis, clearly indirection is the right solution for this. > 3.3 Data Manipulation and Management Requirements I suspect all of these will be met by the conference control protocol work going on in sipping. > It MUST be possible to divert or block instant messages as part of a > user configurable option. Such mechanisms MUST support instant > message diversion based on sender address, message size, message > priority, message subject, message class and message content type. what is message class? > It is proposed that the SIMPLE Working Group evaluates the > requirements presented in this document and incorporates the relevant > ones in its current work items. Those requirements possibly falling > out of the scope of the SIMPLE WG should find a more suitable home, > possibly also in other standardization bodies. As I commented at the last IETF, I would propose that those requirements which do belong to SIMPLE get folded into our general work item on advanced IM requirements. -Jonathan R. aki.niemi@nokia.com wrote: > Hi All, > > Like promised in Yokohama, there is now a document available > describing the 3GPP requirements to Instant Messaging. It lists > requirements for both pager mode and session mode IM. Here's a link > for your convenience: > > http://www.ietf.org/internet-drafts/draft-niemi-simple-im-wireless-re- > qs-00.txt > > I'd especially like to draw your attention to the requirements for > session mode IM, as well as the requirements for data manipulation. > > Note also, that when 3GPP talks about session based messaging, there > is a strong flavor of multiparty sessions to it. The conferencing > aspects, and the chat-room type aspects of this document should be > considered already in the current message session work. > > Cheers, Aki > > _______________________________________________ simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Nov 16 00:33: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 AAA01102 for ; Sat, 16 Nov 2002 00:33: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 gAG5YR5r023331; Sat, 16 Nov 2002 00:34:27 -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 AAA21684; Sat, 16 Nov 2002 00:35:07 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21671 for ; Sat, 16 Nov 2002 00:34:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAG5YeYH001201; Sat, 16 Nov 2002 00:34:40 -0500 (EST) Message-ID: <3DD5D8ED.7070704@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: pkyzivat@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD19@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sat, 16 Nov 2002 00:34:37 -0500 Content-Transfer-Encoding: 7bit I think the basic idea behind these drafts is a good one. There is clear value in knowing, at a watcher, more details on each of the contact addresses in the presence document. There are a bunch of issues here which require further discussion: 1. Assuming the watcher "picks" one of the contact addresses, and decides to communicate with it by sending it an INVITE, how should that INVITE look? If the URI in the contact element is the AOR of the user, does the watcher need to add caller preferences (Require-Contact) in order to reach that specific UA instance? More generally, what is the meaning of these capabilities attributes? Does it mean that there exists some UA behind that URI with those capabilities? Does it mean that any UA reached with that URI is guaranteed to have those capabilities? I think what you want is the former. I also think that you are not going to be able to put the actual Contact URI into the PIDF doc; it will need to be some kind of AOR, but one that routes to a specific UA instance. 2. One of the things I am not particularly fond of in the current caller prefs spec is the limitation on the capabilities predicate (conjunctive normal form only). That restriction exists because of the syntactic limitations of using contact parameters, and of the need for a simple matching algorithm in proxies to support routing. I would like to leave the door open for much more complex capabilities documents, which can be uploaded by a UA and used for other things, NOT call routing necessarily. Here is a good example of a use case that does not need to suffer the limitations of caller prefs. It would be nice if we can be more general. w3c has done a lot of work in describing capabilities (CC/PP, RDF), all of which is XML-based. I wonder if there is a better fit here to use that kind of syntax? -Jonathan R. mikko.lonnfors@nokia.com wrote: > Hi, > > inline > > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: 29 October, 2002 17:06 >>To: simple@mailman.dynamicsoft.com >>Subject: Re: [Simple] FW: I-D >>ACTION:draft-lonnfors-simple-prescaps-ext-00.txt >> >> >>mikko.lonnfors@nokia.com wrote: >> >>>Hi, >>> >>>New draft is now available. Basically draft presents a >> >>solution for the requirements presented in >>draft-kyzivat-simple-prescaps-reqts-00.txt. >> >>>All comments are welcome. >> >>Obviously Mikko and I have been cooperating on this. We were >>both interested in the subject. I thought it would be helpful >>to be clear about the requirements rather than jumping >>directly to a proposed solution, so I posted a requirements >>draft last week. Since then I have been waiting for Mikko to >>submit this in order to have more fodder for discussion. >> >>There is already a work item to produce a SIP-specific >>profile for PIDF. I consider these drafts to be a *partial* >>response to that work item. I realize there is a desire for >>some addition generalized status values beyond open/closed, >>such as busy. That is a minefield, and we have chosen not to >>address it. Instead, we are focusing on some attributes that >>should be less controversial because they are drawn from the >>callerprefs draft, whose basic concepts have been accepted >>for a long time. (I am open to discussion about whether these >>specific drafts should be expanded to cover the more general >>requirement, or whether that should be left separate.) >>The assertion of these drafts is that capabilities a UAS can >>specify when registering are information that is equally >>important in a presence document. I believe Mikko is most >>concerned with supported media. I also consider that to be of >>major importance, but I also believe all the others are of >>potential value in a presence document. > > > This topic was first discussed in IMPP mailing list related to PIDF communication means. After some discussion it was concluded that this work might fit better to SIMPLE WG agenda. > I would also like to see some comments to the requirements draft. A small problem in writing that was that there were no requirements for callerpreferences and because of that we have tried to put quite a lot motivational and explanative text into requirements. It would be very helpful to hear also other people comments to this. If the overall idea is acceptable then the exact requirements should be quite clear. At least requirements 1, 2, and 3 should be quite self-evident (I hope). Requirement 4 is now marked with SHOULD level and I would like to hear if it would be good idea to move it to MUST level. Also I am not sure we have been able to collect all relevant requirements so if something seems to be missing please let us know. > > >>The callerprefs draft is still itself in a state of flux. The >>work here should remain dependent on the outcome of that >>work. But I believe it would be helpful to begin progressing >>these documents now. > > > We have tried to keep this draft as independent of callerprefs as possible but there is of course quite heavy dependency between these two. > > Here are some open items for solution draft: > - At a moment draft allows use of extension in two places inside PIDF document (inside and . Should we specify the exact location where this extension can be used within PIDF document. > - We went through 2 or 3 different XML schemas before ending up with current one. Obviously there is lot of different options and if someone thinks there exists better alternatives then this can be discussed. > - We ended up using negated attribute inside elements to indicate whether value is supporter or not supported. There are also other alternatives to represent this. One alternative would be to replace with either or element. > > - Mikko > > >> Paul >>_______________________________________________ >>simple mailing list >>simple@mailman.dynamicsoft.com >>http://mailman.dynamicsoft.com/mailman/listinfo/simple >> > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Nov 16 01:18: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 BAA01834 for ; Sat, 16 Nov 2002 01:18: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 gAG6J75r023472; Sat, 16 Nov 2002 01:19: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 BAA21864; Sat, 16 Nov 2002 01:20:10 -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 BAA21851 for ; Sat, 16 Nov 2002 01:19:51 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAG6JqYH001216; Sat, 16 Nov 2002 01:19:53 -0500 (EST) Message-ID: <3DD5E384.3090103@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] FW: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sat, 16 Nov 2002 01:19:48 -0500 Content-Transfer-Encoding: 7bit This draft is a good start. I would very much like to do this as generally as possible. Clearly, there are a number of different ways to design a protocol to meet the requirements in the data-req draft. They range from the totally specific to totally general: * PROTOCOL OPTION 1: We design a protocol that JUST does whats in the requirements doc, nothig more, nothing less. Its simple, but it only works for buddy lists and authorization policy. It won't work for conference policy, for example. * PROTOCOL OPTION 2: Markus' draft. Generalize option 1 a bit. Focus on lists of things, and define a general protocol for creating, modifying and managing lists. Works for buddy lists and conferencing too, so long as all they do is manage lists. * PROTOCOL OPTION 3: Generalize Markus' draft further. Assume that anything we want to manipulate can be represented in XML. Conference policies might be modelled as really complex XML documents. Media policies too. A buddy list is an XML document. And so on. The protocol, then, is a general tool for remote editing of XML documents. Using things like XPath, you can address a particular node, add elements, modify them, etc. The underlying application (conferencing, buddy list) validates the changes against its schemas, and assignes semantics to the documents. There are probably more sub-options between 2 and 3. For example, we cna introduce restrictions on the types of XML documents we can manipulate, the types of changes we can make, and so on. Where do draw the line? Clearly, we want something simple so that we can be done soon. Simple is always good. However, I would also like a single protocol that can meet the requirements here, AND the requirements for conference policy control and media policy control that are evolving in SIPPING. Conference policy is complex enough that a simple list won't suffice. So, I think we need a bit more that what Markus has defined. Thoughts? -Jonathan R. Markus.Isomaki@nokia.com wrote: > Hi, > > The following draft is now available in the I-D directories. It is an > initial attempt to specify a list management protocol on an abstract > level (only semantics, no syntax). The proposal is made based on the > requirements stated in "draft-ietf-simple-data-req-00". The draft is > still quite drafty, but the main points should be visible. > > The main idea is that many applications (for instance presence and > conferencing) require lists that should be configurable by a client > terminal. It would be useful to define a standard protocol to handle > list manipulation (for SIP-applications), so that it could be > "plugged in" to any application needing it. > > I hope comments to the approach and to the actual abstract protocol. > If this is a good enough start, it could be used as a basis for a WG > document. After that would be reasonably stable, a mapping to some > real syntax could be made and that specifation should be in standards > track. > > Markus > > >> -----Original Message----- From: ext Internet-Drafts@ietf.org >> [mailto:Internet-Drafts@ietf.org] Sent: 04 November, 2002 17:05 >> Subject: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Semantic Description of SIMPLE List Manipulation >> Operations Author(s) : M. Isomaki et al. Filename : >> draft-isomaki-simple-list-man-sem-00.txt Pages : 13 Date : >> 2002-11-1 In SIMPLE based presence and messaging applications, it >> is necessary for the user to be able to configure a number of >> pieces of information. One of the most common types of information >> is a list of URIs. List management is useful outside the scope of >> SIMPLE as well, for instance in conferencing. There are many >> reasons why it would be beneficial to manage the lists in a similar >> fashion regardless of the application. Before the selection of the >> actual protocol(s) to manage the lists there is a need to describe >> their semantics on an abstract level. This document proposes the >> semantics for SIMPLE list manipulation protocol. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-isomaki-simple-list- > > man-sem-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then "get > draft-isomaki-simple-list-man-sem-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: mailserv@ietf.org. In the body type: "FILE > /internet-drafts/draft-isomaki-simple-list-man-sem-00.txt". NOTE: > The mail server at ietf.org can return the document in MIME-encoded > form by using the "mpack" utility. To use this feature, insert the > command "ENCODING mime" before the "FILE" command. To decode the > response(s), you will need "munpack" or a MIME-compliant mail reader. > Different MIME-compliant mail readers exhibit different behavior, > especially when dealing with "multipart" MIME messages (i.e. > documents which have been split up into multiple messages), so check > your local documentation on how to manipulate these messages. Below > is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Nov 16 01:47: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 BAA02087 for ; Sat, 16 Nov 2002 01:47: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 gAG6m05r023623; Sat, 16 Nov 2002 01:48: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 BAA22028; Sat, 16 Nov 2002 01:49: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 BAA22017 for ; Sat, 16 Nov 2002 01:48:29 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAG6mUYH001239; Sat, 16 Nov 2002 01:48:31 -0500 (EST) Message-ID: <3DD5EA3A.2040702@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Comments on Data Manipulation Requirements References: <2038BCC78B1AD641891A0D1AE133DBB7FE6FC1@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sat, 16 Nov 2002 01:48:26 -0500 Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > Hi, > > Section 5.1 REQ 2: This requirement is talking about rejecting a > subscriber not belonging in an "Allowed Watchers" list. Should > rejecting only be based on subscribers belonging to "Blocked > Watchers". In this case, REQ 2 would be changed to talk about adding > that subscriber to a "Pending Watchers" list and accepting the > subscription. (Or do we need both REQ 2 as it stands and REQ 2 as I > suggest?) I'm not sure I fully understand the question. I think you are asking about pending watchers. The current acceptance requirements don't talk about pending cases. I would add these as separate requirements, something like: REQ XX: It MUST be possible for the acceptance policy to specify that if a user is not on a blocked or allowed list, they are pending, such that a watcherinfo notification is used to query authorization. I don't think it makes sense to have an explicit "pending list". > > REQ 7.7: This is similar to REQ 7 in section 4, should both > requirements carry the same strength (MUST or SHOULD)? Good catch. Generally, I need to make these more consistent. > > REQ 7.8: should it continue specifying that "If the URI cannot be > allocated (because it already exists, for example), it MUST be > possible to inform the client of the failure, and the reason for it"? > This aligns it with REQ 2 in section 4. Yes. > > REQ 7.9: This is similar to REQ 3 in section 4, should both > requirements carry the same strength (MUST or SHOULD)? REQ 7.9: > should it continue specifying that this happens in case user does not > provide one? This aligns it with REQ 3 in section 4. Yes. > > Section 5.2 REQ 4: I don't quite understand this one. Is it talking > about filters in subscribe specifying higher rate that the minimum? Its talking about filters in the sense of: http://www.ietf.org/internet-drafts/draft-moran-sipping-filter-reqs-00.txt so, if someone asks to be notified about changes only to my geolocation, I can reject that subscription. > > Section 5.3 REQ 3: This can result in a NOTIFY with no tuples. Is > that Ok? should the NOTIFY be sent? if so, what does it mean? I think thats a level deeper than the requirements need to address. I suspect that, if the filtering implied that there was no presence document left, the NOTIFY would not be sent. > > REQ 4: Tuples cannot be meaningfully identified. Communication means > might be a better choice. Well, PIDF doesn't really define communications means either. This is something that the lonnfors prescaps draft could help us with. It would provide a meaningful way to identify tupples. I could specify something like "don't report tuples that support voice calls". > > Back to section 3: > > It states that a PA can receive a subscription with presence list > uri. Are we assuming that a PA is a PLS? Does a PA's definition allow > for this? This is irrelevant to this draft anyway. Its a bit of a stretch of the term PA, since we are applying it to something whcih can terminate the presence event package or the presence.collection package. Clearly the latter is outside the definition provided in the baseline presence spec. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Nov 16 11:04: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 LAA19695 for ; Sat, 16 Nov 2002 11:04: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 gAGG585r024313; Sat, 16 Nov 2002 11:05: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 LAA23649; Sat, 16 Nov 2002 11:06:09 -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 LAA23637 for ; Sat, 16 Nov 2002 11:05:26 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAGG5eS7008044; Sat, 16 Nov 2002 11:05:40 -0500 (EST) Received: from cisco.com (rtp-vpn2-716.cisco.com [10.82.242.204]) by cannon.cisco.com (Mirapoint) with ESMTP id AAU99480; Sat, 16 Nov 2002 11:10:11 -0500 (EST) Message-ID: <3DD66CBC.A986100@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: mikko.lonnfors@nokia.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD19@esebe004.ntc.nokia.com> <3DD5D8ED.7070704@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: Sat, 16 Nov 2002 11:05:16 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > I think the basic idea behind these drafts is a good one. There is clear > value in knowing, at a watcher, more details on each of the contact > addresses in the presence document. > > There are a bunch of issues here which require further discussion: Yup. We were expecting discussion. > > 1. Assuming the watcher "picks" one of the contact addresses, and > decides to communicate with it by sending it an INVITE, how should that > INVITE look? If the URI in the contact element is the AOR of the user, > does the watcher need to add caller preferences (Require-Contact) in > order to reach that specific UA instance? My assumption has been that if the watcher picks one of the contact addresses, he then just sends the invite to it. It is up to the publisher of presence to arrange things so that does the right thing. The publisher can identify separate tuples each with a particular set of capabilities, and yet provide a single AOR for all of them. In that case it is in effect promising to provide a smart proxy at the AOR that can do the right thing. Or the publisher can provide an actual individual contact address for each tuple. In that case it is promising that the contact addresses are usable by presence subscribers. In the end, the publisher is in the driver's seat, and publishing what it willing to expose and what it thinks will be useful to subscribers. There clearly is a tradeoff between those two things, and the publisher is the one that ought to decide. Whether the subscriber should put callerprefs on the invite is a good question. If the algorithm the subscriber uses to choose between the contacts can be represented by callerprefs then it probably wouldn't hurt and might help. This needs further discussion. > > More generally, what is the meaning of these capabilities attributes? > Does it mean that there exists some UA behind that URI with those > capabilities? Does it mean that any UA reached with that URI is > guaranteed to have those capabilities? I think what you want is the > former. I agree. > I also think that you are not going to be able to put the actual > Contact URI into the PIDF doc; it will need to be some kind of AOR, but > one that routes to a specific UA instance. As I mention above, this is really the responsibility of the publisher. It would be stupid of the publisher to insert URIs that cannot be used by subscribers. But I don't see any reason to otherwise restrict this. > > 2. One of the things I am not particularly fond of in the current caller > prefs spec is the limitation on the capabilities predicate (conjunctive > normal form only). That restriction exists because of the syntactic > limitations of using contact parameters, and of the need for a simple > matching algorithm in proxies to support routing. I would like to leave > the door open for much more complex capabilities documents, which can be > uploaded by a UA and used for other things, NOT call routing > necessarily. Here is a good example of a use case that does not need to > suffer the limitations of caller prefs. It would be nice if we can be > more general. Yes!!! Thanks for mentioning this. I was waiting for this to get out for general discussion before bringing it up. I would welcome suggestions for enhancements to the requirements. > > w3c has done a lot of work in describing capabilities (CC/PP, RDF), all > of which is XML-based. I wonder if there is a better fit here to use > that kind of syntax? Could be. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Nov 16 11:45: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 LAA20683 for ; Sat, 16 Nov 2002 11:45: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 gAGGk25r024453; Sat, 16 Nov 2002 11: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 LAA23810; Sat, 16 Nov 2002 11:47:04 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23799 for ; Sat, 16 Nov 2002 11:46:46 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAGGkFO04349 for ; Sat, 16 Nov 2002 18:46:15 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 16 Nov 2002 18:46:43 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 16 Nov 2002 18:46:45 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 16 Nov 2002 18:46:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD53@esebe004.ntc.nokia.com> Thread-Topic: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt Thread-Index: AcKNMdyTvtocwuOhTCuQP8uHI3ToeAAUkU4A To: Cc: , X-OriginalArrivalTime: 16 Nov 2002 16:46:44.0656 (UTC) FILETIME=[BF25CB00:01C28D8F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA23799 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, 16 Nov 2002 18:46:43 +0200 Content-Transfer-Encoding: 8bit Hi, Thanks for comments. Mine are inline, > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 16 November, 2002 07:35 > To: Lonnfors Mikko (NRC/Helsinki) > Cc: pkyzivat@cisco.com; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] FW: I-D > ACTION:draft-lonnfors-simple-prescaps-ext-00.txt > > > I think the basic idea behind these drafts is a good one. > There is clear > value in knowing, at a watcher, more details on each of the contact > addresses in the presence document. > > There are a bunch of issues here which require further discussion: > > > 1. Assuming the watcher "picks" one of the contact addresses, and > decides to communicate with it by sending it an INVITE, how > should that > INVITE look? If the URI in the contact element is the AOR of > the user, > does the watcher need to add caller preferences (Require-Contact) in > order to reach that specific UA instance? This is one of the issues which is currently completely unspecified in the draft. I have a bit mixed feeling how we should proceed which this one. As the decision is based on presence info watchers have quite a lot freedom how they can initiate communication with the presentity. I am not sure if it makes much sense to mandate any strict behavior from UAs but I think we could give recommendations. This topic definitely deserves more discussion. > More generally, what is the meaning of these capabilities attributes? > Does it mean that there exists some UA behind that URI with those > capabilities? Does it mean that any UA reached with that URI is > guaranteed to have those capabilities? I think what you want is the > former. Yes, this is probably the case. >I also think that you are not going to be able to put > the actual > Contact URI into the PIDF doc; it will need to be some kind > of AOR, but > one that routes to a specific UA instance. Yes, this has been my assumption. > > 2. One of the things I am not particularly fond of in the > current caller > prefs spec is the limitation on the capabilities predicate > (conjunctive > normal form only). That restriction exists because of the syntactic > limitations of using contact parameters, and of the need for a simple > matching algorithm in proxies to support routing. I would > like to leave > the door open for much more complex capabilities documents, > which can be > uploaded by a UA and used for other things, NOT call routing > necessarily. Here is a good example of a use case that does > not need to > suffer the limitations of caller prefs. It would be nice if we can be > more general. Yes, I definitely agree. The question seems to be if it is sufficient to give current functionality with ability to extend it using XML namespaces or is there need to define addition functionality to support more complex features. > w3c has done a lot of work in describing capabilities (CC/PP, > RDF), all > of which is XML-based. I wonder if there is a better fit here to use > that kind of syntax? I am not very familiar with work done in w3c in this area but I will take a look. - Mikko > -Jonathan R. > > mikko.lonnfors@nokia.com wrote: > > Hi, > > > > inline > > > > > >>-----Original Message----- > >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: 29 October, 2002 17:06 > >>To: simple@mailman.dynamicsoft.com > >>Subject: Re: [Simple] FW: I-D > >>ACTION:draft-lonnfors-simple-prescaps-ext-00.txt > >> > >> > >>mikko.lonnfors@nokia.com wrote: > >> > >>>Hi, > >>> > >>>New draft is now available. Basically draft presents a > >> > >>solution for the requirements presented in > >>draft-kyzivat-simple-prescaps-reqts-00.txt. > >> > >>>All comments are welcome. > >> > >>Obviously Mikko and I have been cooperating on this. We were > >>both interested in the subject. I thought it would be helpful > >>to be clear about the requirements rather than jumping > >>directly to a proposed solution, so I posted a requirements > >>draft last week. Since then I have been waiting for Mikko to > >>submit this in order to have more fodder for discussion. > >> > >>There is already a work item to produce a SIP-specific > >>profile for PIDF. I consider these drafts to be a *partial* > >>response to that work item. I realize there is a desire for > >>some addition generalized status values beyond open/closed, > >>such as busy. That is a minefield, and we have chosen not to > >>address it. Instead, we are focusing on some attributes that > >>should be less controversial because they are drawn from the > >>callerprefs draft, whose basic concepts have been accepted > >>for a long time. (I am open to discussion about whether these > >>specific drafts should be expanded to cover the more general > >>requirement, or whether that should be left separate.) > >>The assertion of these drafts is that capabilities a UAS can > >>specify when registering are information that is equally > >>important in a presence document. I believe Mikko is most > >>concerned with supported media. I also consider that to be of > >>major importance, but I also believe all the others are of > >>potential value in a presence document. > > > > > > This topic was first discussed in IMPP mailing list related > to PIDF communication means. After some discussion it was > concluded that this work might fit better to SIMPLE WG agenda. > > I would also like to see some comments to the requirements > draft. A small problem in writing that was that there were no > requirements for callerpreferences and because of that we > have tried to put quite a lot motivational and explanative > text into requirements. It would be very helpful to hear also > other people comments to this. If the overall idea is > acceptable then the exact requirements should be quite clear. > At least requirements 1, 2, and 3 should be quite > self-evident (I hope). Requirement 4 is now marked with > SHOULD level and I would like to hear if it would be good > idea to move it to MUST level. Also I am not sure we have > been able to collect all relevant requirements so if > something seems to be missing please let us know. > > > > > >>The callerprefs draft is still itself in a state of flux. The > >>work here should remain dependent on the outcome of that > >>work. But I believe it would be helpful to begin progressing > >>these documents now. > > > > > > We have tried to keep this draft as independent of > callerprefs as possible but there is of course quite heavy > dependency between these two. > > > > Here are some open items for solution draft: > > - At a moment draft allows use of extension in two places > inside PIDF document (inside and . Should we > specify the exact location where this extension can be used > within PIDF document. > > - We went through 2 or 3 different XML schemas before > ending up with current one. Obviously there is lot of > different options and if someone thinks there exists better > alternatives then this can be discussed. > > - We ended up using negated attribute inside > elements to indicate whether value is supporter or not > supported. There are also other alternatives to represent > this. One alternative would be to replace with either > or element. > > > > - Mikko > > > > > >> Paul > >>_______________________________________________ > >>simple mailing list > >>simple@mailman.dynamicsoft.com > >>http://mailman.dynamicsoft.com/mailman/listinfo/simple > >> > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Nov 17 13:46: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 NAA23244 for ; Sun, 17 Nov 2002 13:46: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 gAHIlC5r026300; Sun, 17 Nov 2002 13:47: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 NAA28230; Sun, 17 Nov 2002 13:48: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 NAA28219 for ; Sun, 17 Nov 2002 13:47:08 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAHIkZO29240 for ; Sun, 17 Nov 2002 20:46:35 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 17 Nov 2002 20:47:06 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 17 Nov 2002 20:47:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [Simple] 3GPP Messaging requirements Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD07D@esebe013.ntc.nokia.com> Thread-Topic: [Simple] 3GPP Messaging requirements Thread-Index: AcKNLw2ZRv0Ud+GgQkSSDcjpfrK6WgBJqf/g To: Cc: X-OriginalArrivalTime: 17 Nov 2002 18:47:06.0771 (UTC) FILETIME=[BA46D630:01C28E69] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA28219 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, 17 Nov 2002 20:47:06 +0200 Content-Transfer-Encoding: 8bit Hi Jonathan, Thanks for your comments. I've got some inline. [...] > This is a good collection of requirements. As you know, I > think most of > them are addressed already. A few comments on some of them: I agree. I think from the 3GPP point of view, they just like to keep a comprehensive list of their requirements in this I-D. But we definitely should focus on the ones which do not seem to be covered already. > > It MUST be possible to use a single address to identify the > recipient > > or sender of an instant message or a member in a message session, > > irrespective of the messaging system. > > I wasn't sure what to make of this requirement. Is this asking for > something new from SIP? You can put whatever kind of address you want > into the From field of a MESSAGE request or an INVITE to set > up a session... The original requirements were pretty vague, so my interpretation was that this was actually requiring CPIM compliance. The other requirement is for using E.164 numbers. So nothing new there I think. Both are already enabled. > > Additionally, it MUST be possible to send the entire > message body, or > > parts of the body in a way that allows the recipient to choose > > between receivng the body and ignoring it. > > parts of the body? What does that mean? Do you mean I can ask > to receive > the top half of a jpeg only? I hope not. No, simply if there is a MIME multipart body. This is poor wording from my part. It probably should say parts of the payload instead of body. > If you are just talking about receiving parts on a > body-by-body basis, > clearly indirection is the right solution for this. Definitely, CI was what we were also thinking of. > > 3.3 Data Manipulation and Management Requirements > > I suspect all of these will be met by the conference control protocol > work going on in sipping. Yes, that seems to be the best home for these requirements. > > It MUST be possible to divert or block instant messages as part of a > > user configurable option. Such mechanisms MUST support instant > > message diversion based on sender address, message size, message > > priority, message subject, message class and message > content type. > > what is message class? The 3GPP documents define message class as being e.g., advertisement, announcement, personal, and so on. Frankly I had trouble with this as well, since message class is obviously not available currently in SIP, so I was doubtful as to whether this is actually a protocol issue at all. There may actually be a hidden requirement here, something like: There MUST be a mechanism available by which the sender of an instant message can set a specific class for the message. Possible classes could be 'advertisement', for commercial messages, and 'personal' for messages intended for personal consumption. Either this, or the message diversion could also depend on an implementation specific mechanism for grouping messages to classes. (I'm well aware of the futility of the message class type mechanisms, and I'm not expecting spammers to actually mark their messages as spam...) > > It is proposed that the SIMPLE Working Group evaluates the > > requirements presented in this document and incorporates > the relevant > > ones in its current work items. Those requirements > possibly falling > > out of the scope of the SIMPLE WG should find a more > suitable home, > > possibly also in other standardization bodies. > > As I commented at the last IETF, I would propose that those > requirements > which do belong to SIMPLE get folded into our general work item on > advanced IM requirements. I agree. But just to have the complete list available, I'll keep updating this document. And keep track of the requirements and where they end up. Cheers, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Nov 17 14: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 OAA23743 for ; Sun, 17 Nov 2002 14: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 gAHJL15r026419; Sun, 17 Nov 2002 14:21: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 OAA28388; Sun, 17 Nov 2002 14:22:05 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28377 for ; Sun, 17 Nov 2002 14:21:58 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAHJMhB29122 for ; Sun, 17 Nov 2002 21:22:43 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 17 Nov 2002 21:21:57 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 17 Nov 2002 21:21:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] FW: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt Message-ID: Thread-Topic: [Simple] FW: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt Thread-Index: AcKNOHrmlD0m2hVmQu6OThzVec2WkABNA8Fw To: Cc: X-OriginalArrivalTime: 17 Nov 2002 19:21:57.0260 (UTC) FILETIME=[984E24C0:01C28E6E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA28377 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, 17 Nov 2002 21:21:56 +0200 Content-Transfer-Encoding: 8bit Hi, I would be happy with a more generalized solution than what is being discussed in my draft. I think SIMPLE data manipulation and conference policy control protocol should be solved within the same framework. Using XML schemas for manipulated objects (such as lists) and using XPath etc. to implement generic manipulation operations would be a good candidate. Actually, I think XPath might be a good solution to presence event filtering as well. The question now is how to go forward. I wrote the list manipulation 'semantics' draft, because people were saying that it is not possible to pick a particular solution, such as XML or SOAP, straight away. Maybe we should first make even some higher level decisions, such as whether to follow PROTOCOL OPTION 1, 2 or 3 from Jonathan's mail. I'll try to raise some discussion about this during my presentation in SIMPLE. Also, I'll try to find out how many people are actually willing to allocate some time to work on this, to have a commonly agreed approach within that group. There hasn't been much discussion on the mailing list. Markus > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 16 November, 2002 08:20 > To: Isomaki Markus (NRC/Helsinki) > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] FW: I-D > ACTION:draft-isomaki-simple-list-man-sem-00.txt > > > This draft is a good start. > > I would very much like to do this as generally as possible. Clearly, > there are a number of different ways to design a protocol to meet the > requirements in the data-req draft. They range from the > totally specific > to totally general: > > * PROTOCOL OPTION 1: We design a protocol that JUST does whats in the > requirements doc, nothig more, nothing less. Its simple, but it only > works for buddy lists and authorization policy. It won't work for > conference policy, for example. > > * PROTOCOL OPTION 2: Markus' draft. Generalize option 1 a > bit. Focus on > lists of things, and define a general protocol for creating, > modifying > and managing lists. Works for buddy lists and conferencing > too, so long > as all they do is manage lists. > > * PROTOCOL OPTION 3: Generalize Markus' draft further. Assume that > anything we want to manipulate can be represented in XML. Conference > policies might be modelled as really complex XML documents. Media > policies too. A buddy list is an XML document. And so on. The > protocol, > then, is a general tool for remote editing of XML documents. Using > things like XPath, you can address a particular node, add elements, > modify them, etc. The underlying application (conferencing, > buddy list) > validates the changes against its schemas, and assignes > semantics to the > documents. > > > There are probably more sub-options between 2 and 3. For > example, we cna > introduce restrictions on the types of XML documents we can > manipulate, > the types of changes we can make, and so on. > > Where do draw the line? > > Clearly, we want something simple so that we can be done > soon. Simple is > always good. > > However, I would also like a single protocol that can meet the > requirements here, AND the requirements for conference policy control > and media policy control that are evolving in SIPPING. > Conference policy > is complex enough that a simple list won't suffice. So, I > think we need > a bit more that what Markus has defined. > > Thoughts? > > -Jonathan R. > > Markus.Isomaki@nokia.com wrote: > > Hi, > > > > The following draft is now available in the I-D > directories. It is an > > initial attempt to specify a list management protocol on > an abstract > > level (only semantics, no syntax). The proposal is made > based on the > > requirements stated in "draft-ietf-simple-data-req-00". > The draft is > > still quite drafty, but the main points should be visible. > > > > The main idea is that many applications (for instance presence and > > conferencing) require lists that should be configurable by a client > > terminal. It would be useful to define a standard protocol > to handle > > list manipulation (for SIP-applications), so that it could be > > "plugged in" to any application needing it. > > > > I hope comments to the approach and to the actual abstract > protocol. > > If this is a good enough start, it could be used as a > basis for a WG > > document. After that would be reasonably stable, a mapping to some > > real syntax could be made and that specifation should be > in standards > > track. > > > > Markus > > > > > >> -----Original Message----- From: ext Internet-Drafts@ietf.org > >> [mailto:Internet-Drafts@ietf.org] Sent: 04 November, 2002 17:05 > >> Subject: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> > >> Title : Semantic Description of SIMPLE List > Manipulation > >> Operations Author(s) : M. Isomaki et al. Filename : > >> draft-isomaki-simple-list-man-sem-00.txt Pages > : 13 Date : > >> 2002-11-1 In SIMPLE based presence and messaging applications, it > >> is necessary for the user to be able to configure a number of > >> pieces of information. One of the most common types of information > >> is a list of URIs. List management is useful outside the scope of > >> SIMPLE as well, for instance in conferencing. There are many > >> reasons why it would be beneficial to manage the lists in > a similar > >> fashion regardless of the application. Before the selection of the > >> actual protocol(s) to manage the lists there is a need to describe > >> their semantics on an abstract level. This document proposes the > >> semantics for SIMPLE list manipulation protocol. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-isomaki-simple-list- > > > > man-sem-00.txt > > > > To remove yourself from the IETF Announcement list, send a > message to > > ietf-announce-request with the word unsubscribe in the body of the > > message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then "get > > draft-isomaki-simple-list-man-sem-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: mailserv@ietf.org. In the body type: "FILE > > /internet-drafts/draft-isomaki-simple-list-man-sem-00.txt". NOTE: > > The mail server at ietf.org can return the document in MIME-encoded > > form by using the "mpack" utility. To use this feature, insert the > > command "ENCODING mime" before the "FILE" command. To decode the > > response(s), you will need "munpack" or a MIME-compliant > mail reader. > > Different MIME-compliant mail readers exhibit different behavior, > > especially when dealing with "multipart" MIME messages (i.e. > > documents which have been split up into multiple > messages), so check > > your local documentation on how to manipulate these > messages. Below > > is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Nov 17 14:50: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 OAA24182 for ; Sun, 17 Nov 2002 14:50: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 gAHJp75r026499; Sun, 17 Nov 2002 14: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 OAA28498; Sun, 17 Nov 2002 14:52:08 -0500 (EST) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28487 for ; Sun, 17 Nov 2002 14:51:35 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gAHJpXe02328 for ; Sun, 17 Nov 2002 14:51:33 -0500 (EST) Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sun, 17 Nov 2002 19:51:32 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB006B27C3D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Eric Burger , Jose.Costa-Requena@nokia.com Cc: bindignavile.srinivas@nokia.com, Stephane.Coulombe@nokia.com, jon.peterson@neustar.biz, Markus.Isomaki@nokia.com, dean.willis@softarmor.com, drage@lucent.com, Gonzalo.Camarillo@lmf.ericsson.se, sipping@ietf.org, Pekka.Pessi@nokia.com, simple@mailman.dynamicsoft.com, ietf-openproxy@imc.org, UM list , um@snowshore.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="UTF-8" Subject: [Simple] RE: [Sipping] Multimedia message adaptationInternet-Drafts 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, 17 Nov 2002 19:51:29 -0000 SIPPING is in the transport area because SIP is. SIP is in the transport area because MMUSIC is. I assume that the transport area allocation was made because of the http like origin of SIP. It would be hard to argue that SIP acts like http today, or indeed is used like http. I have heard several people who matter argue that if SIP was allocated to an area today it would be in the application area, and certainly much of the aspects of the work are application layer issues, not transport ones. I therefore see no reason to argue that application level material cannot be discussed in either SIP or SIPPING. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: 14 November 2002 14:18 > To: Jose.Costa-Requena@nokia.com > Cc: bindignavile.srinivas@nokia.com; Stephane.Coulombe@nokia.com; > jon.peterson@neustar.biz; Markus.Isomaki@nokia.com; > dean.willis@softarmor.com; drage@lucent.com; > Gonzalo.Camarillo@lmf.ericsson.se; sipping@ietf.org; > Pekka.Pessi@nokia.com; simple@mailman.dynamicsoft.com; > ietf-openproxy@imc.org; UM list; um@snowshore.com > Subject: RE: [Sipping] Multimedia message adaptationInternet-Drafts > > > I understand the sentiment. Neither opes nor lemonade are > perfect fits for the current proposals. However, I would > offer that the proper home for media adaptation is either > opes or lemonade. > > My rationale is simple. Sipping is a transport area work > group. The experts in the group are transport experts. The > AD's are transport AD's. Media transformation is an > application. Opes and lemonade are application work groups. > The experts in the groups are application experts. The AD's > are application AD's. > > I agree that there may be refinement or conventions that will > be needed in SIP to support real-time media transformation. > The correct place for that to happen is sipping. However, > the right people with expertise in media transformation are > in the opes and lemonade groups. > > From a charter point of view, media transformation (IMHO) is > way out of scope for sipping. We've heard from Abbie that it > is sort of out of scope for opes, as opes is focusing on > HTTP. On the other hand, the mechanism being proposed is > rather close to the lemonade work. > > I think this work fits into lemonade charter items 1 > (retrieval protocols) and 5 (translation services). We can > refine the language to explicitly contain the real-time > adaptation work items, if that would make everyone happy. > > -- > - Eric > > > > > SIPPING is for SIP. OPES and LEMONADE are specifically for > media transformation. Said differently, we have transport > experts in SIPPING and application experts in OPES and LEMONADE. > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Wed 11/13/2002 9:00 PM > To: Jose.Costa-Requena@nokia.com > Cc: bindignavile.srinivas@nokia.com; Eric Burger; > Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; > Markus.Isomaki@nokia.com; dean.willis@softarmor.com; > drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se; > sipping@ietf.org; Pekka.Pessi@nokia.com; > simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM list > Subject: Re: [Sipping] RE: [Simple] Multimedia message > adaptationInternet-Drafts > > > > hello, > > please cease an desist cross posting when you reply. > sipping seems > like the default wg, so please send your comments only to > sipping@ietf.org. > > thanks, > -rohan > > On Wednesday, November 13, 2002, at 07:35 AM, > Jose.Costa-Requena@nokia.com wrote: > > > Hi, > > > > According to LEMONADE requirements, it is considering > mainly messaging > > systems and I agree that this proposal could fit into > that context at > > some extent. Nevertheless, the actual proposal deals > with content > > adaptation based on UA capabilities registered with > SIP. Thus, I > > consider that it is within SIPPING scope, as well. > > Comments? > > BR > > Jose > > > > -----Original Message----- > > From: Srinivas Bindignavile (NRC/Boston) > > Subject: RE: [Sipping] RE: [Simple] Multimedia message > > adaptationInternet-Drafts > > > > > > Hi, > > > > As Eric has indicated, the OPES WG is considering > transcoding issues! > > However, presently, rather than being > protocol-agnostic, it is being > > designed for HTTP and RTP only. SIP is not being > considered here. > > > > -Srini > > > >> -----Original Message----- > >> From: ext Eric Burger [mailto:eburger@snowshore.com] > >> Subject: RE: [Sipping] RE: [Simple] Multimedia message > >> adaptationInternet-Drafts > >> > >> > >> > >> There are already TWO work groups that are considering > >> EXACTLY these transcoding requirements. > >> > >> They are OPES and LEMONADE. > >> > >> I would offer that discussion of these capabilities happen in > >> those groups. If SIP is the appropriate mechanism, then > >> those groups will submit the appropriate drafts to SIPPING, > >> outlining the requirements. > >> > >>> -----Original Message----- From: > Jose.Costa-Requena@nokia.com > >> [snip] > >>> Nevertheless, "content adaptation" I-D has a wider scope > >>> since it is considering any content-type and it is taking > >>> into account the terminal/user preferences. So I would say > >>> that it fits into SIPPING WG while the filtering I-D is > >>> mainly dealing with presence and I think it should > be handled > >>> at SIMPLE WG. > >>> BR > >>> Jose > >>> > >>> -----Original Message----- From: Coulombe Stephane > (NRC/Dallas) > >>>> At a high level, these drafts also argue that capability > >>>> negotiation should be administered by intermediaries rather > >>> than through an > >>>> end-to-end process; this approach may attract some similar > >>> controversy. > >>> > >>> Proposed capability negotiation can be used both > ways (end-to-end or > >>> administered by intermediaries). > >>> 1) end-to-end: Someone who wants to send an Instant Message > >>> to another user > >>> can send an OPTION query to learn about its terminal > >>> capabilities and > >>> then create a message within its capabilities. > >>> > >>> I guess this is not controversial. However how > >>> realistic and usable is it in practice? > >>> When composing a message, would a user really want to > >>> take into consideration > >>> the image formats to use, message size limitation, etc? > >>> > >>> For instance, you want to send a PNG image to a friend > >>> and his terminal only supports > >>> GIF format. What are you supposed to do? Find an image > >>> conversion tool to convert to GIF? > >>> This is annoying if you are using a PC, imagine with a > >>> mobile phone or handheld? > >>> > >>> For usability reasons, the user wants to send a message > >>> without caring "too much" about > >>> what the other end is supporting. > >>> > >>> 2)administered by intermediaries: this is discussed > in detail > >>> in one of the drafts. > >>> > >>> Performing adaptation in the network is controversial > >>> but this is the only way to support > >>> interoperability and good user experience. > >>> > >>>> the applicability and impact of this mechanism is larger > >>> than the problem of > >>>> instant messaging and presence. While clearly, from the > >>> framework, instant > >>>> messaging and presence cases are driving this work, it is > >>> applicable to the > >>>> general use of SIP events (messaging, I think, is something > >>> of a corner case). > >>> > >>> Yes, applicability and impact is larger than IM and > presence. > >>> It applies to many other > >>> applications including the case of audio/video conferencing > >>> (for instance when there is > >>> no common audio or video codec between two ends). > >>> > >>> The drafts use the "corner case" of SIP IM for a > few reasons: > >>> 1) In SIP IM, there is no concept of capability negotiation > >>> (unlike the case of sessions using SDP). > >>> A user sends a message without knowing anything about > >>> the recipient's terminal capabilities. > >>> 2) In SIP IM, it easier to argue that there will be > >>> interoperability problems because of the variety of content > >>> types that could be sent (in audio/video session codecs are > >>> typically more agreed on). Right now text is mostly used but > >>> richer content will soon be used as is the case in > Multimedia > >>> Messaging Service (MMS). By the way, message adaptation is a > >>> serious issue in MMS because of fast product capability > >>> evolution. It's hard to keep interoperability while not > >>> restricting new phones to send just "low-end" content. > >>> 3) It is easier to explain the problem and propose > a solution > >>> with a smaller well-defined problem. > >>> > >>> Once we agree that SIP message adaptation is required, the > >>> requirements and solutions should be established from global > >>> perspective; not just SIP IM. For that reason, > SIPPING may be > >>> the most appropriate place to initiate this activity. > >>> > >>> Stephane > >>> > >>> -----Original Message----- > >>> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] > >>> Sent: Friday, November 08, 2002 6:58 AM > >>> To: Isomaki Markus (NRC/Helsinki); > dean.willis@softarmor.com; > >>> drage@lucent.com; rohan@cisco.com; > Gonzalo.Camarillo@lmf.ericsson.se > >>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > >>> Subject: RE: [Sipping] RE: [Simple] Multimedia message > >>> adaptationInternet-Drafts > >>> > >>> > >>> > >>> It seems to me that these filtering drafts concern the > >>> modification of MIME > >>> bodies in SIP messages by intermediaries. This is > not exactly an > >>> uncontroversial topic in SIP circles, and therefore I don't > >>> think it is a > >>> foregone conclusion that this is work that some SIP-related > >> WG should > >>> charter. At a high level, these drafts also argue > that capability > >>> negotiation should be administered by intermediaries rather > >>> than through an > >>> end-to-end process; this approach may attract some similar > >>> controversy. > >>> > >>> Provided that this is work the community would like > to pursue, the > >>> applicability and impact of this mechanism is > larger than the > >>> problem of > >>> instant messaging and presence. While clearly, from the > >>> framework, instant > >>> messaging and presence cases are driving this work, it is > >>> applicable to the > >>> general use of SIP events (messaging, I think, is something > >>> of a corner > >>> case). While SIMPLE could certainly spend some time refining > >>> the framework > >>> and requirements related to IM & presence, I imagine that at > >>> a mechanism > >>> stage this work would need to take place in SIPPING. > >>> > >>> Jon Peterson > >>> NeuStar, Inc. > >>> > >>>> -----Original Message----- > >>>> From: Markus.Isomaki@nokia.com > [mailto:Markus.Isomaki@nokia.com] > >>>> Sent: Friday, November 08, 2002 3:47 AM > >>>> To: dean.willis@softarmor.com; drage@lucent.com; > rohan@cisco.com; > >>>> Gonzalo.Camarillo@lmf.ericsson.se > >>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > >>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message > >>>> adaptationInternet-Drafts > >>>> > >>>> > >>>> Hi, > >>>> > >>>> Actually this thread is about two separate things: > >>>> - Event filtering > >>>> - Multimedia message adaptation > >>>> > >>>> Neither of them appears currently on any sippish WG charter > >>>> currently. > >>>> > >>>> Event filtering has been discussed several times and it is > >>>> even mentioned in (but out of scope of) SIP Events RFC. My > >>>> impression has been that people think that it is > needed, but > >>>> there has been debate about scope and feasibility. > I hope the > >>>> requirements draft will help in that discussion. My own > >>>> opinion is that what is concretely needed in short term is > >>>> some simple filtering definitions for Presence > event package. > >>>> More wide-scoped and complex things could be worked upon as > >>>> the understanding accumulates. > >>>> > >>>> Multimedia message adaptation hasn't been yet > discussed much. > >>>> I think it is in general a desirable feature, > especially for > >>>> relatively small and dumb terminals, which are not easily > >>>> upgradable and may not understand all media formats. > >>>> > >>>> So I propose the WG chairs think where these items would be > >>>> appropriate, and if there is enough interest for > them, let's > >>>> put them on the charters. > >>>> > >>>> Markus > >>>> > >>>>> -----Original Message----- > >>>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com] > >>>>> Sent: 08 November, 2002 5:11 > >>>>> To: Drage, Keith (Keith) > >>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com > >>>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message > >>>>> adaptationInternet-Drafts > >>>>> > >>>>> > >>>>> Well, I'd like to hear opinions from the > participants here . . . > >>>>> > >>>>> Clearly they aren't explicitly on the charter for either > >>>>> group. Do we as > >>>>> yet have a consensus that we need to work on these > >>>> problems? If so, we > >>>>> can consider WHERE to work on them. I suspect SIPPING is > >>> closer to a > >>>>> matching scope than is SIMPLE, but the relevant > ADs may have > >>>>> suggestions > >>>>> to make there as well. > >>>>> > >>>>> -- > >>>>> Dean > >>>>> > >>>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote: > >>>>>> I am getting a bit confused as to which group should be > >>>>> discussing these filtering issues. > >>>>>> > >>>>>> Could we have a statement from the WG chairs of > SIPPING or > >>>>> SIMPLE as to whether this, and the moran drafts, > are part of > >>>>> the scope of SIPPING or SIMPLE. > >>>>>> > >>>>>> And before you say these are both author drafts, > I think we > >>>>> do need to charter one of the WGs to do some work in this > >>>>> area - I am just not sure of the exact scope yet. > >>>>>> > >>>>>> Keith > >>>>>> > >>>>>> Keith Drage > >>>>>> Lucent Technologies > >>>>>> Tel: +44 1793 776249 > >>>>>> Email: drage@lucent.com > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > >>>>>>> Sent: 06 November 2002 18:24 > >>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com > >>>>>>> Subject: [Simple] Multimedia message adaptation > >>> Internet-Drafts > >>>>>>> > >>>>>>> > >>>>>>> While these drafts concern event filtering, > >>>> too, the subject was > >>>>>>> a bit misleading because I lazily just followed > >>>> up Tim's e-mail. > >>>>>>> > >>>>>>> Pekka > >>>>>>> > >>>>>>> > >> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > >>>>>>> ptation-framework-00.txt > >>>>>>> > >>>>>>> > >> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada > >>>>>>> ptation-requirements-00.txt > >>>>>>> > >>>>>>> Pekka Pessi writes: > >>>>>>>> We have submitted two drafts regarding > multimedia message > >>>>>>>> adaptation. A multimedia message is typically a message > >>>>>>>> containing images, audio or video clips and their > >>> presentation > >>>>>>>> information, e.g., smil. Also, even > XML-formatted text may > >>>>>>>> require adaptation in some cases. > >>>>>>> > >>>>>>>> Our goal is to have a framework using SIP, HTTP > >> and MIME that > >>>>>>>> allows a person sending multimedia message to adapt > >>> the message > >>>>>>>> contents suitable to all the recipients. In > some cases the > >>>>>>>> adaptation can be done by the sending terminal, but > >>> we also see > >>>>>>>> that an adaptation service would be very useful in > >>> many cases. > >>>>>>>> Such an adaptation mechanism is used by MMS service > >>> provided by > >>>>>>>> cellular networks nowadays. > >>>>>>> > >>>>>>>> The message adaptation work concerns both SIPPING > >> and SIMPLE, > >>>>>>>> the requirements I-D lists use cases and > requirements for > >>>>>>>> multimedia messaging and message adaptation > >> solutions and the > >>>>>>>> framework I-D tries to explore possible solutions. > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> simple mailing list > >>>>>>> simple@mailman.dynamicsoft.com > >>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> Sipping mailing list > >>>> https://www1.ietf.org/mailman/listinfo/sipping > >>>>>> This list is for NEW development of the > application of SIP > >>>>>> Use sip-implementors@cs.columbia.edu for questions on > >>> current sip > >>>>>> Use sip@ietf.org for new developments of core SIP > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>> _______________________________________________ > >>> Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > >>> This list is for NEW development of the application of SIP > >>> Use sip-implementors@cs.columbia.edu for questions > on current sip > >>> Use sip@ietf.org for new developments of core SIP > >>> _______________________________________________ > >>> simple mailing list > >>> simple@mailman.dynamicsoft.com > >>> http://mailman.dynamicsoft.com/mailman/listinfo/simple > >>> _______________________________________________ > >>> Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > >>> This list is for NEW development of the application of SIP > >>> Use sip-implementors@cs.columbia.edu for questions > on current sip > >>> Use sip@ietf.org for new developments of core SIP > >>> > >> _______________________________________________ > >> simple mailing list > >> simple@mailman.dynamicsoft.com > >> http://mailman.dynamicsoft.com/mailman/listinfo/simple > >> > > _______________________________________________ > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on > current sip > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 00:15: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 AAA02998 for ; Mon, 18 Nov 2002 00:15: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 gAI5G55r027423; Mon, 18 Nov 2002 00: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 AAA00197; Mon, 18 Nov 2002 00:17: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 AAA00183 for ; Mon, 18 Nov 2002 00:16:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI5GlYH001969; Mon, 18 Nov 2002 00:16:47 -0500 (EST) Message-ID: <3DD877BC.609@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Comment to draft-olson-simple-publish-01.txt References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD02@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 00:16:44 -0500 Content-Transfer-Encoding: 7bit Well, we are going to discuss in person tomorrow, but may as well do this on the list too. inline. mikko.lonnfors@nokia.com wrote: > Hi, > > Thanks for the new version. Here are some concerns/comments: > > - Sections 1.1.5 and 3.4: Facet header I am bit confused how this is > indented to work. If each PUA always publishes full state then how is > it really possible to use facet header to indicate to which watcher > instances published information is targeted to? As it is currently > defined one PUA could only publish all its information to one or > multiple facets i.e. it is not possible to give some part of that > info so some facets and some other parts to other facet. In current > case it is all or nothing. I would see that better approach would be > to include this kind of information into published content and to > authorization rules but not to publish protocol itself. Also it is > completely unspecified what should happen if PA does not support the > requested facet. Should it report an error or should there be some > default behavior. Building interoperable system in my mind requires > that these procedures are defined. It is actually my preference that we remove the Facet header entirely. I would like to keep separate the problems of publication from the policy mechanisms described in draft-ietf-simple-data-req. Those mechanisms allow a user to specify rules about what information various subscribers should receive. This overlaps with what the Facet header is providing, by allowing that information to be provided at publication time. Rather that having two ways of doing the same thing, we should pick one. I'd prefer to keep this within the policy mechanism since policy is much broader. The policy mechanisms will allow me to specify who sees which documents, but also WHEN they will see them, whether they will be encrypted, and so on. None of that is possible through the Facet mechanism. So, I'd prefer to use a single broader mechanism. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 00:27:27 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 AAA03167 for ; Mon, 18 Nov 2002 00:27:27 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gAI5S15r027526; Mon, 18 Nov 2002 00:28: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 AAA00284; Mon, 18 Nov 2002 00:29: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 AAA00273 for ; Mon, 18 Nov 2002 00:28:14 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI5SFYH001976; Mon, 18 Nov 2002 00:28:15 -0500 (EST) Message-ID: <3DD87A6C.5030204@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Sean Olson , Simple Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt References: <20021028170024.84188.qmail@web20709.mail.yahoo.com> <3DBD8D49.AABAE379@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 00:28:12 -0500 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > Sean Olson wrote: > >> The analogy breaks down in situations that need more persistence of >> the stream identifier. If Call-ID where to persist across all >> requests, across reboots, and potentially across devices, then it >> would be a perfect fit :) > > > Hmm. If that analogy doesn't hold then it would be helpful to have a > more complete description of the semantics of a stream. I guess the > discussion of section 1.1.4 Publisher Instance is intended to provide > this. But it doesn't line up especially well with the definition of > Stream in 3.3. Section 3.3 focuses on providing a context within > which to process messages in order, while 1.1.4 focuses on distinct > publishing instances. From your comments, you suggest that a distinct > instance might not always reside on the same device. Yes. I think the idea is that you might want to, from one device, change the state published originally from another. Example would be, you left your work PC on, set your status to "working", and when you get home, want to change it to "out of the office", but from a different device. I admit this is going to get complicated with soft-state refreshes, since the work PC will presumably continue to refresh the "working" status, resulting in an oscillation of the presence state. Thats clearly not what you want. I suppose a better solution would be for the home PC to publish as a separate stream, but publish using the same tuple ID that is being used by the work PC. The compositor would them somehow know to select the tuple from the home PC as higher priority. In that case, the stream identifier really is playing the same role as the call-id in register, or a dialog ID. So, it seems we have a few options here: * use a new header, as in the current doc * use register-like semantics * have PUBLISH establish a dialog The current doc dismisses the idea of dialog establishment. But, since publications are soft-state, and if you assume a stream is always tied to a particular source, a dialog may make a lot of sense. I always regretted the "special case" behavior that REGISTER has, and would prefer not to propagate it... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 00:32: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 AAA03277 for ; Mon, 18 Nov 2002 00:32: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 gAI5X25r027592; Mon, 18 Nov 2002 00:33: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 AAA00327; Mon, 18 Nov 2002 00:34: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 AAA00316 for ; Mon, 18 Nov 2002 00:33:02 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI5X3YH001979; Mon, 18 Nov 2002 00:33:03 -0500 (EST) Message-ID: <3DD87B8C.3080104@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] A omment to draft-olson-simple-publish-01 References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194504F@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 00:33:00 -0500 Content-Transfer-Encoding: 7bit inline. aki.niemi@nokia.com wrote: > Hi, > > Thanks for the much improved -01. One comment though: > > Although the draft says that 489 (Bad Event) should be sent in case > the composer doesn't understand the published event state, there is > no mention of Allow-Events used in that case. Allow-Events is > mandatory in 489 according to RFC 3265. If it is also mandatory for > 489 to a PUBLISH, it would seem logical that it is also (optionally) > used with OPTIONS (for one). Would then Allow-Events in a 2xx to > OPTIONS indicate support for SUBSCRIBE/NOTIFY, or PUBLISH, or both? Neither. The Allow header indicates whether SUB/NOT and/or PUBLISH are supported. Allow-Events indicates the event packages supported. It may be that a UA doesn't permit outside elements to PUBLISH for a specific event package it supports, but thats really a policy issue, not an issue of whether some package or method is implemented. > > Why not a new pair of headers, which share the event-type (for > packages) namespace with Event/Allow-Events, something like what's > described in > > http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framew- > ork-00.txt > > AFAIK, we are not running out of space with header names ;) No. However, I really don't see the need for defining another entire package concept for publications. I would propose that any "publication" not tied to events (such as uploading a CPL) is probably not going to have the same requirements that event publication has, and probably is a better fit for the data manipulations being discussed in the data requirements document and Markus's semantics draft. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 00:46: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 AAA03483 for ; Mon, 18 Nov 2002 00:46:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gAI5l15r027679; Mon, 18 Nov 2002 00:47: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 AAA00421; Mon, 18 Nov 2002 00: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 AAA00410 for ; Mon, 18 Nov 2002 00:47:43 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI5lfYH001995; Mon, 18 Nov 2002 00:47:41 -0500 (EST) Message-ID: <3DD87EFA.5080400@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'George Foti (LMC)'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] collection template References: <9BF66EBF6BEFD942915B4D4D45C051F3A642B2@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 00:47:38 -0500 Content-Transfer-Encoding: 7bit inline. Adam Roach wrote: >>-----Original Message----- >>From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] >> >>is it correct >>to assume that either of the following is correct: >> >>a) The RLS will send *individual* SUBSCRIBE to all members of >>all sub-lists >>included in the main resource list created by the user when >>he SUBSCRIBEs to >>that list. > > > That would be valid. Of course, the RLS has to know the membership > of all of the sublists to do so. > > >>b) The RLS can do procedure (a) for 1 or more sub-lists (in >>the original >>list) but can also send a SUBSCRIBE to another RLS for some >>sub-lists (in >>the original list). The later RLS can be responsbile for >>maintaining some >>lists, and in turn will implement procedure (a). > > > That would also be valid. The only revision I would make to your > assertion is: "can do procedure (a) for _zero_ or more sublists..." There is a caveat though. When I subscribe to foo.list, this means that every element in the list has to be of the foo event package. The assumption of the template is that each element of the list is of the package the template is applied to. But, that breaks apart when you have a list that contains elements from different packages. For example, you can't have this: sip:mylist@example.com -> sip:joe@example.com [presence package] sip:myworkcolleagues@example.com [presence.list package] What event header value would you use for a SUBSCRIBE to mylist@example.com? Its not presence.list OR presence.list.list. The template approach, right now, requires that IF you have a list that points to other lists, the depth of the resulting tree has to be the same for each leaf. Practically speaking, that is unrealizable, since lists might reside in different domains, and you can't control their depth. So, IMHO, the current mechanism, for all intents and purposes, rules out recursive lists. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 00:56: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 AAA03602 for ; Mon, 18 Nov 2002 00:56: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 gAI5v25r027758; Mon, 18 Nov 2002 00:57: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 AAA00484; Mon, 18 Nov 2002 00:58: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 AAA00473 for ; Mon, 18 Nov 2002 00:57:29 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI5vUYH002002; Mon, 18 Nov 2002 00:57:31 -0500 (EST) Message-ID: <3DD88148.7040107@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] FW: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 00:57:28 -0500 Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > Hi, > > I would be happy with a more generalized solution than what is being > discussed in my draft. I think SIMPLE data manipulation and > conference policy control protocol should be solved within the same > framework. Using XML schemas for manipulated objects (such as lists) > and using XPath etc. to implement generic manipulation operations > would be a good candidate. Actually, I think XPath might be a good > solution to presence event filtering as well. > > The question now is how to go forward. I wrote the list manipulation > 'semantics' draft, because people were saying that it is not possible > to pick a particular solution, such as XML or SOAP, straight away. > Maybe we should first make even some higher level decisions, such as > whether to follow PROTOCOL OPTION 1, 2 or 3 from Jonathan's mail. I think thats a good idea. I don't think we really need to go through a formal process of defining a semantics spec, and then choosing a protocol. If we can get general agreement on an approach, I think the protocol itself falls out of that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 01:01: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 BAA03739 for ; Mon, 18 Nov 2002 01:01: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 gAI6225r027820; Mon, 18 Nov 2002 01:02: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 BAA00527; Mon, 18 Nov 2002 01:03: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 BAA00516 for ; Mon, 18 Nov 2002 01:02:22 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI62OYH002011; Mon, 18 Nov 2002 01:02:24 -0500 (EST) Message-ID: <3DD8826D.5050203@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] 3GPP Messaging requirements References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD07D@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 01:02:21 -0500 Content-Transfer-Encoding: 7bit inline. aki.niemi@nokia.com wrote: > >>> It MUST be possible to divert or block instant messages as part >>> of a user configurable option. Such mechanisms MUST support >>> instant message diversion based on sender address, message size, >>> message priority, message subject, message class and message >> >> content type. >> >> what is message class? > > > The 3GPP documents define message class as being e.g., advertisement, > announcement, personal, and so on. Frankly I had trouble with this as > well, since message class is obviously not available currently in > SIP, so I was doubtful as to whether this is actually a protocol > issue at all. There may actually be a hidden requirement here, > something like: > > There MUST be a mechanism available by which the sender of an instant > message can set a specific class for the message. Possible classes > could be 'advertisement', for commercial messages, and 'personal' for > messages intended for personal consumption. > > Either this, or the message diversion could also depend on an > implementation specific mechanism for grouping messages to classes. > > (I'm well aware of the futility of the message class type mechanisms, > and I'm not expecting spammers to actually mark their messages as > spam...) Thats the problem exactly. The Priority header does exist, and plays a similar role. But, like class, you can't do much with it beyond rendering to the user. Another problem with class is determining the enumerated set of what classes there can be... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 01:07: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 BAA03863 for ; Mon, 18 Nov 2002 01:07: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 gAI6835r027888; Mon, 18 Nov 2002 01: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 BAA00578; Mon, 18 Nov 2002 01:09: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 BAA00567 for ; Mon, 18 Nov 2002 01:08:45 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI68lYH002017; Mon, 18 Nov 2002 01:08:47 -0500 (EST) Message-ID: <3DD883EC.3070101@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: mikko.lonnfors@nokia.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD19@esebe004.ntc.nokia.com> <3DD5D8ED.7070704@dynamicsoft.com> <3DD66CBC.A986100@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 01:08:44 -0500 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > >> 1. Assuming the watcher "picks" one of the contact addresses, and >> decides to communicate with it by sending it an INVITE, how should >> that INVITE look? If the URI in the contact element is the AOR of >> the user, does the watcher need to add caller preferences >> (Require-Contact) in order to reach that specific UA instance? > > > My assumption has been that if the watcher picks one of the contact > addresses, he then just sends the invite to it. It is up to the > publisher of presence to arrange things so that does the right thing. Agreed. > The publisher can identify separate tuples each with a particular set > of capabilities, and yet provide a single AOR for all of them. In > that case it is in effect promising to provide a smart proxy at the > AOR that can do the right thing. Well, that won't work. How would the proxy know which tuple was intended? The only way it can know is if the caller had placed caller preferences in the request. That was my point - how would the caller know it needs to do that? I suppose the right answer is to construct the tuple URI like this: sip:aor@domain?Require-Contact= that is, you don't rely on the subscriber to insert the caller prefs. The PA does that itself by embedding them in the URI. > > Or the publisher can provide an actual individual contact address for > each tuple. In that case it is promising that the contact addresses > are usable by presence subscribers. This is another instance of what I've been calling the "globally routable UA instance problem" - how to construct a SIP URI that routes to a specific UA instance when used outside of any existing dialog. > > In the end, the publisher is in the driver's seat, and publishing > what it willing to expose and what it thinks will be useful to > subscribers. There clearly is a tradeoff between those two things, > and the publisher is the one that ought to decide. > > Whether the subscriber should put callerprefs on the invite is a good > question. If the algorithm the subscriber uses to choose between the > contacts can be represented by callerprefs then it probably wouldn't > hurt and might help. This needs further discussion. I think the semantic needs to be simple. The caller invokes the URI in the presence document, period. The server guarnatees that that results in a request being routed to a UA described by the information in the presence document. Thats the contact. > >> 2. One of the things I am not particularly fond of in the current >> caller prefs spec is the limitation on the capabilities predicate >> (conjunctive normal form only). That restriction exists because of >> the syntactic limitations of using contact parameters, and of the >> need for a simple matching algorithm in proxies to support routing. >> I would like to leave the door open for much more complex >> capabilities documents, which can be uploaded by a UA and used for >> other things, NOT call routing necessarily. Here is a good example >> of a use case that does not need to suffer the limitations of >> caller prefs. It would be nice if we can be more general. > > > Yes!!! Thanks for mentioning this. I was waiting for this to get out > for general discussion before bringing it up. I would welcome > suggestions for enhancements to the requirements. > > >> w3c has done a lot of work in describing capabilities (CC/PP, RDF), >> all of which is XML-based. I wonder if there is a better fit here >> to use that kind of syntax? > > > Could be. That seems to be the common answer here... someone needs to do a detailed study and see how it fits. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 08:19: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 IAA20241 for ; Mon, 18 Nov 2002 08:19: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 gAIDK9Zu000745; Mon, 18 Nov 2002 08:20: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 IAA00993; Mon, 18 Nov 2002 08:21:07 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00982 for ; Mon, 18 Nov 2002 08:20:44 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAIDLSB22068 for ; Mon, 18 Nov 2002 15:21:32 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 18 Nov 2002 15:19:19 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 15:19:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] A comment to draft-olson-simple-publish-01 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD080@esebe013.ntc.nokia.com> Thread-Topic: [Simple] A omment to draft-olson-simple-publish-01 Thread-Index: AcKOw/e8yBv0aP1BTielqm2PecoTQwABKgcw To: Cc: X-OriginalArrivalTime: 18 Nov 2002 13:19:19.0135 (UTC) FILETIME=[19DD7EF0:01C28F05] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA00982 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 Nov 2002 15:19:17 +0200 Content-Transfer-Encoding: 8bit Hi, Comments inline. [...] > > Although the draft says that 489 (Bad Event) should be sent in case > > the composer doesn't understand the published event state, there is > > no mention of Allow-Events used in that case. Allow-Events is > > mandatory in 489 according to RFC 3265. If it is also mandatory for > > 489 to a PUBLISH, it would seem logical that it is also > (optionally) > > used with OPTIONS (for one). Would then Allow-Events in a 2xx to > > OPTIONS indicate support for SUBSCRIBE/NOTIFY, or PUBLISH, or both? > > Neither. The Allow header indicates whether SUB/NOT and/or > PUBLISH are > supported. Allow-Events indicates the event packages > supported. It may > be that a UA doesn't permit outside elements to PUBLISH for a > specific > event package it supports, but thats really a policy issue, > not an issue > of whether some package or method is implemented. Well, the way RFC3265 reads to me suggests that Allow-Events indicates exactly that the node can process the SUBSCRIBEs and NOTIFYs for that particular event package. For clarity's sake I think we need a similar capability specifically for PUBLISH. I agree that the authorization policy for a PUBLISH is not in any way related to the contents of Allow-Events, and may in fact be quite similar to an auth policy for a SUBSCRIBE. We might even consider that some sort of publish-winfo could be reused for reactive authorization of publications. However, this somehow suggests that publish be its own framework, and not an additional part of the events framework. > > Why not a new pair of headers, which share the event-type (for > > packages) namespace with Event/Allow-Events, something like what's > > described in > > > > http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framew- > ork-00.txt > > AFAIK, we are not running out of space with header names ;) > > No. However, I really don't see the need for defining another entire > package concept for publications. I would propose that any "publication" > not tied to events (such as uploading a CPL) is probably not going to > have the same requirements that event publication has, and probably is a > better fit for the data manipulations being discussed in the data > requirements document and Markus's semantics draft. I agree that CPL uploads fall well out of the scope. And I also agree that there isn't maybe a huge need for an entire package system. Having a package would be useful if/when we start defining things like default expiration of state for a particular package, publish payloads that are distinct from NOTIFY bodies, etc. But again, this isn't real concrete yet, nor is it a big issue for me if there isn't a package concept, but things are left for composer policy. Either way works. But there are many degrees to what I'm proposing, and I'll try to bring this into the discussion in the SIMPLE session today. Cheers, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 09:14: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 JAA21451 for ; Mon, 18 Nov 2002 09:14: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 gAIEF2Zu000931; Mon, 18 Nov 2002 09:15: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 JAA01173; Mon, 18 Nov 2002 09:16:05 -0500 (EST) Received: from hotmail.com (f156.sea1.hotmail.com [207.68.163.156]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27912 for ; Sun, 17 Nov 2002 11:52:59 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 17 Nov 2002 08:52:57 -0800 Received: from 212.143.185.30 by sea1fd.sea1.hotmail.msn.com with HTTP; Sun, 17 Nov 2002 16:52:57 GMT X-Originating-IP: [212.143.185.30] From: "Leonardo Rico" To: sip@ietf.org, simple@mailman.dynamicsoft.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Nov 2002 16:52:57.0933 (UTC) FILETIME=[C80D17D0:01C28E59] Subject: [Simple] Presence with PIDF 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: Sun, 17 Nov 2002 11:52:57 -0500 Hi, I’m looking for a UA presence application that supports PIDF format. Preferable an open source or demo I can download. Any idea? Thanks, Leonardo _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 09:15: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 JAA21495 for ; Mon, 18 Nov 2002 09:15: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 gAIEGiZu000978; Mon, 18 Nov 2002 09:16:44 -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 JAA01203; Mon, 18 Nov 2002 09:17:49 -0500 (EST) Received: from hindon.hss.co.in ([202.54.26.202]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00227 for ; Mon, 18 Nov 2002 00:19:14 -0500 (EST) From: akkasam@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAI5Iar20345 for ; Mon, 18 Nov 2002 10:48:36 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAI5IY820331; Mon, 18 Nov 2002 10:48:34 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gAI5KDq27892; Mon, 18 Nov 2002 10:50:13 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C75.001CA518 ; Mon, 18 Nov 2002 10:42:52 +0530 X-Lotus-FromDomain: HSSBLR@HSS To: "Leonardo Rico" cc: sip@ietf.org, simple@mailman.dynamicsoft.com Message-ID: <65256C75.001CA483.00@sandesh.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Simple] Regarding SIPS 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 Nov 2002 10:46:03 +0530 Hi According to the RFC 3261, If the Request-URI contains a SIPS URI, or the topmost Route header field value (after the post processing of bullet 6) contains a SIPS URI, the URI placed into the Record-Route header field MUST be a SIPS URI. Furthermore, if the request was not received over TLS, the proxy MUST insert a Record-Route header field How can this scencario occur. how can it happen that request uri ( or top most route header) is sips and request receiving on other than TLS. Thanks in advance With Regds Ajay Kumar Kasam _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 09:17: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 JAA21533 for ; Mon, 18 Nov 2002 09:17:16 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gAIEIEZu001053; Mon, 18 Nov 2002 09:18: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 JAA01238; Mon, 18 Nov 2002 09:19:18 -0500 (EST) Received: from hindon.hss.co.in ([202.54.26.202]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00360 for ; Mon, 18 Nov 2002 00:38:59 -0500 (EST) From: akkasam@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAI5cKr24534 for ; Mon, 18 Nov 2002 11:08:20 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAI5cJ824527; Mon, 18 Nov 2002 11:08:20 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gAI5dwu00046; Mon, 18 Nov 2002 11:09:58 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C75.001E73B2 ; Mon, 18 Nov 2002 11:02:36 +0530 X-Lotus-FromDomain: HSSBLR@HSS To: akkasam@hss.hns.com cc: "Leonardo Rico" , sip@ietf.org, simple@mailman.dynamicsoft.com Message-ID: <65256C75.001E6FD5.00@sandesh.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Simple] Re: [Sip] Regarding SIPS 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 Nov 2002 11:05:38 +0530 Hi Here is one scenario where we can expect this to occur. Supposed sip: atlanta.com , sips: bilboxi.com be pre-configured route-set at ClientA and let sip:clientb@bilboxi.com be the request uri. Now when the request reaches atlanta.com, after processing route header, the top most route header will be sips, but is received the request on other than TLS. but why doubt is why it is MUST for atlanta.com to record-route. waiting for ur response. thanks in advance ajay kumar kasam _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 12:36:14 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 MAA27426 for ; Mon, 18 Nov 2002 12:36: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 gAIHb7Zu002014; Mon, 18 Nov 2002 12:37: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 MAA02092; Mon, 18 Nov 2002 12:38:08 -0500 (EST) Received: from atpop.smtp.stsn.com (p105.n-atpop03.stsn.com [12.129.82.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02081 for ; Mon, 18 Nov 2002 12:37:06 -0500 (EST) Received: from cisco.com ([10.0.174.235]) by atpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 18 Nov 2002 12:36:17 -0500 Message-ID: <3DD92541.D01F8E1B@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: mikko.lonnfors@nokia.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD19@esebe004.ntc.nokia.com> <3DD5D8ED.7070704@dynamicsoft.com> <3DD66CBC.A986100@cisco.com> <3DD883EC.3070101@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2002 17:36:17.0843 (UTC) FILETIME=[0021A030:01C28F29] 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 Nov 2002 12:37:05 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > >> 1. Assuming the watcher "picks" one of the contact addresses, and > >> decides to communicate with it by sending it an INVITE, how should > >> that INVITE look? If the URI in the contact element is the AOR of > >> the user, does the watcher need to add caller preferences > >> (Require-Contact) in order to reach that specific UA instance? > > > > The publisher can identify separate tuples each with a particular set > > of capabilities, and yet provide a single AOR for all of them. In > > that case it is in effect promising to provide a smart proxy at the > > AOR that can do the right thing. > > Well, that won't work. How would the proxy know which tuple was > intended? The only way it can know is if the caller had placed caller > preferences in the request. That was my point - how would the caller > know it needs to do that? > > I suppose the right answer is to construct the tuple URI like this: > > sip:aor@domain?Require-Contact= > > that is, you don't rely on the subscriber to insert the caller prefs. > The PA does that itself by embedding them in the URI. I think this is a matter of semantics. If I, as publisher, say there are two tuples with different attributes, but associate them both with the same AOR, it might mean that I have two devices registered at the same AOR with differing attributes but don't choose to identify their addresses; or it might mean that I have a single device with two different and interesting sets of attributes I choose to advertise. The subscriber doesn't know and shouldn't care, as long as it reaches a device with the proper capabilities. Having a proxy for the AOR simply fork the request may be sufficient if there are two devices and the characteristics that differentiate them can always be discerned from the initial request. This isn't going to be the case very often, but since the publisher is in the driver seat it should be his problem to decide this. Nevertheless, I agree that in general it would be best for the presence publisher to do as you suggest and embed the callerprefs headers in the contact address. Toward that end, I think we had better specify somewhere that contact addresses in presence may indeed contain embedded headers, since they aren't universally accepted. > I think the semantic needs to be simple. The caller invokes the URI in > the presence document, period. The server guarnatees that that results > in a request being routed to a UA described by the information in the > presence document. Thats the contact. Yes, this seems to be the best answer. > >> w3c has done a lot of work in describing capabilities (CC/PP, RDF), > >> all of which is XML-based. I wonder if there is a better fit here > >> to use that kind of syntax? > > > > > > Could be. > > That seems to be the common answer here... someone needs to do a > detailed study and see how it fits. I already spoke with Mikko about this. Neither of us are familiar with the W3C work. Will need to figure out who has the time / contacts to do the digging. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 17:03: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 RAA05362 for ; Mon, 18 Nov 2002 17:03: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 gAIM4NZu003158; Mon, 18 Nov 2002 17:04:23 -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 RAA03058; Mon, 18 Nov 2002 17:05:17 -0500 (EST) Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03044 for ; Mon, 18 Nov 2002 17:04:42 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with SMTP id gAIM4h122260 for ; Mon, 18 Nov 2002 16:04:43 -0600 Message-ID: <001c01c28f4e$76d5cf60$80452acc@dynamicsoft.com> From: "Adam Roach" To: 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Simple] Thoughts on list template 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 Nov 2002 16:04:27 -0600 Content-Transfer-Encoding: 7bit After giving some thought to the issues raised in today's meeting, it occurs to me that there may, in fact, be a compromise. I'm throwing the rough description out on the list in hope that, if a flaw exists, one of you will be able to point it out. Basically, it amounts to this: to give the capabilities that several people want (e.g. arbitrary depth lists) without abandoning templates, we could slightly tweak the meaning of the ".list" template. In particular, "foo.list" would refer to any arbitrary nesting of foo objects; e.g., it would cover what is, under the current draft, called any of foo.list, foo.list.list, foo.list.list.list, ad infinitum. I *think* this still works gracefully when you combine it with other templates (e.g. presence.list.winfo.list). It *does* impose more of a processing load on aggregators, but I don't think it's crippling. So, first: does anyone see anything that would prevent this working, from a technical perspective? And, second: does anyone have any philosophical objections to this approach? (I'll admit that I have my own reservations, but I want to find a middle ground) /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 19:12:14 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 TAA08414 for ; Mon, 18 Nov 2002 19:12: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 gAJ0D6Zu003691; Mon, 18 Nov 2002 19:13: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 TAA03439; Mon, 18 Nov 2002 19:14: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 TAA03428 for ; Mon, 18 Nov 2002 19:13:45 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJ0DwIL000697; Mon, 18 Nov 2002 19:14:02 -0500 (EST) Received: from cisco.com (rtp-vpn2-678.cisco.com [10.82.242.166]) by cannon.cisco.com (Mirapoint) with ESMTP id AAV09091; Mon, 18 Nov 2002 19:18:29 -0500 (EST) Message-ID: <3DD9822E.9AA9D9D1@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Thoughts on list template References: <001c01c28f4e$76d5cf60$80452acc@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: Mon, 18 Nov 2002 19:13:34 -0500 Content-Transfer-Encoding: 7bit Adam Roach wrote: > > Basically, it amounts to this: to give the capabilities > that several people want (e.g. arbitrary depth lists) > without abandoning templates, we could slightly tweak > the meaning of the ".list" template. In particular, > "foo.list" would refer to any arbitrary nesting of > foo objects; e.g., it would cover what is, under the > current draft, called any of foo.list, foo.list.list, > foo.list.list.list, ad infinitum. ... > So, first: does anyone see anything that would prevent > this working, from a technical perspective? I too hope something like this works. I think we need to dig into details a bit to figure out if it is going to work. 1) Does this imply that the server serving an instance of foo.list itself issues the subscriptions to all the leaves of the recursive list expansion? Or is it just responsible for delegating those? Or are both approaches valid? (They may have different authentication implications.) The pure template approach clearly implied delegating the responsibility for the leaf subscriptions. 2) Either way, the server for foo.list is now responsible for determining if a particular list entry is an instance of foo, or of foo.list. Do we have any better way to figure this out than trial and error? Is that acceptable? (An alternative might be to explicitly type the entries in a list.) Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 19:37: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 TAA08998 for ; Mon, 18 Nov 2002 19:37: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 gAJ0b3Zu003830; Mon, 18 Nov 2002 19:37: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 TAA03530; Mon, 18 Nov 2002 19:38:05 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03519 for ; Mon, 18 Nov 2002 19:37:50 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJ0ccB01068 for ; Tue, 19 Nov 2002 02:38:38 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Nov 2002 02:35:58 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 02:35:57 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 02:35:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Thoughts on list template Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FDB@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Thoughts on list template Thread-Index: AcKPUF0dDipanlHDSgeLT1ywT4XWgQAEXErg To: , X-OriginalArrivalTime: 19 Nov 2002 00:35:56.0929 (UTC) FILETIME=[A0093F10:01C28F63] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id TAA03519 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 Nov 2002 02:35:56 +0200 Content-Transfer-Encoding: 8bit That's how I thought it worked in the first place, hence my confusion of what the problem was. You have a list of buddies, on of the buddies is a list: adam@dynamicsoft.com jonathan@dynamicsoft.com adamfriends@dynamicsoft.com (I have Adam's list of friends on my buddy list. I can do that, technically) My terminal will send out 3 SUBSCRIBEs, one for each of the above. Does my terminal need to recognise that adamfriends@dynamicsoft.com is a list? This has nothing to do with the problem we have now with the list package. Now, I make a list out of the above and call it mybuddies@nokia.com Instead of my terminal sending out 3 SUBSCRIBEs (one of them to adamfriends@dynamicsoft.com with event: presence), it sends out 1. The question is: should my PLS recognise that adamfriends@dynamicsoft.com is a list? I say no. Its up to dynamicsoft's domain to decide that, somehow. This "somehow" solves both problems above. Regards, Hisham > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Tuesday, November 19, 2002 12:04 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Thoughts on list template > > > After giving some thought to the issues raised in today's > meeting, it occurs to me that there may, in fact, be a > compromise. I'm throwing the rough description out on the > list in hope that, if a flaw exists, one of you will > be able to point it out. > > Basically, it amounts to this: to give the capabilities > that several people want (e.g. arbitrary depth lists) > without abandoning templates, we could slightly tweak > the meaning of the ".list" template. In particular, > "foo.list" would refer to any arbitrary nesting of > foo objects; e.g., it would cover what is, under the > current draft, called any of foo.list, foo.list.list, > foo.list.list.list, ad infinitum. > > I *think* this still works gracefully when you combine > it with other templates (e.g. presence.list.winfo.list). > It *does* impose more of a processing load on aggregators, > but I don't think it's crippling. > > So, first: does anyone see anything that would prevent > this working, from a technical perspective? > > And, second: does anyone have any philosophical objections > to this approach? (I'll admit that I have my own reservations, > but I want to find a middle ground) > > /a > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 22:28: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 WAA13283 for ; Mon, 18 Nov 2002 22:28: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 gAJ3TSZu004330; Mon, 18 Nov 2002 22:29:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04080; Mon, 18 Nov 2002 22:29:05 -0500 (EST) Received: from mta0 ([61.144.161.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04069 for ; Mon, 18 Nov 2002 22:28:39 -0500 (EST) Received: from D70286 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H5T00EVD08UL9@mta0.huawei.com> for simple@mailman.dynamicsoft.com; Tue, 19 Nov 2002 11:26:55 +0800 (CST) From: Deepankar To: simple@mailman.dynamicsoft.com Message-id: <008501c28f7b$b4213620$ac064d0a@D70286> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_PLf9RPSIZqp226W79pWLLg)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Simple] PAM and SIMPLE 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 Nov 2002 11:28:18 +0800 This is a multi-part message in MIME format. --Boundary_(ID_PLf9RPSIZqp226W79pWLLg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Sorry to barge in... but could anybody redirect me to a mailing list for discussion on SIMPLE and PAM API mapping. /deeps --Boundary_(ID_PLf9RPSIZqp226W79pWLLg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Sorry to barge in... but could anybody redirect me to a mailing list for discussion on SIMPLE and PAM API mapping.
 
/deeps
--Boundary_(ID_PLf9RPSIZqp226W79pWLLg)-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 18 23:41: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 XAA15113 for ; Mon, 18 Nov 2002 23:41: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 gAJ4e6Zu004574; Mon, 18 Nov 2002 23:40: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 XAA04323; Mon, 18 Nov 2002 23: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 XAA04312 for ; Mon, 18 Nov 2002 23:40:59 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJ4f2YH002975; Mon, 18 Nov 2002 23:41:03 -0500 (EST) Message-ID: <3DD9C0DE.1050008@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Adam Roach , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Thoughts on list template References: <001c01c28f4e$76d5cf60$80452acc@dynamicsoft.com> <3DD9822E.9AA9D9D1@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 23:41:02 -0500 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > Adam Roach wrote: > >> Basically, it amounts to this: to give the capabilities that >> several people want (e.g. arbitrary depth lists) without abandoning >> templates, we could slightly tweak the meaning of the ".list" >> template. In particular, "foo.list" would refer to any arbitrary >> nesting of foo objects; e.g., it would cover what is, under the >> current draft, called any of foo.list, foo.list.list, >> foo.list.list.list, ad infinitum. > > ... > >> So, first: does anyone see anything that would prevent this >> working, from a technical perspective? > > > I too hope something like this works. I think we need to dig into > details a bit to figure out if it is going to work. > > 1) Does this imply that the server serving an instance of foo.list > itself issues the subscriptions to all the leaves of the recursive > list expansion? Or is it just responsible for delegating those? Or > are both approaches valid? (They may have different authentication > implications.) The pure template approach clearly implied delegating > the responsibility for the leaf subscriptions. I don't see the difference between the two things? > > 2) Either way, the server for foo.list is now responsible for > determining if a particular list entry is an instance of foo, or of > foo.list. Do we have any better way to figure this out than trial and > error? Is that acceptable? (An alternative might be to explicitly > type the entries in a list.) This is the big issue. It might help to step back and consider how this would work in an IDEAL world of a clean slate, and work backwards. Doing that is what helped us figure out how to do loose routing, and as it turns out, I think it solves this problem too. In the ideal world, there is no presence package. There is only the equivalent of "presence.list". That is, we assume at the outset that a presence subscription always implies a list, and a valid option is a list of one. Thus, I subscribe to my buddylist with package "presence", and each of the subscriptions it generates are for the same package, "presence". The owner of the URI gets to decide whether its a list of multiple elements, or just one. Now, the problem of course is that all of the list features would need to be replicated in each package. So, the ideal solution there IMHO would have been to have list processing be central to rfc3265 in the first place, so that all packages are list enabled from the outset. OK, so IF you agree that this is what it ought to have been, how do we achieve as close a goal as possible with the constraints that we have? I would define list processing as an EXTENSION to rfc3265, not a template or a new package. How would that work? When a UAC subscribes, it includes a Supported header indicated "lists". The Allow header in the subscribe also lists multipart as a valid body type thats supported, along with the MIME type of this XML list meta-data. So, a buddy list subscription looks like: SUBSCRIBE sip:mylist@domain.com SIP/2.0 Supported: lists Allow: application/pidf+xml, multipart/mixed, application/elist+xml Event: presence The server knows that mylist is a list, but since the client supports lists, its OK. The server does a SUBSCRIBE to each participant in the list, all of them with the Event: presence header, and all of them with the same Supported and Allow headers. Now, should one of those happen to be a regular presence server that doesn't support the "lists" extension, it works just fine! The server will generate NOTIFYs with plain-old PIDF, no multipart or elist+xml. So, there is no trial-and-error; a subscription to an element in the list is the same in all cases, and doesn't require knowing what it is. If it turns out that its a list, multipart comes back. If not, just plain PIDF. Should a user SUBSCRIBE to a list, and not indicate support for "lists" in the Supported header, the server rejects the request with a 420 and the appropriate Require header. As far as I can tell, this solution buys us EVERYTHING we want: * infinite nesting of lists, without the list server needing to know whether an entry is a list or not * no trial and error * backwards compatibility * graceful evolution, if we want, to a revised rfc3265 that includes the list processing as a native capability Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 19 00:23:20 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 AAA15800 for ; Tue, 19 Nov 2002 00:23: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 gAJ5M4Zu004707; Tue, 19 Nov 2002 00:22: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 AAA04500; Tue, 19 Nov 2002 00:23: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 AAA04489 for ; Tue, 19 Nov 2002 00:22:32 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJ5MoiU000418; Tue, 19 Nov 2002 00:22:51 -0500 (EST) Received: from cisco.com (sjc-vpn3-983.cisco.com [10.21.67.215]) by cannon.cisco.com (Mirapoint) with ESMTP id AAV10082; Tue, 19 Nov 2002 00:27:20 -0500 (EST) Message-ID: <3DD9CA91.B5325142@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Adam Roach , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Thoughts on list template References: <001c01c28f4e$76d5cf60$80452acc@dynamicsoft.com> <3DD9822E.9AA9D9D1@cisco.com> <3DD9C0DE.1050008@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 Nov 2002 00:22:25 -0500 Content-Transfer-Encoding: 7bit Jonathan, I was thinking that getting out of this problem required special casing list. It looks like you have come up with a fine way to do it. At first glance this seems to work just fine as far as I can see, though I reserve the right to change my mind. Great idea, Paul Jonathan Rosenberg wrote: > > It might help to step back and consider how this would work in an IDEAL > world of a clean slate, and work backwards. Doing that is what helped us > figure out how to do loose routing, and as it turns out, I think it > solves this problem too. > > In the ideal world, there is no presence package. There is only > the equivalent of "presence.list". That is, we assume at the outset that > a presence subscription always implies a list, and a valid option is a > list of one. Thus, I subscribe to my buddylist with package "presence", > and each of the subscriptions it generates are for the same package, > "presence". The owner of the URI gets to decide whether its a list of > multiple elements, or just one. > > Now, the problem of course is that all of the list features would need > to be replicated in each package. So, the ideal solution there IMHO > would have been to have list processing be central to rfc3265 in the > first place, so that all packages are list enabled from the outset. > > OK, so IF you agree that this is what it ought to have been, how do we > achieve as close a goal as possible with the constraints that we have? > > I would define list processing as an EXTENSION to rfc3265, not a > template or a new package. How would that work? When a UAC subscribes, > it includes a Supported header indicated "lists". The Allow header in > the subscribe also lists multipart as a valid body type thats supported, > along with the MIME type of this XML list meta-data. So, a buddy list > subscription looks like: > > SUBSCRIBE sip:mylist@domain.com SIP/2.0 > Supported: lists > Allow: application/pidf+xml, multipart/mixed, application/elist+xml > Event: presence > > The server knows that mylist is a list, but since the client supports > lists, its OK. The server does a SUBSCRIBE to each participant in the > list, all of them with the Event: presence header, and all of them with > the same Supported and Allow headers. Now, should one of those happen to > be a regular presence server that doesn't support the "lists" extension, > it works just fine! The server will generate NOTIFYs with plain-old > PIDF, no multipart or elist+xml. So, there is no trial-and-error; a > subscription to an element in the list is the same in all cases, and > doesn't require knowing what it is. If it turns out that its a list, > multipart comes back. If not, just plain PIDF. > > Should a user SUBSCRIBE to a list, and not indicate support for "lists" > in the Supported header, the server rejects the request with a 420 and > the appropriate Require header. > > As far as I can tell, this solution buys us EVERYTHING we want: > > * infinite nesting of lists, without the list server needing to know > whether an entry is a list or not > * no trial and error > * backwards compatibility > * graceful evolution, if we want, to a revised rfc3265 that includes the > list processing as a native capability > > Comments? _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 19 11:51: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 LAA09693 for ; Tue, 19 Nov 2002 11:51: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 gAJGqDZu006692; Tue, 19 Nov 2002 11:52: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 LAA06528; Tue, 19 Nov 2002 11:53:08 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06517 for ; Tue, 19 Nov 2002 11:52:03 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJGqoB24217 for ; Tue, 19 Nov 2002 18:52:50 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Nov 2002 18:52:02 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 18:52:02 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Thoughts on list template X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194508F@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Thoughts on list template Thread-Index: AcKPhgGtNVSm6bdoRqKqeOiYh2t4vwAZKu9w To: , Cc: , X-OriginalArrivalTime: 19 Nov 2002 16:52:02.0697 (UTC) FILETIME=[FBF43F90:01C28FEB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA06517 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 Nov 2002 18:52:02 +0200 Content-Transfer-Encoding: 8bit Jonathan, I think this is a good idea. The problem really was that while we were trying to treat lists as part of the event, they really were not. So separating the list handling from the actual event is a good idea, and I think you nailed it here. Cheers, Aki > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, November 19, 2002 6:41 AM > To: Paul Kyzivat > Cc: Adam Roach; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Thoughts on list template > > > inline. > > Paul Kyzivat wrote: > > > > Adam Roach wrote: > > > >> Basically, it amounts to this: to give the capabilities that > >> several people want (e.g. arbitrary depth lists) without > abandoning > >> templates, we could slightly tweak the meaning of the ".list" > >> template. In particular, "foo.list" would refer to any arbitrary > >> nesting of foo objects; e.g., it would cover what is, under the > >> current draft, called any of foo.list, foo.list.list, > >> foo.list.list.list, ad infinitum. > > > > ... > > > >> So, first: does anyone see anything that would prevent this > >> working, from a technical perspective? > > > > > > I too hope something like this works. I think we need to dig into > > details a bit to figure out if it is going to work. > > > > 1) Does this imply that the server serving an instance of foo.list > > itself issues the subscriptions to all the leaves of the recursive > > list expansion? Or is it just responsible for delegating those? Or > > are both approaches valid? (They may have different authentication > > implications.) The pure template approach clearly implied > delegating > > the responsibility for the leaf subscriptions. > > I don't see the difference between the two things? > > > > > 2) Either way, the server for foo.list is now responsible for > > determining if a particular list entry is an instance of foo, or of > > foo.list. Do we have any better way to figure this out > than trial and > > error? Is that acceptable? (An alternative might be to explicitly > > type the entries in a list.) > > This is the big issue. > > It might help to step back and consider how this would work > in an IDEAL > world of a clean slate, and work backwards. Doing that is > what helped us > figure out how to do loose routing, and as it turns out, I think it > solves this problem too. > > In the ideal world, there is no presence package. > There is only > the equivalent of "presence.list". That is, we assume at the > outset that > a presence subscription always implies a list, and a valid > option is a > list of one. Thus, I subscribe to my buddylist with package > "presence", > and each of the subscriptions it generates are for the same package, > "presence". The owner of the URI gets to decide whether its a list of > multiple elements, or just one. > > Now, the problem of course is that all of the list features > would need > to be replicated in each package. So, the ideal solution there IMHO > would have been to have list processing be central to rfc3265 in the > first place, so that all packages are list enabled from the outset. > > OK, so IF you agree that this is what it ought to have been, > how do we > achieve as close a goal as possible with the constraints that we have? > > I would define list processing as an EXTENSION to rfc3265, not a > template or a new package. How would that work? When a UAC > subscribes, > it includes a Supported header indicated "lists". The Allow header in > the subscribe also lists multipart as a valid body type thats > supported, > along with the MIME type of this XML list meta-data. So, a buddy list > subscription looks like: > > SUBSCRIBE sip:mylist@domain.com SIP/2.0 > Supported: lists > Allow: application/pidf+xml, multipart/mixed, application/elist+xml > Event: presence > > The server knows that mylist is a list, but since the client supports > lists, its OK. The server does a SUBSCRIBE to each participant in the > list, all of them with the Event: presence header, and all of > them with > the same Supported and Allow headers. Now, should one of > those happen to > be a regular presence server that doesn't support the "lists" > extension, > it works just fine! The server will generate NOTIFYs with plain-old > PIDF, no multipart or elist+xml. So, there is no trial-and-error; a > subscription to an element in the list is the same in all cases, and > doesn't require knowing what it is. If it turns out that its a list, > multipart comes back. If not, just plain PIDF. > > Should a user SUBSCRIBE to a list, and not indicate support > for "lists" > in the Supported header, the server rejects the request with > a 420 and > the appropriate Require header. > > As far as I can tell, this solution buys us EVERYTHING we want: > > * infinite nesting of lists, without the list server needing to know > whether an entry is a list or not > * no trial and error > * backwards compatibility > * graceful evolution, if we want, to a revised rfc3265 that > includes the > list processing as a native capability > > > Comments? > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 19 14:02:19 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 OAA13284 for ; Tue, 19 Nov 2002 14:02:19 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gAJJ2AZu007342; Tue, 19 Nov 2002 14:02: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 OAA07044; Tue, 19 Nov 2002 14:03:06 -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 OAA07033 for ; Tue, 19 Nov 2002 14:02:58 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJJ2RO24782 for ; Tue, 19 Nov 2002 21:02:27 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Nov 2002 21:02:38 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 21:02:37 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28FFE.394FE73C" Subject: RE: [Simple] PAM and SIMPLE X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD5C@esebe004.ntc.nokia.com> Thread-Topic: [Simple] PAM and SIMPLE Thread-Index: AcKPfHPWt3e+ifGPRJGAQZxmKVKA+QAa6wBg To: , X-OriginalArrivalTime: 19 Nov 2002 19:02:37.0289 (UTC) FILETIME=[39BC1D90:01C28FFE] 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 Nov 2002 21:02:36 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C28FFE.394FE73C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I am not sure what APIs you are referring to but here is one answer. = SIMPLE and PAM APIs are at least being defined within Java Community = Processes (JCP). There are separate items for both SIMPLE API and PAM = API. The work mode in JCP is different compared to IETF and as a result = API design and discussion is limited to expert group members until work = becomes public. You can check status from JCP web site or contact the = expert group lead if you have further questions. =20 simple: http://www.jcp.org/en/jsr/detail?id=3D164 http://www.jcp.org/en/jsr/detail?id=3D165 =20 pam: http://www.jcp.org/en/jsr/detail?id=3D123 =20 BR - Mikko -----Original Message----- From: ext Deepankar [mailto:deepankarb@huawei.com] Sent: 19 November, 2002 05:28 To: simple@mailman.dynamicsoft.com Subject: [Simple] PAM and SIMPLE Sorry to barge in... but could anybody redirect me to a mailing list for = discussion on SIMPLE and PAM API mapping. =20 /deeps ------_=_NextPart_001_01C28FFE.394FE73C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am=20 not sure what APIs you are referring to but here is one answer. SIMPLE = and PAM=20 APIs are at least being defined within Java Community Processes (JCP). = There are=20 separate items for both SIMPLE API and PAM API. The work mode in JCP is=20 different compared to IETF and as a result API design and discussion is = limited=20 to expert group members until work becomes public. You can check = status=20 from JCP web site or contact the expert group lead if you have further=20 questions.
 
simple:
http://www.jcp.org/en/= jsr/detail?id=3D164
http://www.jcp.org/en/= jsr/detail?id=3D165
 
pam:
http://www.jcp.org/en/= jsr/detail?id=3D123
 
BR
-=20 Mikko
-----Original Message-----
From: ext Deepankar=20 [mailto:deepankarb@huawei.com]
Sent: 19 November, 2002=20 05:28
To: simple@mailman.dynamicsoft.com
Subject: = [Simple]=20 PAM and SIMPLE

Sorry to barge in... but could = anybody redirect=20 me to a mailing list for discussion on SIMPLE and PAM API=20 mapping.
 
/deeps
------_=_NextPart_001_01C28FFE.394FE73C-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 19 14:13: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 OAA13651 for ; Tue, 19 Nov 2002 14:13: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 gAJJE4Zu007454; Tue, 19 Nov 2002 14: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 OAA07131; Tue, 19 Nov 2002 14:15:07 -0500 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03137 for ; Mon, 18 Nov 2002 17:28:18 -0500 (EST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11782 for ; Mon, 18 Nov 2002 14:28:18 -0800 (PST) Received: from sydney.East.Sun.COM (esun1es-fe-ge0.Holland.Sun.COM [129.159.36.22]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id gAIMSCJ22168; Mon, 18 Nov 2002 17:28:13 -0500 (EST) From: Steve Hanna Message-Id: <200211182228.gAIMSCJ22168@sydney.East.Sun.COM> To: Cc: Reply-To: X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [Simple] Pointer to standard policy language 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 Nov 2002 17:28:08 -0500 Content-Transfer-Encoding: 7bit In today's SIMPLE WG session, I promised to send a pointer to the work going on elsewhere to define a standard access control policy language. The language I was referring to is XACML (eXtensible Access Control Markup Language). It is an XML-based access control policy language designed to support a wide variety of applications. The spec is currently in the middle of a 30 day Public Review, so this is a great time to read it and send your comments. For more info, see http://www.oasis-open.org/committees/xacml. There are definite advantages to using a standard language for expressing access control policies. Developers can reuse existing code. Users don't need to learn special-purpose languages. Etc. I would recommend that in defining your protocols, you treat an access control policy as a blob, allowing users to set or get them but not defining commands to manipulate the internal contents. This will allow you to use XACML or any successor language or even to define your own language if you should decide at some later time that you want to do so. I do not subscribe to your WG list, so please cc me on subsequent discussions of this topic (unless you explicitly want to exclude me!). Thanks, Steve Hanna _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 19 15:20: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 PAA15484 for ; Tue, 19 Nov 2002 15:20: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 gAJKH8Zu007781; Tue, 19 Nov 2002 15:17: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 PAA07430; Tue, 19 Nov 2002 15:18:07 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07419 for ; Tue, 19 Nov 2002 15:17:47 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJKIZB07632 for ; Tue, 19 Nov 2002 22:18:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Nov 2002 22:17:44 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 22:17:43 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 22:17:42 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD5D@esebe004.ntc.nokia.com> Thread-Topic: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt Thread-Index: AcKPKYU0nDXJxM0rRUCdi28v4yvyjgA2bMPw To: , Cc: X-OriginalArrivalTime: 19 Nov 2002 20:17:42.0933 (UTC) FILETIME=[B74ED450:01C29008] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA07419 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 Nov 2002 22:17:42 +0200 Content-Transfer-Encoding: 8bit Hi inline > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 18 November, 2002 19:37 > To: Jonathan Rosenberg > Cc: Lonnfors Mikko (NRC/Helsinki); simple@mailman.dynamicsoft.com > Subject: Re: [Simple] FW: I-D > ACTION:draft-lonnfors-simple-prescaps-ext-00.txt > > Jonathan Rosenberg wrote: > > > > >> 1. Assuming the watcher "picks" one of the contact > addresses, and > > >> decides to communicate with it by sending it an INVITE, > how should > > >> that INVITE look? If the URI in the contact element is > the AOR of > > >> the user, does the watcher need to add caller preferences > > >> (Require-Contact) in order to reach that specific UA instance? > > > > > > The publisher can identify separate tuples each with a > particular set > > > of capabilities, and yet provide a single AOR for all of them. In > > > that case it is in effect promising to provide a smart > proxy at the > > > AOR that can do the right thing. > > > > Well, that won't work. How would the proxy know which tuple was > > intended? The only way it can know is if the caller had > placed caller > > preferences in the request. That was my point - how would the caller > > know it needs to do that? > > > > I suppose the right answer is to construct the tuple URI like this: > > > > sip:aor@domain?Require-Contact= > > > > that is, you don't rely on the subscriber to insert the > caller prefs. > > The PA does that itself by embedding them in the URI. > > I think this is a matter of semantics. If I, as publisher, > say there are two tuples with different attributes, but > associate them both with the same AOR, it might mean that I > have two devices registered at the same AOR with differing > attributes but don't choose to identify their addresses; or > it might mean that I have a single device with two different > and interesting sets of attributes I choose to advertise. > > The subscriber doesn't know and shouldn't care, as long as it > reaches a device with the proper capabilities. > > Having a proxy for the AOR simply fork the request may be > sufficient if there are two devices and the characteristics > that differentiate them can always be discerned from the > initial request. This isn't going to be the case very often, > but since the publisher is in the driver seat it should be > his problem to decide this. > > Nevertheless, I agree that in general it would be best for > the presence publisher to do as you suggest and embed the > callerprefs headers in the contact address. Toward that end, > I think we had better specify somewhere that contact > addresses in presence may indeed contain embedded headers, > since they aren't universally accepted. This may need bit more consideration. Embedding the caller preferences headers into contact address might make sense in a case where publisher has registered using caller preferences. I can also see use cases where presentity wants to embed feature tags into presence info but chooses not to register those to registrar (I want to show support for voice but I don't want my proxy to act differently). Other side of this problem is that this model seems to require callerprefs support from watcher side. How is the watcher expected to behave if it receives a contact URI with all different callerprefs headers it does not understand? This procedure seems also to duplicate the information in the presence document. It is first presented inside XML structures and then second time in contact URI. This may not be a huge problem but it isn't very nice either. Well, in any case I think Jonathan is right that watcher should have a simple mechanism how to send request to presentity. One option could be that XML structure includes some kind of instructions to watcher how the Request based on presence info should be constructed. This would eliminate the duplication problem and if watcher does not understand callerprefs extension it can just ignore it and behave as callerprefs extension wasn't there in the first place. > > I think the semantic needs to be simple. The caller invokes > the URI in > > the presence document, period. The server guarnatees that > that results > > in a request being routed to a UA described by the > information in the > > presence document. Thats the contact. > > Yes, this seems to be the best answer. > > > >> w3c has done a lot of work in describing capabilities > (CC/PP, RDF), > > >> all of which is XML-based. I wonder if there is a > better fit here > > >> to use that kind of syntax? > > > > > > > > > Could be. > > > > That seems to be the common answer here... someone needs to do a > > detailed study and see how it fits. > > I already spoke with Mikko about this. Neither of us are > familiar with the W3C work. Will need to figure out who has > the time / contacts to do the digging. If nobody else is going to volunteer for this I can spend some time to figure these things out. - Mikko > Paul > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 19 15:33: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 PAA15766 for ; Tue, 19 Nov 2002 15:33: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 gAJKY4Zu007904; Tue, 19 Nov 2002 15:34:04 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07508; Tue, 19 Nov 2002 15:35:06 -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 PAA07495 for ; Tue, 19 Nov 2002 15:34:24 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJKXrO04171 for ; Tue, 19 Nov 2002 22:33:53 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Nov 2002 22:34:24 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 22:34:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Pointer to standard policy language Message-ID: Thread-Topic: [Simple] Pointer to standard policy language Thread-Index: AcKQAA7xWLbcfztWQwm6Eljc78kOgwACIBdA To: , X-OriginalArrivalTime: 19 Nov 2002 20:34:24.0855 (UTC) FILETIME=[0C7FFE70:01C2900B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA07495 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 Nov 2002 22:34:24 +0200 Content-Transfer-Encoding: 8bit Hi Steve, Thanks for the pointer. Before getting deeper into the details, I would like to know a couple of basic points about XACML's applicability in this case. In my opinion the standardized protocols to setup presence policy rules are most valuable for wireless terminals with small displays, since using a web browser aside of SIP client is quite clumsy with them. If we assume the XACML document would be a blob, that the client can just read and replace, would that be feasible over low-bandwidth links (say, <50 kps)? This depends on how big the documents would get, and wheter ALL the information, such as URI lists, would be included in the same blob (document). For instance, if reactive authorization works so that a SIP URI is appended to some list, I don't think it makes sense to send the whole policy doc. to the server. In my opinion the protocol should have some light-weigth procedures to do the most common operations, such as adding and deleting URIs (assuming the authorization model in the requirements draft). Would it still make sense to use XACML, and use some simple XML manipulation operations on it, to achieve this? I'll do some calculations to see whether this will be critical or not in real-life systems. Markus > -----Original Message----- > From: ext Steve Hanna [mailto:Steve.Hanna@sun.com] > Sent: 19 November, 2002 00:28 > To: simple@mailman.dynamicsoft.com > Cc: steve.hanna@sun.com > Subject: [Simple] Pointer to standard policy language > > > In today's SIMPLE WG session, I promised to send a pointer to the > work going on elsewhere to define a standard access control policy > language. > > The language I was referring to is XACML (eXtensible Access Control > Markup Language). It is an XML-based access control policy language > designed to support a wide variety of applications. The spec is > currently in the middle of a 30 day Public Review, so this is a > great time to read it and send your comments. For more info, see > http://www.oasis-open.org/committees/xacml. > > There are definite advantages to using a standard language for > expressing access control policies. Developers can reuse existing > code. Users don't need to learn special-purpose languages. Etc. > > I would recommend that in defining your protocols, you treat an > access control policy as a blob, allowing users to set or get them > but not defining commands to manipulate the internal contents. This > will allow you to use XACML or any successor language or even to > define your own language if you should decide at some later time > that you want to do so. > > I do not subscribe to your WG list, so please cc me on subsequent > discussions of this topic (unless you explicitly want to exclude me!). > > Thanks, > > Steve Hanna > > _______________________________________________ > 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 Nov 19 15:54: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 PAA16322 for ; Tue, 19 Nov 2002 15:54: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 gAJKt4Zu008034; Tue, 19 Nov 2002 15:55: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 PAA07596; Tue, 19 Nov 2002 15:56:06 -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 PAA07585 for ; Tue, 19 Nov 2002 15:55:39 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJKt9O10223 for ; Tue, 19 Nov 2002 22:55:09 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Nov 2002 22:55:40 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 22:55:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: [Simple] Pointer to standard policy language Thread-Index: AcKQAA7xWLbcfztWQwm6Eljc78kOgwACIBdAAADYQiA= To: , , X-OriginalArrivalTime: 19 Nov 2002 20:55:40.0290 (UTC) FILETIME=[04B7EE20:01C2900E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA07585 Subject: [Simple] Data manipulation 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 Nov 2002 22:55:39 +0200 Content-Transfer-Encoding: 8bit Hi, There hasn't been too much interest or comments on the Data Manipulation in SIMPLE, excluding the authors of the drafts. I would like to find out who is really interested in this, and would be even willing to contribute to the drafts. So, could all those people send me e-mail saying: a) I think we should get this standardized, but I don't have time for it right now; or b) I would be willing to help solving the technical problems I also propose that we meet briefly after tomorrow's SIPPING session (15:30-17:30) somewhere around the chairs' desk to see who we are. I'm the one who was presenting the list manipulation semantics draft yesterday. Markus _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 19 16:11: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 QAA16665 for ; Tue, 19 Nov 2002 16:11: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 gAJL83Zu008158; Tue, 19 Nov 2002 16: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 QAA07667; Tue, 19 Nov 2002 16:09:06 -0500 (EST) Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07656 for ; Tue, 19 Nov 2002 16:08:43 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gAJL8i127267 for ; Tue, 19 Nov 2002 15:08:44 -0600 From: Robert Sparks To: simple@mailman.dynamicsoft.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Message-Id: <1037740088.1253.9.camel@RjS.localdomain> Mime-Version: 1.0 Subject: [Simple] Notes and slides 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: 19 Nov 2002 16:08:08 -0500 Content-Transfer-Encoding: 7bit Rough notes and the slides from the IETF55 SIMPLE meeting are available at http://www.softarmor.com/simple/meets/ietf55 Please send corrections to the notes to the list. Send corrections to the slides (or error reports concerning the SIMPLE weblet) directly to me. RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 19 16:52: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 QAA17989 for ; Tue, 19 Nov 2002 16:52: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 gAJLp8Zu008387; Tue, 19 Nov 2002 16:51: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 QAA07832; Tue, 19 Nov 2002 16:52: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 QAA07821 for ; Tue, 19 Nov 2002 16:51:53 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJLqAxQ011588; Tue, 19 Nov 2002 16:52:10 -0500 (EST) Received: from cisco.com (rtp-vpn2-642.cisco.com [10.82.242.130]) by cannon.cisco.com (Mirapoint) with ESMTP id AAV16766; Tue, 19 Nov 2002 16:56:41 -0500 (EST) Message-ID: <3DDAB270.439918E7@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: mikko.lonnfors@nokia.com CC: jdrosen@dynamicsoft.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD5D@esebe004.ntc.nokia.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 Nov 2002 16:51:44 -0500 Content-Transfer-Encoding: 7bit mikko.lonnfors@nokia.com wrote: > > This may need bit more consideration. Embedding the caller preferences headers into contact address might make sense in a case where publisher has registered using caller preferences. I can also see use cases where presentity wants to embed feature tags into presence info but chooses not to register those to registrar (I want to show support for voice but I don't want my proxy to act differently). Certainly the publisher can do this if it wants to. May make sense in some cases. > Other side of this problem is that this model seems to require callerprefs support from watcher side. How is the watcher expected to behave if it receives a contact URI with all different callerprefs headers it does not understand? I don't see this as a problem. As long as watchers understand that the contacts may have embedded headers, and know generically what to do with them. (And 3261 says what to do with them.) The watcher doesn't have to understand or support the headers to insert them in a request. > This procedure seems also to duplicate the information in the presence document. It is first presented inside XML structures and then second time in contact URI. This may not be a huge problem but it isn't very nice either. Yes, it is less than desirable. But it seems to show up in many contexts, such as duplication of headers in sipfrags for security purposes. It may be the lesser of evils. > > Well, in any case I think Jonathan is right that watcher should have a simple mechanism how to send request to presentity. One option could be that XML structure includes some kind of instructions to watcher how the Request based on presence info should be constructed. This would eliminate the duplication problem and if watcher does not understand callerprefs extension it can just ignore it and behave as callerprefs extension wasn't there in the first place. I don't understand this. What form would these "instructions" take? How would they affect the resulting request beyond using the contact address? I don't see what they could achieve that couldn't be achieved by attaching headers to the contact address. > > > >> w3c has done a lot of work in describing capabilities > > (CC/PP, RDF), > > > >> all of which is XML-based. I wonder if there is a > > better fit here > > > >> to use that kind of syntax? ... > > > That seems to be the common answer here... someone needs to do a > > > detailed study and see how it fits. ... > If nobody else is going to volunteer for this I can spend some time to figure these things out. Thanks. I would like to look into this too, but I've got to figure out what is on my plate at home before I commit. I want to suggest a requirement here: We must ensure that this remains semantically a superset of what is used to represent capabilities in registrations. (callerprefs) This could be an important constraint because many mechanisms are likely to have different namespaces and registration rules for capabilities/attributes. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 19 18:48: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 SAA20864 for ; Tue, 19 Nov 2002 18:48: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 gAJNjFZu008811; Tue, 19 Nov 2002 18:45: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 SAA08193; Tue, 19 Nov 2002 18:46:12 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08182 for ; Tue, 19 Nov 2002 18:45:37 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJNkSB20668 for ; Wed, 20 Nov 2002 01:46:28 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 20 Nov 2002 01:45:38 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Nov 2002 01:45:38 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD5F@esebe004.ntc.nokia.com> Thread-Topic: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt Thread-Index: AcKQFeQ+OnMvaetsSz22XadhgoXPewAC+98A To: Cc: , X-OriginalArrivalTime: 19 Nov 2002 23:45:38.0630 (UTC) FILETIME=[C3671E60:01C29025] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id SAA08182 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 Nov 2002 01:45:38 +0200 Content-Transfer-Encoding: 8bit Hi, Inline > mikko.lonnfors@nokia.com wrote: > > > > This may need bit more consideration. Embedding the caller > preferences headers into contact address might make sense in > a case where publisher has registered using caller > preferences. I can also see use cases where presentity wants > to embed feature tags into presence info but chooses not to > register those to registrar (I want to show support for voice > but I don't want my proxy to act differently). > > Certainly the publisher can do this if it wants to. May make > sense in some cases. > > > Other side of this problem is that this model seems to > require callerprefs support from watcher side. How is the > watcher expected to behave if it receives a contact URI with > all different callerprefs headers it does not understand? > > I don't see this as a problem. As long as watchers understand > that the contacts may have embedded headers, and know > generically what to do with them. (And 3261 says what to do > with them.) The watcher doesn't have to understand or support > the headers to insert them in a request. ok, then it should be explained somewhere that contact element URIs can contain embedded headers and how those should be processed. I am not sure is this draft the place to do it but on the other hand I cannot figure out any better place either. > > This procedure seems also to duplicate the information in > the presence document. It is first presented inside XML > structures and then second time in contact URI. This may not > be a huge problem but it isn't very nice either. > > Yes, it is less than desirable. But it seems to show up in > many contexts, such as duplication of headers in sipfrags for > security purposes. It may be the lesser of evils. As I said this may not be such a big problem but my view still is that if this can be avoided it should be avoided. > > > > Well, in any case I think Jonathan is right that watcher > should have a simple mechanism how to send request to > presentity. One option could be that XML structure includes > some kind of instructions to watcher how the Request based on > presence info should be constructed. This would eliminate the > duplication problem and if watcher does not understand > callerprefs extension it can just ignore it and behave as > callerprefs extension wasn't there in the first place. > > I don't understand this. What form would these "instructions" > take? How would they affect the resulting request beyond > using the contact address? I don't see what they could > achieve that couldn't be achieved by attaching headers to the > contact address. I probably wasn't clear enough. I was thinking to desing something like this: .. .. audio sip:user@domain.com The element could have an attribute called 'required' or something similar. When watcher would get this info it would take the contact as Request-URI and then generate Require-Contact based on 'required' attributes. This would solve the duplication problem and also embedded header problem (if it was a problem in the first place). This would put little more responsibility on watcher side as watcher would construct Require-Contact headers based on info found in XML. This was just to show that there might be some alternatives to do this. Hopefully it is now bit clearer. > > > > >> w3c has done a lot of work in describing capabilities > > > (CC/PP, RDF), > > > > >> all of which is XML-based. I wonder if there is a > > > better fit here > > > > >> to use that kind of syntax? > ... > > > > That seems to be the common answer here... someone needs to do a > > > > detailed study and see how it fits. > ... > > If nobody else is going to volunteer for this I can spend > some time to figure these things out. > > Thanks. I would like to look into this too, but I've got to > figure out what is on my plate at home before I commit. > > I want to suggest a requirement here: We must ensure that > this remains semantically a superset of what is used to > represent capabilities in registrations. (callerprefs) This > could be an important constraint because many mechanisms are > likely to have different namespaces and registration rules > for capabilities/attributes. This sounds like a good idea. Could you still elaborate the last sentence a bit. I am not sure I completely got it. - Mikko > Paul > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 19 19:10: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 TAA21323 for ; Tue, 19 Nov 2002 19:10: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 gAK0A2Zu008978; Tue, 19 Nov 2002 19:10: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 TAA08338; Tue, 19 Nov 2002 19:11:05 -0500 (EST) Received: from u-mail.rd.francetelecom.com (u-mail.rd.francetelecom.com [208.25.178.63]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08327 for ; Tue, 19 Nov 2002 19:10:19 -0500 (EST) Received: by U-MAIL with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 16:10:18 -0800 Message-ID: <037E7050631FD611AAFD0002A509146A345E6C@U-MAIL2> From: GOPALAKRISHNAN Arun / FTR&D US To: "'Deepankar'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] PAM and SIMPLE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29029.81D9F900" 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 Nov 2002 16:12:26 -0800 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_01C29029.81D9F900 Content-Type: text/plain; charset="iso-8859-1" You may want to check with PAM forum. Apparently there's some activity on PAM/SIMPLE mapping. -----Original Message----- From: Deepankar [mailto:deepankarb@huawei.com] Sent: Monday, November 18, 2002 7:32 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] PAM and SIMPLE Sorry to barge in... but could anybody redirect me to a mailing list for discussion on SIMPLE and PAM API mapping. /deeps ------_=_NextPart_001_01C29029.81D9F900 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] PAM and SIMPLE

You may want to check with PAM forum. Apparently there's some activity on PAM/SIMPLE mapping.



-----Original Message-----
From: Deepankar [mailto:deepankarb@huawei.com]
Sent: Monday, November 18, 2002 7:32 PM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] PAM and SIMPLE


Sorry to barge in... but could anybody redirect me to a mailing list for discussion on SIMPLE and PAM API mapping.

/deeps

------_=_NextPart_001_01C29029.81D9F900-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 19 22:11:14 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 WAA02052 for ; Tue, 19 Nov 2002 22:11:14 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gAK3C5Zu010190; Tue, 19 Nov 2002 22: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 WAA08921; Tue, 19 Nov 2002 22:13: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 WAA08910 for ; Tue, 19 Nov 2002 22:12:01 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAK3CDFT009804; Tue, 19 Nov 2002 22:12:18 -0500 (EST) Received: from cisco.com (rtp-vpn2-694.cisco.com [10.82.242.182]) by cannon.cisco.com (Mirapoint) with ESMTP id AAV18411; Tue, 19 Nov 2002 22:16:36 -0500 (EST) Message-ID: <3DDAD58C.32881310@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: mikko.lonnfors@nokia.com CC: jdrosen@dynamicsoft.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD5F@esebe004.ntc.nokia.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 Nov 2002 19:21:32 -0500 Content-Transfer-Encoding: 7bit mikko.lonnfors@nokia.com wrote: > > > I want to suggest a requirement here: We must ensure that > > this remains semantically a superset of what is used to > > represent capabilities in registrations. (callerprefs) This > > could be an important constraint because many mechanisms are > > likely to have different namespaces and registration rules > > for capabilities/attributes. > > This sounds like a good idea. Could you still elaborate the last sentence a bit. I am not sure I completely got it. In draft-kyzivat-simple-prescaps-reqts-00 I reference the need to represent any feature tag. The feature tags used in callerprefs are defined by reference in rfc 2506. It defines the syntax of feature tags, a partitioning into different namespaces, and different registration procedures for the namespaces. Callerprefs also uses rfc 2533 to define the semantics of feature sets. But it doesn't support the full range of semantics defined by 2533 - it uses only a subset that can be mapped onto the parameter syntax in a simple way. So, if some existing specification is used to represent combinations of features/capabilities in PIDF, then it needs to have the capability to use any of the feature tags legal according to 2506, and any of the feature sets that can also be represented by callerprefs. The obvious selection is rfc 2533 itself, mapped into xml. This of course assumes that callerprefs doesn't change again. But I think it is important to track callerprefs. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 20 01:47: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 BAA19230 for ; Wed, 20 Nov 2002 01:47: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 gAK6l7Zu010605; Wed, 20 Nov 2002 01:47: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 BAA09612; Wed, 20 Nov 2002 01:48:06 -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 BAA09601 for ; Wed, 20 Nov 2002 01:47:14 -0500 (EST) Received: from d23rh901.au.ibm.com (d23rh901.au.ibm.com [9.185.167.100]) by ausmtp01.au.ibm.com (8.12.1/8.12.1) with ESMTP id gAK6lNoX246558 for ; Wed, 20 Nov 2002 17:47:23 +1100 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.181.2.75]) by d23rh901.au.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAK6fo4E099578 for ; Wed, 20 Nov 2002 17:41:51 +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.9a |January 7, 2002) at 20/11/2002 14:46:11 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] Confused by collection template vs. list presence event 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 Nov 2002 14:46:09 +0800 Hi, When I try to implement some application related to group presence, I am confused to choose the way to handle the presence list subscription. Who can tell me what's the difference of ideas in draft-roach-sip-list-template-00.txt vs. draft-ietf-simple-presencelist-package-00.txt? 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 Wed Nov 20 09:36: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 JAA20197 for ; Wed, 20 Nov 2002 09:36: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 gAKEb6Zu011573; Wed, 20 Nov 2002 09:37: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 JAA11004; Wed, 20 Nov 2002 09:38:06 -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 JAA10993 for ; Wed, 20 Nov 2002 09:37:48 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKEbGO12409 for ; Wed, 20 Nov 2002 16:37:16 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 20 Nov 2002 16:37:41 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Nov 2002 16:37:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FE9@esebe019.ntc.nokia.com> Thread-Topic: who changes im: pres: to sip: Thread-Index: AcKQomA5IbUD9/GEQquwCWoDME7+yA== To: X-OriginalArrivalTime: 20 Nov 2002 14:37:40.0513 (UTC) FILETIME=[60EE5910:01C290A2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA10993 Subject: [Simple] who changes im: pres: to sip: 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 Nov 2002 16:37:40 +0200 Content-Transfer-Encoding: 8bit Hi, Most of us heard the discussion at impp wg meeting about schemes, but there was no consensus on who changes the scheme. There are 2 suggestions: 1. change it to sip as soon as possible, as instructed by presence-07 2. Leave it to the terminating domain. I.e. the domain responsible. Which one of the above should we do? If we choose 2, should presence I-D be changed to reflect that? I'm referring to the text: "When subscribing to a presentity, the subscription can be addressed using the protocol independent form or the SIP or SIPS URI form. In the SIP context, "addressed" refers to the Request-URI. It is RECOMMENDED that if the entity sending a SUBSCRIBE is capable of resolving the protocol independent form to the SIP form, this resolution is done before sending the request" Regards, Hisham _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 20 10:36: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 KAA22175 for ; Wed, 20 Nov 2002 10:36: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 gAKFb7Zu011883; Wed, 20 Nov 2002 10:37:08 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11250; Wed, 20 Nov 2002 10:38:07 -0500 (EST) Received: from magus.nostrum.com (gw-ext.nostrum.com [208.21.192.129] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11237 for ; Wed, 20 Nov 2002 10:37:04 -0500 (EST) Received: from dynamicsoft.com (root@magus.nostrum.com [10.10.10.2]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gAKFanhd013267; Wed, 20 Nov 2002 09:36:49 -0600 (CST) Message-ID: <3DDBAC0E.7020204@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , Adam Roach , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Thoughts on list template References: <001c01c28f4e$76d5cf60$80452acc@dynamicsoft.com> <3DD9822E.9AA9D9D1@cisco.com> <3DD9C0DE.1050008@dynamicsoft.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 20 Nov 2002 10:36:46 -0500 Content-Transfer-Encoding: 7bit This certainly seems like an elegant way to allow assymetric hierachies. There are a few areas that give me heartburn, but on reflection, I realize these issues are with the idea of recursive lists in the first place. 1) We talk about the idea that a watcher can infer list contents from an initial full state notify. But it is not entirely clear to me what a full state notify looks like for a list that contains other lists. Do we expect the watcher to be able to infer the full hiearchy? 2) Robert mentioned a scary one to me this morning: What about circular references in lists? Jonathan Rosenberg wrote: > inline. > > Paul Kyzivat wrote: > > > > Adam Roach wrote: > > > >> Basically, it amounts to this: to give the capabilities that > >> several people want (e.g. arbitrary depth lists) without abandoning > >> templates, we could slightly tweak the meaning of the ".list" > >> template. In particular, "foo.list" would refer to any arbitrary > >> nesting of foo objects; e.g., it would cover what is, under the > >> current draft, called any of foo.list, foo.list.list, > >> foo.list.list.list, ad infinitum. > > > > ... > > > >> So, first: does anyone see anything that would prevent this > >> working, from a technical perspective? > > > > > > I too hope something like this works. I think we need to dig into > > details a bit to figure out if it is going to work. > > > > 1) Does this imply that the server serving an instance of foo.list > > itself issues the subscriptions to all the leaves of the recursive > > list expansion? Or is it just responsible for delegating those? Or > > are both approaches valid? (They may have different authentication > > implications.) The pure template approach clearly implied delegating > > the responsibility for the leaf subscriptions. > > I don't see the difference between the two things? > > > > > 2) Either way, the server for foo.list is now responsible for > > determining if a particular list entry is an instance of foo, or of > > foo.list. Do we have any better way to figure this out than trial and > > error? Is that acceptable? (An alternative might be to explicitly > > type the entries in a list.) > > This is the big issue. > > It might help to step back and consider how this would work in an IDEAL > world of a clean slate, and work backwards. Doing that is what helped us > figure out how to do loose routing, and as it turns out, I think it > solves this problem too. > > In the ideal world, there is no presence package. There is only > the equivalent of "presence.list". That is, we assume at the outset that > a presence subscription always implies a list, and a valid option is a > list of one. Thus, I subscribe to my buddylist with package "presence", > and each of the subscriptions it generates are for the same package, > "presence". The owner of the URI gets to decide whether its a list of > multiple elements, or just one. > > Now, the problem of course is that all of the list features would need > to be replicated in each package. So, the ideal solution there IMHO > would have been to have list processing be central to rfc3265 in the > first place, so that all packages are list enabled from the outset. > > OK, so IF you agree that this is what it ought to have been, how do we > achieve as close a goal as possible with the constraints that we have? > > I would define list processing as an EXTENSION to rfc3265, not a > template or a new package. How would that work? When a UAC subscribes, > it includes a Supported header indicated "lists". The Allow header in > the subscribe also lists multipart as a valid body type thats supported, > along with the MIME type of this XML list meta-data. So, a buddy list > subscription looks like: > > SUBSCRIBE sip:mylist@domain.com SIP/2.0 > Supported: lists > Allow: application/pidf+xml, multipart/mixed, application/elist+xml > Event: presence > > The server knows that mylist is a list, but since the client supports > lists, its OK. The server does a SUBSCRIBE to each participant in the > list, all of them with the Event: presence header, and all of them with > the same Supported and Allow headers. Now, should one of those happen to > be a regular presence server that doesn't support the "lists" extension, > it works just fine! The server will generate NOTIFYs with plain-old > PIDF, no multipart or elist+xml. So, there is no trial-and-error; a > subscription to an element in the list is the same in all cases, and > doesn't require knowing what it is. If it turns out that its a list, > multipart comes back. If not, just plain PIDF. > > Should a user SUBSCRIBE to a list, and not indicate support for "lists" > in the Supported header, the server rejects the request with a 420 and > the appropriate Require header. > > As far as I can tell, this solution buys us EVERYTHING we want: > > * infinite nesting of lists, without the list server needing to know > whether an entry is a list or not > * no trial and error > * backwards compatibility > * graceful evolution, if we want, to a revised rfc3265 that includes the > list processing as a native capability > > > Comments? > > -Jonathan R. > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 20 10:55: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 KAA22848 for ; Wed, 20 Nov 2002 10:55: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 gAKFu3Zu012022; Wed, 20 Nov 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 KAA11360; Wed, 20 Nov 2002 10:57:05 -0500 (EST) Received: from web20703.mail.yahoo.com (web20703.mail.yahoo.com [216.136.226.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id KAA11349 for ; Wed, 20 Nov 2002 10:56:53 -0500 (EST) Message-ID: <20021120155650.95949.qmail@web20703.mail.yahoo.com> Received: from [204.42.69.176] by web20703.mail.yahoo.com via HTTP; Wed, 20 Nov 2002 07:56:50 PST From: Sean Olson Subject: Re: [Simple] Thoughts on list template To: Ben Campbell , Jonathan Rosenberg Cc: Paul Kyzivat , Adam Roach , simple@mailman.dynamicsoft.com In-Reply-To: <3DDBAC0E.7020204@dynamicsoft.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 Nov 2002 07:56:50 -0800 (PST) --- Ben Campbell wrote: > This certainly seems like an elegant way to allow > assymetric hierachies. > There are a few areas that give me heartburn, but on > reflection, I > realize these issues are with the idea of recursive > lists in the first > place. > > 1) We talk about the idea that a watcher can infer > list contents from an > initial full state notify. But it is not entirely > clear to me what a > full state notify looks like for a list that > contains other lists. Do we > expect the watcher to be able to infer the full > hiearchy? I don't think this is necessary, but certainly possible -- if a bit of a pain. The hierarchy of the MIME plus the tuple ID plus the presentity URI plus the From: URI in the NOTIFY gives the watcher enough info to reconstruct this hierarchy if it really wanted to.... but is this a requirement? I'm assuming the watcher has a notion of the hiearchy of the list it is subscribing to -- even though that may be an incomplete view. The watcher could render the NOTIFYs relative to his own view of the list, relative to the hierarchy in the NOTIFYs, or even "flat". > > 2) Robert mentioned a scary one to me this morning: > What about circular > references in lists? Could a common Call-ID be used to break these loops? /sean __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 20 11:02: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 LAA23093 for ; Wed, 20 Nov 2002 11:02: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 gAKG23Zu012105; Wed, 20 Nov 2002 11:02: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 LAA11405; Wed, 20 Nov 2002 11:03:06 -0500 (EST) Received: from web20705.mail.yahoo.com (web20705.mail.yahoo.com [216.136.226.178]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA11394 for ; Wed, 20 Nov 2002 11:02:51 -0500 (EST) Message-ID: <20021120160252.34308.qmail@web20705.mail.yahoo.com> Received: from [204.42.69.176] by web20705.mail.yahoo.com via HTTP; Wed, 20 Nov 2002 08:02:52 PST From: Sean Olson Subject: Re: [Simple] who changes im: pres: to sip: To: hisham.khartabil@nokia.com, simple@mailman.dynamicsoft.com In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE6FE9@esebe019.ntc.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 20 Nov 2002 08:02:52 -0800 (PST) It sounds like the text you reference answers the question. Do it as soon as possible, preferably before you send the request. Different environments and clients may do this at different times depending on your view of "as soon as possible". I think (1) is the right answer, though that might be identical to (2) is some rare cases. The SRV resolution that was discussion in IMPP solves the next hop problem. It did not directly address translation of an im: *URI* to a sip: *URI*. Shouldn't this be left to local policy/implementation? /sean --- hisham.khartabil@nokia.com wrote: > Hi, > > Most of us heard the discussion at impp wg meeting > about schemes, but there was no consensus on who > changes the scheme. > > There are 2 suggestions: > > 1. change it to sip as soon as possible, as > instructed by presence-07 > 2. Leave it to the terminating domain. I.e. the > domain responsible. > > Which one of the above should we do? If we choose 2, > should presence I-D be changed to reflect that? > > I'm referring to the text: > > "When subscribing to a presentity, the subscription > can be addressed > using the protocol independent form or the SIP or > SIPS URI form. In > the SIP context, "addressed" refers to the > Request-URI. It is > RECOMMENDED that if the entity sending a > SUBSCRIBE is capable of > resolving the protocol independent form to the > SIP form, this > resolution is done before sending the request" > > Regards, > Hisham > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 20 12:07: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 MAA25080 for ; Wed, 20 Nov 2002 12:07: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 gAKH8LZu012517; Wed, 20 Nov 2002 12:08: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 MAA11691; Wed, 20 Nov 2002 12:09:09 -0500 (EST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11675 for ; Wed, 20 Nov 2002 12:08:04 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAKH80kL048894 for ; Wed, 20 Nov 2002 18:08:00 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAKH7wda088770 for ; Wed, 20 Nov 2002 18:07:59 +0100 In-Reply-To: To: "Li Hua Tang" Cc: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Confused by collection template vs. list presence event MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 20/11/2002 19:07:59, Serialize complete at 20/11/2002 19:07:59 Content-Type: multipart/alternative; boundary="=_alternative 005E1B76C2256C77_=" 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 Nov 2002 19:07:57 +0200 This is a multipart message in MIME format. --=_alternative 005E1B76C2256C77_= Content-Type: text/plain; charset="US-ASCII" draft-roach-sip-list-template-00.txt it replaces the presencelist package. Note however that there might be changes due to recursive application of the template. Avshalom Li Hua Tang/China/IBM@IBMCN Sent by: simple-admin@mailman.dynamicsoft.com 20/11/2002 08:46 To simple@mailman.dynamicsoft.com cc Subject [Simple] Confused by collection template vs. list presence event Hi, When I try to implement some application related to group presence, I am confused to choose the way to handle the presence list subscription. Who can tell me what's the difference of ideas in draft-roach-sip-list-template-00.txt vs. draft-ietf-simple-presencelist-package-00.txt? Best regards, Tang Lihua Email: tanglih@cn.ibm.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple --=_alternative 005E1B76C2256C77_= Content-Type: text/html; charset="US-ASCII"
draft-roach-sip-list-template-00.txt it replaces the presencelist package.
Note however that there might be changes due to recursive application of the template.

Avshalom



Li Hua Tang/China/IBM@IBMCN
Sent by: simple-admin@mailman.dynamicsoft.com

20/11/2002 08:46

To
simple@mailman.dynamicsoft.com
cc
Subject
[Simple] Confused by collection template vs. list presence event






Hi,

When I try to implement some application related to group presence, I am
confused to choose the way to handle the presence list subscription. Who
can tell me what's the difference of ideas in
draft-roach-sip-list-template-00.txt vs.
draft-ietf-simple-presencelist-package-00.txt?

Best regards,

Tang Lihua
Email:  tanglih@cn.ibm.com

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple
--=_alternative 005E1B76C2256C77_=-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 20 14:26: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 OAA28235 for ; Wed, 20 Nov 2002 14:26: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 gAKJR9Zu013085; Wed, 20 Nov 2002 14:27: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 OAA12145; Wed, 20 Nov 2002 14:28:06 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12134 for ; Wed, 20 Nov 2002 14:27:17 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKJS6B10443 for ; Wed, 20 Nov 2002 21:28:06 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 20 Nov 2002 21:27:16 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Nov 2002 21:27:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] who changes im: pres: to sip: Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FEA@esebe019.ntc.nokia.com> Thread-Topic: [Simple] who changes im: pres: to sip: Thread-Index: AcKQrk1h+6tOCMggTHevDxTmUzQqVwAG24fw To: , X-OriginalArrivalTime: 20 Nov 2002 19:27:16.0489 (UTC) FILETIME=[D5D1DF90:01C290CA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA12134 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 Nov 2002 21:27:15 +0200 Content-Transfer-Encoding: 8bit It was mentioned in the discussion at the impp meeting. What I was trying to ask is if the text in presence-07 is out of date now. Compare the two: From presence-07: "It is RECOMMENDED that if the entity sending a SUBSCRIBE is capable of resolving the protocol independent form to the SIP form, this resolution is done before sending the request" From Jonathan on a different thread: > 1. client looks up _pres._sip.somewhere.com in DNS > 2. client takes the resulting records, and sends the request there. The > r-uri remains a pres URI. > 3. the somewhere.com proxy server understands the pres URI, and applies > some local policy to translate the URI. > 4. Its all sip from there These are contradicting, in some cases. Do I change the scheme before I send? or do I leave the scheme as is and send? Regards, Hisham > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: Wednesday, November 20, 2002 6:03 PM > To: Khartabil Hisham (NMP/Helsinki); simple@mailman.dynamicsoft.com > Subject: Re: [Simple] who changes im: pres: to sip: > > > It sounds like the text you reference answers > the question. Do it as soon as possible, > preferably before you send the request. Different > environments and clients may do this at different > times depending on your view of "as soon as possible". > I think (1) is the right answer, though that might > be identical to (2) is some rare cases. > > The SRV resolution that was discussion in IMPP > solves the next hop problem. It did not directly > address translation of an im: *URI* to a sip: *URI*. > Shouldn't this be left to local policy/implementation? > > /sean > > --- hisham.khartabil@nokia.com wrote: > > Hi, > > > > Most of us heard the discussion at impp wg meeting > > about schemes, but there was no consensus on who > > changes the scheme. > > > > There are 2 suggestions: > > > > 1. change it to sip as soon as possible, as > > instructed by presence-07 > > 2. Leave it to the terminating domain. I.e. the > > domain responsible. > > > > Which one of the above should we do? If we choose 2, > > should presence I-D be changed to reflect that? > > > > I'm referring to the text: > > > > "When subscribing to a presentity, the subscription > > can be addressed > > using the protocol independent form or the SIP or > > SIPS URI form. In > > the SIP context, "addressed" refers to the > > Request-URI. It is > > RECOMMENDED that if the entity sending a > > SUBSCRIBE is capable of > > resolving the protocol independent form to the > > SIP form, this > > resolution is done before sending the request" > > > > Regards, > > Hisham > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Web Hosting - Let the expert host your site > http://webhosting.yahoo.com > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 20 15:03: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 PAA29278 for ; Wed, 20 Nov 2002 15:03: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 gAKJn3Zu013221; Wed, 20 Nov 2002 14:49: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 OAA12235; Wed, 20 Nov 2002 14:50:07 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12222 for ; Wed, 20 Nov 2002 14:49:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.78]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAKJnjYH005056; Wed, 20 Nov 2002 14:49:47 -0500 (EST) Message-ID: <3DDBE758.1090108@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avshalom Houri CC: Li Hua Tang , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Confused by collection template vs. list presence event References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 20 Nov 2002 14:49:44 -0500 Content-Transfer-Encoding: 7bit In particular, the most recent discussions on the list suggest that its NOT a template, but a sip events extension using the regular presence package. So, this will probably change again, but I think we have finally found the right solution... -Jonathan R. Avshalom Houri wrote: > > draft-roach-sip-list-template-00.txt it replaces the presencelist package. > Note however that there might be changes due to recursive application of > the template. > > Avshalom > > > > *Li Hua Tang/China/IBM@IBMCN* > Sent by: simple-admin@mailman.dynamicsoft.com > > 20/11/2002 08:46 > > To > simple@mailman.dynamicsoft.com > cc > Subject > [Simple] Confused by collection template vs. list presence event > > > > > > > > Hi, > > When I try to implement some application related to group presence, I am > confused to choose the way to handle the presence list subscription. Who > can tell me what's the difference of ideas in > draft-roach-sip-list-template-00.txt vs. > draft-ietf-simple-presencelist-package-00.txt? > > Best regards, > > Tang Lihua > Email: tanglih@cn.ibm.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 20 15:18: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 PAA29712 for ; Wed, 20 Nov 2002 15:18: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 gAKKI2Zu013395; Wed, 20 Nov 2002 15:18: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 PAA12340; Wed, 20 Nov 2002 15:19:05 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12329 for ; Wed, 20 Nov 2002 15:18:53 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKKJhB02245 for ; Wed, 20 Nov 2002 22:19:43 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 20 Nov 2002 22:18:52 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Nov 2002 22:18:51 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Nov 2002 22:18:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] who changes im: pres: to sip: Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945096@esebe013.ntc.nokia.com> Thread-Topic: [Simple] who changes im: pres: to sip: Thread-Index: AcKQrnT6GDNfUvfxReWSNUG75nr4IgAIJ4eQ To: , , X-OriginalArrivalTime: 20 Nov 2002 20:18:51.0635 (UTC) FILETIME=[0AABAC30:01C290D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA12329 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 Nov 2002 22:18:51 +0200 Content-Transfer-Encoding: 8bit Hi, inline. > It sounds like the text you reference answers > the question. Do it as soon as possible, > preferably before you send the request. Different > environments and clients may do this at different > times depending on your view of "as soon as possible". > I think (1) is the right answer, though that might > be identical to (2) is some rare cases. Well, I would argue that the translation can *never* happen before the request is sent. We can't mandate a direct translation from an IM URI to a SIP URI, and any other translation would be local policy to the GW. So the Request-URI would always need to have the original im: URI in it. This of course causes problems for proxies that don't recognize the im URI scheme. My proposal is that the client uses a translation similar to when translating tel URIs. Namely, the im URI is translated into a SIP URI by simply replacing the scheme. Additionally, the URI parameter 'user' is populated with the original scheme which in this case is 'im'. If I need to contact 'im:foo@bar.com', I resolve the next hop using SRV, and in the request line have the following: MESSAGE sip:foo@bar.com;user=im SIP/2.0 This will enable both cases (1 and 2 below) since a GW can fall back to the direct translation by ignoring the user param. If the local policy dictates some other translation, the user parameter gives enough information to also do that at the GW. > The SRV resolution that was discussion in IMPP > solves the next hop problem. It did not directly > address translation of an im: *URI* to a sip: *URI*. > Shouldn't this be left to local policy/implementation? I think the above translation would solve this problem. Thoughts? Cheers, Aki > --- hisham.khartabil@nokia.com wrote: > > Hi, > > > > Most of us heard the discussion at impp wg meeting > > about schemes, but there was no consensus on who > > changes the scheme. > > > > There are 2 suggestions: > > > > 1. change it to sip as soon as possible, as > > instructed by presence-07 > > 2. Leave it to the terminating domain. I.e. the > > domain responsible. > > > > Which one of the above should we do? If we choose 2, > > should presence I-D be changed to reflect that? > > > > I'm referring to the text: > > > > "When subscribing to a presentity, the subscription > > can be addressed > > using the protocol independent form or the SIP or > > SIPS URI form. In > > the SIP context, "addressed" refers to the > > Request-URI. It is > > RECOMMENDED that if the entity sending a > > SUBSCRIBE is capable of > > resolving the protocol independent form to the > > SIP form, this > > resolution is done before sending the request" > > > > Regards, > > Hisham > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Web Hosting - Let the expert host your site > http://webhosting.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 Nov 20 16:33: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 QAA01687 for ; Wed, 20 Nov 2002 16:33: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 gAKLUDZu013746; Wed, 20 Nov 2002 16:30: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 QAA12581; Wed, 20 Nov 2002 16:31:09 -0500 (EST) Received: from web20701.mail.yahoo.com (web20701.mail.yahoo.com [216.136.226.174]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA12570 for ; Wed, 20 Nov 2002 16:30:29 -0500 (EST) Message-ID: <20021120213030.52417.qmail@web20701.mail.yahoo.com> Received: from [204.42.69.176] by web20701.mail.yahoo.com via HTTP; Wed, 20 Nov 2002 13:30:30 PST From: Sean Olson Subject: RE: [Simple] who changes im: pres: to sip: To: aki.niemi@nokia.com, hisham.khartabil@nokia.com, simple@mailman.dynamicsoft.com In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945096@esebe013.ntc.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 20 Nov 2002 13:30:30 -0800 (PST) To take your analogy for tel: URIs to completion, wouldn't we want to represent the entire im: URI in the user portion of the sip: URI and tack on a "user=im" parameter? This seems like an interesting approach but I'm concerned that the user=im parameter would *have* to be interpreted by the proxies to do the right thing. In that case, we would be better off with sticking with an im: URI in the Request-URI. /sean --- aki.niemi@nokia.com wrote: > Hi, > > inline. > > > It sounds like the text you reference answers > > the question. Do it as soon as possible, > > preferably before you send the request. Different > > environments and clients may do this at different > > times depending on your view of "as soon as > possible". > > I think (1) is the right answer, though that might > > be identical to (2) is some rare cases. > > Well, I would argue that the translation can *never* > happen before the request is sent. We can't mandate > a direct translation from an IM URI to a SIP URI, > and any other translation would be local policy to > the GW. > > So the Request-URI would always need to have the > original im: URI in it. This of course causes > problems for proxies that don't recognize the im URI > scheme. > > My proposal is that the client uses a translation > similar to when translating tel URIs. Namely, the im > URI is translated into a SIP URI by simply replacing > the scheme. Additionally, the URI parameter 'user' > is populated with the original scheme which in this > case is 'im'. > > If I need to contact 'im:foo@bar.com', I resolve the > next hop using SRV, and in the request line have the > following: > > MESSAGE sip:foo@bar.com;user=im SIP/2.0 > > This will enable both cases (1 and 2 below) since a > GW can fall back to the direct translation by > ignoring the user param. If the local policy > dictates some other translation, the user parameter > gives enough information to also do that at the GW. > > > The SRV resolution that was discussion in IMPP > > solves the next hop problem. It did not directly > > address translation of an im: *URI* to a sip: > *URI*. > > Shouldn't this be left to local > policy/implementation? > > I think the above translation would solve this > problem. > > Thoughts? > > Cheers, > Aki > > > --- hisham.khartabil@nokia.com wrote: > > > Hi, > > > > > > Most of us heard the discussion at impp wg > meeting > > > about schemes, but there was no consensus on who > > > changes the scheme. > > > > > > There are 2 suggestions: > > > > > > 1. change it to sip as soon as possible, as > > > instructed by presence-07 > > > 2. Leave it to the terminating domain. I.e. the > > > domain responsible. > > > > > > Which one of the above should we do? If we > choose 2, > > > should presence I-D be changed to reflect that? > > > > > > I'm referring to the text: > > > > > > "When subscribing to a presentity, the > subscription > > > can be addressed > > > using the protocol independent form or the > SIP or > > > SIPS URI form. In > > > the SIP context, "addressed" refers to the > > > Request-URI. It is > > > RECOMMENDED that if the entity sending a > > > SUBSCRIBE is capable of > > > resolving the protocol independent form to > the > > > SIP form, this > > > resolution is done before sending the > request" > > > > > > Regards, > > > Hisham > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.com > > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Web Hosting - Let the expert host your site > > http://webhosting.yahoo.com > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 20 17:12: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 RAA02967 for ; Wed, 20 Nov 2002 17:12: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 gAKM23Zu013926; Wed, 20 Nov 2002 17:02: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 RAA12724; Wed, 20 Nov 2002 17:03:06 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12713 for ; Wed, 20 Nov 2002 17:02:37 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKM3RR08401 for ; Thu, 21 Nov 2002 00:03:28 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Nov 2002 00:02:38 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 00:02:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] who changes im: pres: to sip: Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945097@esebe013.ntc.nokia.com> Thread-Topic: [Simple] who changes im: pres: to sip: Thread-Index: AcKQ3A7uYoFFjqAmR6WE/pGyJEF6jQAAWelw To: , , X-OriginalArrivalTime: 20 Nov 2002 22:02:37.0765 (UTC) FILETIME=[89BBB750:01C290E0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA12713 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, 21 Nov 2002 00:02:37 +0200 Content-Transfer-Encoding: 8bit Hi, > To take your analogy for tel: URIs to completion, > wouldn't we want to represent the entire im: URI in > the user portion of the sip: URI and tack on a > "user=im" parameter? I'm not sure we'd have to follow the tel URI conventions all the way. The im and SIP URI schemes seem to be pretty similar anyway. And unlike tel, the im URI can't include any URI parameters (I think...) However, if we did follow the tel URI way, we'd run into the problem you describe below. > This seems like an interesting approach but I'm > concerned that the user=im parameter would *have* > to be interpreted by the proxies to do the right > thing. In that case, we would be better off with > sticking with an im: URI in the Request-URI. I think having the im URI in the Request-URI is even worse. It would mean that all the proxies in the path of this request would have to support the im URI scheme to be able to route the message at all. With the user-parameter, at least these intermediary proxies would still be able to route the request normally to the owner domain. The owner proxy of the Request-URI would then have to interpret the user-parameter to do the right thing, at least if the tel URI conventions were applied as they are right now. However, my preference would be to specify the translation such that the right thing could be done even when ignoring the user-parameter. This would require a translation which doesn't include the escaped im URI in the user part of the SIP URI. Cheers, Aki > --- aki.niemi@nokia.com wrote: > > Hi, > > > > inline. > > > > > It sounds like the text you reference answers > > > the question. Do it as soon as possible, > > > preferably before you send the request. Different > > > environments and clients may do this at different > > > times depending on your view of "as soon as > > possible". > > > I think (1) is the right answer, though that might > > > be identical to (2) is some rare cases. > > > > Well, I would argue that the translation can *never* > > happen before the request is sent. We can't mandate > > a direct translation from an IM URI to a SIP URI, > > and any other translation would be local policy to > > the GW. > > > > So the Request-URI would always need to have the > > original im: URI in it. This of course causes > > problems for proxies that don't recognize the im URI > > scheme. > > > > My proposal is that the client uses a translation > > similar to when translating tel URIs. Namely, the im > > URI is translated into a SIP URI by simply replacing > > the scheme. Additionally, the URI parameter 'user' > > is populated with the original scheme which in this > > case is 'im'. > > > > If I need to contact 'im:foo@bar.com', I resolve the > > next hop using SRV, and in the request line have the > > following: > > > > MESSAGE sip:foo@bar.com;user=im SIP/2.0 > > > > This will enable both cases (1 and 2 below) since a > > GW can fall back to the direct translation by > > ignoring the user param. If the local policy > > dictates some other translation, the user parameter > > gives enough information to also do that at the GW. > > > > > The SRV resolution that was discussion in IMPP > > > solves the next hop problem. It did not directly > > > address translation of an im: *URI* to a sip: > > *URI*. > > > Shouldn't this be left to local > > policy/implementation? > > > > I think the above translation would solve this > > problem. > > > > Thoughts? > > > > Cheers, > > Aki > > > > > --- hisham.khartabil@nokia.com wrote: > > > > Hi, > > > > > > > > Most of us heard the discussion at impp wg > > meeting > > > > about schemes, but there was no consensus on who > > > > changes the scheme. > > > > > > > > There are 2 suggestions: > > > > > > > > 1. change it to sip as soon as possible, as > > > > instructed by presence-07 > > > > 2. Leave it to the terminating domain. I.e. the > > > > domain responsible. > > > > > > > > Which one of the above should we do? If we > > choose 2, > > > > should presence I-D be changed to reflect that? > > > > > > > > I'm referring to the text: > > > > > > > > "When subscribing to a presentity, the > > subscription > > > > can be addressed > > > > using the protocol independent form or the > > SIP or > > > > SIPS URI form. In > > > > the SIP context, "addressed" refers to the > > > > Request-URI. It is > > > > RECOMMENDED that if the entity sending a > > > > SUBSCRIBE is capable of > > > > resolving the protocol independent form to > > the > > > > SIP form, this > > > > resolution is done before sending the > > request" > > > > > > > > Regards, > > > > Hisham > > > > _______________________________________________ > > > > simple mailing list > > > > simple@mailman.dynamicsoft.com > > > > > > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Web Hosting - Let the expert host your site > > > http://webhosting.yahoo.com > > > _______________________________________________ > > > simple mailing list > > > simple@mailman.dynamicsoft.com > > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Web Hosting - Let the expert host your site > http://webhosting.yahoo.com > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 20 17:31: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 RAA03390 for ; Wed, 20 Nov 2002 17:30: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 gAKMV5Zu014094; Wed, 20 Nov 2002 17:31: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 RAA12836; Wed, 20 Nov 2002 17:32:06 -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 RAA12825 for ; Wed, 20 Nov 2002 17:31:20 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKMUlT28209 for ; Thu, 21 Nov 2002 00:30:47 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Nov 2002 00:31:20 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 00:31:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] who changes im: pres: to sip: Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FEB@esebe019.ntc.nokia.com> Thread-Topic: [Simple] who changes im: pres: to sip: Thread-Index: AcKQ3A7uYoFFjqAmR6WE/pGyJEF6jQAAWelwAAFppoA= To: , , X-OriginalArrivalTime: 20 Nov 2002 22:31:18.0950 (UTC) FILETIME=[8BA3B460:01C290E4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA12825 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, 21 Nov 2002 00:31:18 +0200 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Niemi Aki (NET/Espoo) > Sent: Thursday, November 21, 2002 12:03 AM > To: 'ext Sean Olson'; Khartabil Hisham (NMP/Helsinki); > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] who changes im: pres: to sip: > > > Hi, > > > To take your analogy for tel: URIs to completion, > > wouldn't we want to represent the entire im: URI in > > the user portion of the sip: URI and tack on a > > "user=im" parameter? > > I'm not sure we'd have to follow the tel URI conventions all > the way. The im and SIP URI schemes seem to be pretty similar > anyway. And unlike tel, the im URI can't include any URI > parameters (I think...) However, if we did follow the tel URI > way, we'd run into the problem you describe below. > > > This seems like an interesting approach but I'm > > concerned that the user=im parameter would *have* > > to be interpreted by the proxies to do the right > > thing. In that case, we would be better off with > > sticking with an im: URI in the Request-URI. > > I think having the im URI in the Request-URI is even worse. > It would mean that all the proxies in the path of this > request would have to support the im URI scheme to be able to > route the message at all. With the user-parameter, at least > these intermediary proxies would still be able to route the > request normally to the owner domain. When you do an SRV query on _im._sip.bar.com, you would expect the address returned to be for an entity that understands im scheme. So leaving the scheme as im is probably better. Or are there any scenarios where that is not the case? Regards, Hisham > > The owner proxy of the Request-URI would then have to > interpret the user-parameter to do the right thing, at least > if the tel URI conventions were applied as they are right now. > > However, my preference would be to specify the translation > such that the right thing could be done even when ignoring > the user-parameter. This would require a translation which > doesn't include the escaped im URI in the user part of the SIP URI. > > Cheers, > Aki > > > --- aki.niemi@nokia.com wrote: > > > Hi, > > > > > > inline. > > > > > > > It sounds like the text you reference answers > > > > the question. Do it as soon as possible, > > > > preferably before you send the request. Different > > > > environments and clients may do this at different > > > > times depending on your view of "as soon as > > > possible". > > > > I think (1) is the right answer, though that might > > > > be identical to (2) is some rare cases. > > > > > > Well, I would argue that the translation can *never* > > > happen before the request is sent. We can't mandate > > > a direct translation from an IM URI to a SIP URI, > > > and any other translation would be local policy to > > > the GW. > > > > > > So the Request-URI would always need to have the > > > original im: URI in it. This of course causes > > > problems for proxies that don't recognize the im URI > > > scheme. > > > > > > My proposal is that the client uses a translation > > > similar to when translating tel URIs. Namely, the im > > > URI is translated into a SIP URI by simply replacing > > > the scheme. Additionally, the URI parameter 'user' > > > is populated with the original scheme which in this > > > case is 'im'. > > > > > > If I need to contact 'im:foo@bar.com', I resolve the > > > next hop using SRV, and in the request line have the > > > following: > > > > > > MESSAGE sip:foo@bar.com;user=im SIP/2.0 > > > > > > This will enable both cases (1 and 2 below) since a > > > GW can fall back to the direct translation by > > > ignoring the user param. If the local policy > > > dictates some other translation, the user parameter > > > gives enough information to also do that at the GW. > > > > > > > The SRV resolution that was discussion in IMPP > > > > solves the next hop problem. It did not directly > > > > address translation of an im: *URI* to a sip: > > > *URI*. > > > > Shouldn't this be left to local > > > policy/implementation? > > > > > > I think the above translation would solve this > > > problem. > > > > > > Thoughts? > > > > > > Cheers, > > > Aki > > > > > > > --- hisham.khartabil@nokia.com wrote: > > > > > Hi, > > > > > > > > > > Most of us heard the discussion at impp wg > > > meeting > > > > > about schemes, but there was no consensus on who > > > > > changes the scheme. > > > > > > > > > > There are 2 suggestions: > > > > > > > > > > 1. change it to sip as soon as possible, as > > > > > instructed by presence-07 > > > > > 2. Leave it to the terminating domain. I.e. the > > > > > domain responsible. > > > > > > > > > > Which one of the above should we do? If we > > > choose 2, > > > > > should presence I-D be changed to reflect that? > > > > > > > > > > I'm referring to the text: > > > > > > > > > > "When subscribing to a presentity, the > > > subscription > > > > > can be addressed > > > > > using the protocol independent form or the > > > SIP or > > > > > SIPS URI form. In > > > > > the SIP context, "addressed" refers to the > > > > > Request-URI. It is > > > > > RECOMMENDED that if the entity sending a > > > > > SUBSCRIBE is capable of > > > > > resolving the protocol independent form to > > > the > > > > > SIP form, this > > > > > resolution is done before sending the > > > request" > > > > > > > > > > Regards, > > > > > Hisham > > > > > _______________________________________________ > > > > > simple mailing list > > > > > simple@mailman.dynamicsoft.com > > > > > > > > > > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > > > > __________________________________________________ > > > > Do you Yahoo!? > > > > Yahoo! Web Hosting - Let the expert host your site > > > > http://webhosting.yahoo.com > > > > _______________________________________________ > > > > simple mailing list > > > > simple@mailman.dynamicsoft.com > > > > > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Web Hosting - Let the expert host your site > > http://webhosting.yahoo.com > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 20 17: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 RAA03615 for ; Wed, 20 Nov 2002 17:36: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 gAKMa3Zu014197; Wed, 20 Nov 2002 17:36: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 RAA12918; Wed, 20 Nov 2002 17:37:06 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12895 for ; Wed, 20 Nov 2002 17:36:21 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKMbBR19835 for ; Thu, 21 Nov 2002 00:37:12 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 21 Nov 2002 00:35:45 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 00:35:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: [Simple] who changes im: pres: to sip: Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FEC@esebe019.ntc.nokia.com> Thread-Topic: [Simple] who changes im: pres: to sip: Thread-Index: AcKQrk1h+6tOCMggTHevDxTmUzQqVwAG24fwAAZDo2AAAImDsA== To: X-OriginalArrivalTime: 20 Nov 2002 22:35:46.0727 (UTC) FILETIME=[2B3F3B70:01C290E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA12895 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, 21 Nov 2002 00:35:46 +0200 Content-Transfer-Encoding: 8bit Looks like Ryan pressed the "Reply" button instead of "Reply to All". > -----Original Message----- > From: ext Ryan Chapman [mailto:Rchapman@seancesoft.com] > Sent: Thursday, November 21, 2002 12:25 AM > To: Khartabil Hisham (NMP/Helsinki) > Subject: RE: [Simple] who changes im: pres: to sip: > > > Because the snippet from Jonathan below was prompted by a > question I raised on the issue, I thought I'd wade in to the > discussion... > > It seems that a fairly logical approach is to use recursive > SRV lookups to translate the URI. The first lookup would > determine the domain associated with the particular URI. So, > for example, im:somebody@somewhere.com would result in a query for: > > _im._sip.somewhere.com > > Which would give me a new domain associated with IM/SIP at > somewhere.com. Assuming the result was something like > "im.somewhere.com", the SIP URI that would result would be: > > sip:im.somewhere.com > > ...at which point I proceed with normal SIP. If the lookup > failed, I would just replace "im" with "sip". > > Using this approach, nothing needs to be configured save for > the application itself and the name server of the appropriate > organization. Proxies need never concern themselves with any > sort of translation. > > I'm not an SRV pro, so the above may not be feasible, but it > has the benefit of being logical and clean. It also allows > one to build arbitrarily complex protocols on top of SIP > (e.g., xyz -> abc -> im -> sip...). > > Ryan > > > > > From Jonathan on a different thread: > > > > > 1. client looks up _pres._sip.somewhere.com in DNS > > > 2. client takes the resulting records, and sends the > > request there. The > > > r-uri remains a pres URI. > > > 3. the somewhere.com proxy server understands the pres URI, > > and applies > > > some local policy to translate the URI. > > > 4. Its all sip from there > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 20 17:45: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 RAA03903 for ; Wed, 20 Nov 2002 17:45: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 gAKMk9Zu014297; Wed, 20 Nov 2002 17:46: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 RAA12981; Wed, 20 Nov 2002 17:47: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 RAA12970 for ; Wed, 20 Nov 2002 17:46:47 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKMkET04062 for ; Thu, 21 Nov 2002 00:46:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Nov 2002 00:46:46 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 00:46:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] who changes im: pres: to sip: Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD095@esebe013.ntc.nokia.com> Thread-Topic: [Simple] who changes im: pres: to sip: Thread-Index: AcKQ3A7uYoFFjqAmR6WE/pGyJEF6jQAAWelwAAFppoAAANSlwA== To: , , X-OriginalArrivalTime: 20 Nov 2002 22:46:46.0904 (UTC) FILETIME=[B4BE3F80:01C290E6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA12970 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, 21 Nov 2002 00:46:46 +0200 Content-Transfer-Encoding: 8bit Hi Hisham, [...] > > I think having the im URI in the Request-URI is even worse. > > It would mean that all the proxies in the path of this > > request would have to support the im URI scheme to be able to > > route the message at all. With the user-parameter, at least > > these intermediary proxies would still be able to route the > > request normally to the owner domain. > > When you do an SRV query on _im._sip.bar.com, you would > expect the address returned to be for an entity that > understands im scheme. So leaving the scheme as im is > probably better. Or are there any scenarios where that is not > the case? Yeah, that actually defeats the whole purpose of the translation. I agree, im URI in the Request-URI will do the trick. Cheers, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 20 19:09: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 TAA05582 for ; Wed, 20 Nov 2002 19:09: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 gAL08JZu014593; Wed, 20 Nov 2002 19:08: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 TAA13229; Wed, 20 Nov 2002 19:09:14 -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 TAA13218 for ; Wed, 20 Nov 2002 19:08:29 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAL07tT02795 for ; Thu, 21 Nov 2002 02:07:56 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Nov 2002 02:08:28 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 02:08:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] who changes im: pres: to sip: Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945098@esebe013.ntc.nokia.com> Thread-Topic: [Simple] who changes im: pres: to sip: Thread-Index: AcKQ3A7uYoFFjqAmR6WE/pGyJEF6jQAAWelwAAFppoAAANSlwAABKnNg To: , , X-OriginalArrivalTime: 21 Nov 2002 00:08:28.0128 (UTC) FILETIME=[1E19AE00:01C290F2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id TAA13218 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, 21 Nov 2002 02:08:27 +0200 Content-Transfer-Encoding: 8bit Hi, Apologies for flooding the list by thinking aloud here. ;) However, after thinking about this a little more, I did come up with a scenario for which the im/pres URI in the Request-URI would not work. It's when a UA sits behind an outbound proxy that knows nothing about im/pres URIs. Then the UA itself will have to do tricks with the im URI so that the request can be routed by this outbound proxy. I see two choices: 1) Use a translation very much like a tel URI to SIP URI translation. The entire im URI would go into the user part of the SIP URI, and the target domain received in the SRV query would go into the hostport part. And again, the ';user=im' or ';user=pres' would indicate that such a translation was done. 2) Keep things as they are, and in most cases use the abstract im or pres URI in the Request-URI (if not in all cases). Use SRV normally, and if the UA doesn't send the request directly to the target server, the UA needs to use loose routing to guide it there. Option 1 would force the target proxy to interpret the user-parameter to process the request correctly. Option 2 doesn't seem to require anything new, so it looks much better to me. Thoughts? Cheers, Aki > Hi Hisham, > > [...] > > > I think having the im URI in the Request-URI is even worse. > > > It would mean that all the proxies in the path of this > > > request would have to support the im URI scheme to be able to > > > route the message at all. With the user-parameter, at least > > > these intermediary proxies would still be able to route the > > > request normally to the owner domain. > > > > When you do an SRV query on _im._sip.bar.com, you would > > expect the address returned to be for an entity that > > understands im scheme. So leaving the scheme as im is > > probably better. Or are there any scenarios where that is not > > the case? > > Yeah, that actually defeats the whole purpose of the > translation. I agree, im URI in the Request-URI will do the trick. > > Cheers, > Aki > _______________________________________________ > 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 Nov 21 02:49:20 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 CAA24844 for ; Thu, 21 Nov 2002 02:49: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 gAL7n6Zu015546; Thu, 21 Nov 2002 02:49:07 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14606; Thu, 21 Nov 2002 02:50: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 CAA14593 for ; Thu, 21 Nov 2002 02:49:18 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.58]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAL7nKYH005515; Thu, 21 Nov 2002 02:49:20 -0500 (EST) Message-ID: <3DDC8FFE.1040909@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: seancolson@yahoo.com, hisham.khartabil@nokia.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] who changes im: pres: to sip: References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945097@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 21 Nov 2002 02:49:18 -0500 Content-Transfer-Encoding: 7bit inline. aki.niemi@nokia.com wrote: > Hi, > > >> To take your analogy for tel: URIs to completion, wouldn't we want >> to represent the entire im: URI in the user portion of the sip: URI >> and tack on a "user=im" parameter? > > > I'm not sure we'd have to follow the tel URI conventions all the way. > The im and SIP URI schemes seem to be pretty similar anyway. And > unlike tel, the im URI can't include any URI parameters (I think...) > However, if we did follow the tel URI way, we'd run into the problem > you describe below. Careful!!! There is a HUGE difference between the im and tel URIs. Thats the presence of the domain part. The domain part says something terribly important. It says that the user part has an interpretation that can ONLY be done by an entity in that domain. Nothing outside of that domain can use it. A tel URI doesn't have that property. THe "user part" is well defiend everywhere. Translating a URI cannot be done if you cannot understand the resource that URI points to. In the case of the IM URI, only the server in that domain can understand, and thus, translate it. Not so for tel URI. As an example, a valid translation is: im:jonathan.rosenberg@dynamicsoft.com -> sip:jdrosen@dynamicsoft.com only dynamicsoft.com can do that. > > >> This seems like an interesting approach but I'm concerned that the >> user=im parameter would *have* to be interpreted by the proxies to >> do the right thing. In that case, we would be better off with >> sticking with an im: URI in the Request-URI. > > > I think having the im URI in the Request-URI is even worse. It would > mean that all the proxies in the path of this request would have to > support the im URI scheme to be able to route the message at all. > With the user-parameter, at least these intermediary proxies would > still be able to route the request normally to the owner domain. Not so. Remember that you are looking up the IM URI in DNS, and sending it there. Thus, the domain which needs to interpret it is the one on the RHS of the IM URI. Since its the one that created that URI in the first place, it clearly means it can understand and process it. Now, there is this issue of the outbound proxy you raise in another note, which I'll respond to there. Not an easy issue. THe net/net, however, is that the text in the presence spec as written is probably wrong, and needs to be updated to reflect the current thinking on the pres URI. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 21 02:53: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 CAA24892 for ; Thu, 21 Nov 2002 02:53: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 gAL7s1Zu015617; Thu, 21 Nov 2002 02:54: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 CAA14655; Thu, 21 Nov 2002 02:55:07 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14642 for ; Thu, 21 Nov 2002 02:54:48 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.58]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAL7soYH005518; Thu, 21 Nov 2002 02:54:51 -0500 (EST) Message-ID: <3DDC9148.4030407@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: hisham.khartabil@nokia.com, seancolson@yahoo.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] who changes im: pres: to sip: References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945098@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 21 Nov 2002 02:54:48 -0500 Content-Transfer-Encoding: 7bit inline. aki.niemi@nokia.com wrote: > It's when a UA sits behind an outbound proxy that knows nothing about > im/pres URIs. Then the UA itself will have to do tricks with the im > URI so that the request can be routed by this outbound proxy. Yes, this is definitely the problematic case. > > I see two choices: > > 1) Use a translation very much like a tel URI to SIP URI translation. > The entire im URI would go into the user part of the SIP URI, and the > target domain received in the SRV query would go into the hostport > part. And again, the ';user=im' or ';user=pres' would indicate that > such a translation was done. Yuck. > > 2) Keep things as they are, and in most cases use the abstract im or > pres URI in the Request-URI (if not in all cases). Use SRV normally, > and if the UA doesn't send the request directly to the target server, > the UA needs to use loose routing to guide it there. This is better, but it requires the UA to know that its outbound proxy doesn't support the im or pres URI. > > Option 1 would force the target proxy to interpret the user-parameter > to process the request correctly. Option 2 doesn't seem to require > anything new, so it looks much better to me. There is a third option, which is do nothing. In this case, the proxy will fail the request. That is exactly what we do today for tel URI. If a UAC sends a request with a tel URI in the request URI to an outbound proxy (a common operation in sip networks), if the outbound proxy doesn't understand the tel URI, the request fails. Same with sips. So, I don't believe we should be special casing the IM/Pres URIs. Generally speaking, the price you pay for using outbound proxies is that it knows how to process your request, new URIs, proxy-requires, and anything else. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 21 03:17: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 DAA25212 for ; Thu, 21 Nov 2002 03:17: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 gAL8I2Zu015735; Thu, 21 Nov 2002 03:18: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 DAA14756; Thu, 21 Nov 2002 03:19:07 -0500 (EST) Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14745 for ; Thu, 21 Nov 2002 03:18:10 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.58]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAL8IDYH005531; Thu, 21 Nov 2002 03:18:13 -0500 (EST) Message-ID: <3DDC96C2.4060800@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Paul Kyzivat , Adam Roach , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Thoughts on list template References: <001c01c28f4e$76d5cf60$80452acc@dynamicsoft.com> <3DD9822E.9AA9D9D1@cisco.com> <3DD9C0DE.1050008@dynamicsoft.com> <3DDBAC0E.7020204@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 21 Nov 2002 03:18:10 -0500 Content-Transfer-Encoding: 7bit inline. Ben Campbell wrote: > This certainly seems like an elegant way to allow assymetric hierachies. Thanks. I definitely think this is right. > There are a few areas that give me heartburn, but on reflection, I > realize these issues are with the idea of recursive lists in the first > place. > > 1) We talk about the idea that a watcher can infer list contents from an > initial full state notify. But it is not entirely clear to me what a > full state notify looks like for a list that contains other lists. Do we > expect the watcher to be able to infer the full hiearchy? I thought that the presence list server (or whatever we are calling it these days) would subscribe to each element, and when it gets the notifies, will know whether each element is a single URI or itself a list. It then reports its own result as a list, where elements are either a single URI, or another list, based on its downstream subscribes. The result is that the hierarchy would be constructed and placed in the full state notify. Now, the bigger issue is full-state notifies for big lists. They quickly become unwieldy. If we apply the current semantic - which is that NOTIFY's triggered from SUBSCRIBE contain full state, you end up with this huge NOTIFY after every refresh, probably not what you want. If you assume that the list structure itself (ie., the set of presentities in any list), rather than the state of the presentities, is synchronized separately, you don't really have a strong need for full state updates. Instead, you can send a bunch of partial updates (state for a single presentity) that are then used by the subscriber to fill in the state of the individual leaves of the tree. Its probably OK for those partial notifies to be sent to the subscriber over some window of time after the subscribe (i.e, it takes 2 seconds for the state of all leaves to be transferred). We could also define a parameter in the SUBSCRIBE somewhere that explicitly tells the server to send a full state in a NOTIFY. The deafult operation is to never send full state, only when requested. > > 2) Robert mentioned a scary one to me this morning: What about circular > references in lists? Yikes!! We can either do a "hop counter" - every time a server triggers a subscription to get state for an incoming subscription it decrements a counter, or we can detect the loop through a persistent identifer as sean suggests. I think that there is no real meaning of "spiral" here, which would immensely complicate such an approach. One way or another, we have to worry about this case if we accept recursive lists. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 25 12:12: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 MAA10246 for ; Mon, 25 Nov 2002 12:12:30 -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 gAPHDHN4001586; Mon, 25 Nov 2002 12:13:18 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01526; Mon, 25 Nov 2002 12:14:11 -0500 (EST) Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01515 for ; Mon, 25 Nov 2002 12:13:03 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gAPHD2127509; Mon, 25 Nov 2002 11:13:02 -0600 Subject: Re: [Simple] Notes and slides From: Robert Sparks To: Robert Sparks Cc: simple@mailman.dynamicsoft.com In-Reply-To: <1037740088.1253.9.camel@RjS.localdomain> References: <1037740088.1253.9.camel@RjS.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Message-Id: <1038244330.915.24.camel@RjS.localdomain> Mime-Version: 1.0 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 25 Nov 2002 12:12:09 -0500 Content-Transfer-Encoding: 7bit I've received no comments so far. I will submit these (modulo minor spelling corrections in the notes) for the proceedings at the end of the week. If you haven't already done so, please take a few minutes to look them over. Send a note even if you find no corrections are needed so I know they've been reviewed. I would also appreciate a note from the presenters when they have verified that the correct copy of their slides appears at the link below. Thanks! RjS On Tue, 2002-11-19 at 16:08, Robert Sparks wrote: > Rough notes and the slides from the IETF55 SIMPLE > meeting are available at > http://www.softarmor.com/simple/meets/ietf55 > > Please send corrections to the notes to the list. > > Send corrections to the slides (or error reports > concerning the SIMPLE weblet) directly to me. > > RjS > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 28 03:42: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 DAA23016 for ; Thu, 28 Nov 2002 03:42: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 gAS8hBN4011918; Thu, 28 Nov 2002 03: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 DAA12626; Thu, 28 Nov 2002 03:44: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 DAA12610 for ; Thu, 28 Nov 2002 03:43:01 -0500 (EST) Received: from d23rh901.au.ibm.com (d23rh901.au.ibm.com [9.185.167.100]) by ausmtp01.au.ibm.com (8.12.1/8.12.1) with ESMTP id gAS8hBUr353704 for ; Thu, 28 Nov 2002 19:43:11 +1100 Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.181.2.75]) by d23rh901.au.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAS8bb7L108918 for ; Thu, 28 Nov 2002 19:37:39 +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.9a |January 7, 2002) at 28/11/2002 16:42:12 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Simple] any SIP progress in devices? 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 Nov 2002 16:41:17 +0800 Hi, all I'd like to know how about SIP work on sessions involving in multiple devices and server resources. My interesting points includes how to exchange the events among devices, how to control Prompt Players, Text to Speech, and Speech Recognition Engines. Thanks very much for your information. Best regards, Tang Lihua IBM China Research Lab. 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 Thu Nov 28 05:06: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 FAA24321 for ; Thu, 28 Nov 2002 05:06: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 gASA70N4012165; Thu, 28 Nov 2002 05:07: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 FAA12965; Thu, 28 Nov 2002 05:08:07 -0500 (EST) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12954 for ; Thu, 28 Nov 2002 05:07:47 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gASA7cAL060304 for ; Thu, 28 Nov 2002 11:07:44 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gASA7TFt098236 for ; Thu, 28 Nov 2002 11:07:31 +0100 To: simple@mailman.dynamicsoft.com Subject: Re: [Simple] any SIP progress in devices? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 28/11/2002 12:07:30, Serialize complete at 28/11/2002 12:07:30 Content-Type: multipart/alternative; boundary="=_alternative 003796A4C2256C7F_=" 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 Nov 2002 12:07:21 +0200 This is a multipart message in MIME format. --=_alternative 003796A4C2256C7F_= Content-Type: text/plain; charset="US-ASCII" Tang Li Hua wrote: > I'd like to know how about SIP work on sessions involving in multiple > devices and server resources. My interesting points includes how to > exchange the events among devices, how to control Prompt Players, Text to > Speech, and Speech Recognition Engines. Following information sent by Henry Sinnreich may be of interest: Avshalom Houri Lotus Sametime, IBM ------------------------------------------------------- As discussed during the IETF, here is the I-D on SIP Telephony Device Requirements, Configuration and Data This informational I-D describes the requirements for SIP Telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations. The document reviews the generic requirements for SIP telephony devices, the automatic device configuration process, the device configuration data and examples for XML configuration data formats. The I-D will be published in the IETF archive and can also be found at http://www.sipforum.org/ietfdrafts/draft-somefolks-sipdevices-req-00.txt Send an email to sipdevices-request@sipforum.org with the word "subscribe" in the body to subscribe to the list or use this link. After you have subscribe to the SIP Forum Devices Work Group mailing list, you can access the SIP Devices WG email archives by visiting http://www.freelists.org/archives/sipdevices/. The authors would really appeciate your comments. Please feel free to share with anyone interested in the company. --=_alternative 003796A4C2256C7F_= Content-Type: text/html; charset="US-ASCII"
Tang Li Hua wrote:

> I'd like to know how about SIP work on sessions involving in multiple
> devices and server resources. My interesting points includes how to
> exchange the events among devices, how to control Prompt Players, Text to
> Speech, and Speech Recognition Engines.

Following information sent by Henry Sinnreich <Henry.Sinnreich@wcom.com> may be of interest:

Avshalom Houri
Lotus Sametime, IBM

-------------------------------------------------------

As discussed during the IETF, here is the I-D on

SIP Telephony Device Requirements, Configuration and Data

  This informational I-D describes the requirements for SIP Telephony
  devices, based on the deployment experience of large numbers of SIP
  phones and PC clients using different implementations. The document
  reviews the generic requirements for SIP telephony devices, the
  automatic device configuration process, the device configuration data

  and examples for XML configuration data formats.

The I-D will be published in the IETF archive and can also be found at

http://www.sipforum.org/ietfdrafts/draft-somefolks-sipdevices-req-00.txt

Send an email to sipdevices-request@sipforum.org with the word
"subscribe" in the body to subscribe to the list or use this link.

After you have subscribe to the SIP Forum Devices Work Group mailing
list, you can access the SIP Devices WG email archives by visiting
http://www.freelists.org/archives/sipdevices/.

The authors would really appeciate your comments. Please feel free to
share with anyone interested in the company.


 --=_alternative 003796A4C2256C7F_=-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple