From simple-bounces@ietf.org Tue Jan 02 10:00:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1l6u-0008Rj-QA; Tue, 02 Jan 2007 09:59:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1l6s-0008JA-K2; Tue, 02 Jan 2007 09:59:26 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1l6q-0007sQ-JC; Tue, 02 Jan 2007 09:59:26 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmc459ad63d; Tue, 02 Jan 2007 23:09:05 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm144595cb39; Sat, 30 Dec 2006 05:08:44 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 30 Dec 2006 05:08:44 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Og4-0004Rn-NW; Fri, 29 Dec 2006 15:50:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Ofz-0004Qf-Kg; Fri, 29 Dec 2006 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Ofy-0005kG-BX; Fri, 29 Dec 2006 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5101E328DC; Fri, 29 Dec 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H0Ofy-0000el-7N; Fri, 29 Dec 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 29 Dec 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-10.txt X-BeenThere: simple@ietf.org Reply-To: internet-drafts@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Relay Extensions for the Message Sessions Relay Protocol (MSRP) Author(s) : C. Jennings, et al. Filename : draft-ietf-simple-msrp-relays-10.txt Pages : 37 Date : 2006-12-29 Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a SIP (Session Initiation Protocol) session, whereas Session-mode messages are set up as part of a session using the SIP protocol. MSRP (Message Session Relay Protocol) is a protocol for near real-time, peer-to- peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-relays-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-msrp-relays-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-msrp-relays-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-29102603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-msrp-relays-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-msrp-relays-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-29102603.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Jan 10 06:16:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bRL-0004IG-CR; Wed, 10 Jan 2007 06:16:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bRK-0004IB-Cb for simple@ietf.org; Wed, 10 Jan 2007 06:16:18 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4bRI-0005OC-Vc for simple@ietf.org; Wed, 10 Jan 2007 06:16:18 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0ABGGdO157596 for ; Wed, 10 Jan 2007 11:16:16 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l0ABGFMT3092690 for ; Wed, 10 Jan 2007 12:16:15 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0ABGF1e012237 for ; Wed, 10 Jan 2007 12:16:15 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0ABGF9U012234 for ; Wed, 10 Jan 2007 12:16:15 +0100 To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Wed, 10 Jan 2007 13:16:14 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF882 | September 26, 2006) at 10/01/2007 13:16:15, Serialize complete at 10/01/2007 13:16:15 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Simple] Errors on older notifications X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0340012256==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0340012256== Content-Type: multipart/alternative; boundary="=_alternative 003DDDB8C225725F_=" This is a multipart message in MIME format. --=_alternative 003DDDB8C225725F_= Content-Type: text/plain; charset="US-ASCII" When a subscriber gets a NOTIFY with a lower CSEQ, can it return an error and still keep the subscription? Should it return 200 OK? Could not find the answer in 3265 or 3856. Thanks --Avshalom --=_alternative 003DDDB8C225725F_= Content-Type: text/html; charset="US-ASCII"
When a subscriber gets a NOTIFY with a lower CSEQ, can it return an error
and still keep the subscription?

Should it return 200 OK?

Could not find the answer in 3265 or 3856.

Thanks
--Avshalom
 --=_alternative 003DDDB8C225725F_=-- --===============0340012256== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0340012256==-- From simple-bounces@ietf.org Wed Jan 10 08:35:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4dae-0004ku-Ao; Wed, 10 Jan 2007 08:34:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4dac-0004kj-UG for simple@ietf.org; Wed, 10 Jan 2007 08:34:02 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4daV-0000Tv-2M for simple@ietf.org; Wed, 10 Jan 2007 08:34:02 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0ADXifn010431; Wed, 10 Jan 2007 07:33:50 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 07:33:44 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 14:33:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Errors on older notifications Date: Wed, 10 Jan 2007 14:33:34 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180AB0819@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Errors on older notifications thread-index: Acc0qOMJr/o4uIFJTfeQJo0a+C7OUgAEndAg From: "Drage, Keith \(Keith\)" To: "Avshalom Houri" , X-OriginalArrivalTime: 10 Jan 2007 13:33:35.0649 (UTC) FILETIME=[EDCCA910:01C734BB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Surely RFC 3261 applies (12.2.2): If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a 500 (Server Internal Error) response. RFC 3265 does not appear to change this behaviour. 500 (Server Internal Error) responses do not kill the dialog, only the transaction - see http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-05.tx t. Regards Keith ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: 10 January 2007 11:16 To: simple@ietf.org Subject: [Simple] Errors on older notifications =09 =09 When a subscriber gets a NOTIFY with a lower CSEQ, can it return an error=20 and still keep the subscription?=20 =09 Should it return 200 OK?=20 =09 Could not find the answer in 3265 or 3856.=20 =09 Thanks=20 --Avshalom =09 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 10 08:45:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4dkz-0001Tj-Id; Wed, 10 Jan 2007 08:44:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4dky-0001Te-EY for simple@ietf.org; Wed, 10 Jan 2007 08:44:44 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4dkg-0002AL-Au for simple@ietf.org; Wed, 10 Jan 2007 08:44:44 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0ADiO6v035890 for ; Wed, 10 Jan 2007 13:44:25 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l0ADiNYh2490454 for ; Wed, 10 Jan 2007 14:44:23 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0ADiMRr027635 for ; Wed, 10 Jan 2007 14:44:23 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0ADiMPY027628 for ; Wed, 10 Jan 2007 14:44:22 +0100 In-Reply-To: <5D1A7985295922448D5550C94DE29180AB0819@DEEXC1U01.de.lucent.com> To: "Drage, Keith \(Keith\)" Subject: RE: [Simple] Errors on older notifications MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Wed, 10 Jan 2007 15:44:20 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF882 | September 26, 2006) at 10/01/2007 15:44:22, Serialize complete at 10/01/2007 15:44:22 X-Spam-Score: 0.1 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0420854349==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0420854349== Content-Type: multipart/alternative; boundary="=_alternative 004B90FAC225725F_=" This is a multipart message in MIME format. --=_alternative 004B90FAC225725F_= Content-Type: text/plain; charset="US-ASCII" On the other hand the following text from RFC 3265 may say the opposite (found it after I have sent the email): RFC 3265 Section 3.2.2: If the NOTIFY request fails (as defined above) due to an error response, and the subscription was installed using a soft-state mechanism, the notifier MUST remove the corresponding subscription. This seems to contradict RFC 3261 and the dialousage draft. Regards --Avshalom "Drage, Keith \(Keith\)" 10/01/2007 15:33 To Avshalom Houri/Haifa/IBM@IBMIL, cc Subject RE: [Simple] Errors on older notifications Surely RFC 3261 applies (12.2.2): If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a 500 (Server Internal Error) response. RFC 3265 does not appear to change this behaviour. 500 (Server Internal Error) responses do not kill the dialog, only the transaction - see http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-05.tx t. Regards Keith ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] Sent: 10 January 2007 11:16 To: simple@ietf.org Subject: [Simple] Errors on older notifications When a subscriber gets a NOTIFY with a lower CSEQ, can it return an error and still keep the subscription? Should it return 200 OK? Could not find the answer in 3265 or 3856. Thanks --Avshalom _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=_alternative 004B90FAC225725F_= Content-Type: text/html; charset="US-ASCII"
On the other hand the following text from RFC 3265 may say the opposite
(found it after I have sent the email):

RFC 3265 Section 3.2.2:
 If the NOTIFY request fails (as defined above) due to an error
   response, and the subscription was installed using a soft-state
   mechanism, the notifier MUST remove the corresponding subscription.

This seems to contradict RFC 3261 and the dialousage draft.

Regards
--Avshalom


"Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>

10/01/2007 15:33

To
Avshalom Houri/Haifa/IBM@IBMIL, <simple@ietf.org>
cc
Subject
RE: [Simple] Errors on older notifications





Surely RFC 3261 applies (12.2.2):

  If the remote sequence number was not empty, but the sequence number
  of the request is lower than the remote sequence number, the request
  is out of order and MUST be rejected with a 500 (Server Internal
  Error) response.

RFC 3265 does not appear to change this behaviour.

500 (Server Internal Error) responses do not kill the dialog, only the
transaction - see
http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-05.tx
t.

Regards

Keith


________________________________

                From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
                Sent: 10 January 2007 11:16
                To: simple@ietf.org
                Subject: [Simple] Errors on older notifications
               
               

                When a subscriber gets a NOTIFY with a lower CSEQ, can it return
an error
                and still keep the subscription?
               
                Should it return 200 OK?
               
                Could not find the answer in 3265 or 3856.
               
                Thanks
                --Avshalom
               


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--=_alternative 004B90FAC225725F_=-- --===============0420854349== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0420854349==-- From simple-bounces@ietf.org Wed Jan 10 11:18:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4g98-0008Sw-ES; Wed, 10 Jan 2007 11:17:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4g96-0008Sg-7h for simple@ietf.org; Wed, 10 Jan 2007 11:17:48 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4g93-0006Op-Sw for simple@ietf.org; Wed, 10 Jan 2007 11:17:48 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Jan 2007 08:17:46 -0800 X-IronPort-AV: i="4.13,168,1167638400"; d="scan'208"; a="50459067:sNHT51163072" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0AGHjge032063; Wed, 10 Jan 2007 11:17:45 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0AGHj7f015407; Wed, 10 Jan 2007 11:17:45 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 11:17:44 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 11:17:44 -0500 Message-ID: <45A511A7.7000303@cisco.com> Date: Wed, 10 Jan 2007 11:17:43 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Avshalom Houri Subject: Re: [Simple] Errors on older notifications References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2007 16:17:44.0394 (UTC) FILETIME=[DC1BE2A0:01C734D2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2910; t=1168445865; x=1169309865; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20Errors=20on=20older=20notifications |Sender:=20 |To:=20Avshalom=20Houri=20; bh=3nEqw9r8Eaq+KQGbkhxKkWqyvMosLUQ/+6Np6FVXVXo=; b=vPPiobpyPmyXartjssZ4oSwBjfOHSwg2YbkIM4Dp9+eYaGUC3AJ32DTTzBAThaikWQKR2FJ8 iEhEHT7j8PvPC/f924FOyH0dJ4Tf9wJ3RZHpdHV0BVHjYbdpMjESv7+s; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Adam Roach , "Drage, Keith \(Keith\)" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Avshalom Houri wrote: > > On the other hand the following text from RFC 3265 may say the opposite > (found it after I have sent the email): > > RFC 3265 Section 3.2.2: > If the NOTIFY request fails (as defined above) due to an error > response, and the subscription was installed using a soft-state > mechanism, the notifier MUST remove the corresponding subscription. > > This seems to contradict RFC 3261 and the dialousage draft. I agree that there seems to be a conflict here. However the accompanying text in 3265 explains the rationale, and I believe based on that the dialogusage approach should take precedence, at least in some cases. In particular, if the notifier has sent a NOTIFY before receiving a response to a previous NOTIFY, then this error can occur without implying any serious problem. However this could probably stand to have some further discussion. Perhaps Adam (author of 3265) will provide an opinion. Paul > Regards > --Avshalom > > > > > > *"Drage, Keith \(Keith\)" * > > 10/01/2007 15:33 > > > To > Avshalom Houri/Haifa/IBM@IBMIL, > cc > > Subject > RE: [Simple] Errors on older notifications > > > > > > > > > Surely RFC 3261 applies (12.2.2): > > If the remote sequence number was not empty, but the sequence number > of the request is lower than the remote sequence number, the request > is out of order and MUST be rejected with a 500 (Server Internal > Error) response. > > RFC 3265 does not appear to change this behaviour. > > 500 (Server Internal Error) responses do not kill the dialog, only the > transaction - see > http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-05.tx > t. > > Regards > > Keith > > > ________________________________ > > From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] > Sent: 10 January 2007 11:16 > To: simple@ietf.org > Subject: [Simple] Errors on older notifications > > > > When a subscriber gets a NOTIFY with a lower CSEQ, can > it return > an error > and still keep the subscription? > > Should it return 200 OK? > > Could not find the answer in 3265 or 3856. > > Thanks > --Avshalom > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jan 12 00:58:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5FQC-0001JZ-WD; Fri, 12 Jan 2007 00:57:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5FQB-0001IA-8i for simple@ietf.org; Fri, 12 Jan 2007 00:57:47 -0500 Received: from web7805.mail.in.yahoo.com ([202.86.4.62]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5FQ8-0008AY-CN for simple@ietf.org; Fri, 12 Jan 2007 00:57:47 -0500 Received: (qmail 99648 invoked by uid 60001); 12 Jan 2007 05:57:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=sskJMzppS9tTcDBR1SEw0CBsQwwDXkyXPZiBWVpJCE/mw61P1fojVnQS7fCa/ajeJAzR2sR38xLCHTVqVKtUtlkTznaGMKQwGjxNIB+60ZqlbJP7t+6rPIFV/ZuOEeDtu8n/4sOFYBqReLopIxIwqRhB07JH1sMFky6snSpbUPE=; X-YMail-OSG: mTGUVHEVM1kMOx_jjJuRow_CjUOvxnUNfxGQOrrF_AqJCZXbFwC6A4bXkYLIjoL_UaULmVlC2of.6Ya.hc3OhnBBDzHftfwTC7ko3rF9B1eqCFRTgLBS719cmQaQOEKX2bvwrRhYRj_2qvRSOlfLfo.vZ1bBjlYNhBGxmXJhHppgIw-- Received: from [202.144.104.245] by web7805.mail.in.yahoo.com via HTTP; Fri, 12 Jan 2007 05:57:41 GMT Date: Fri, 12 Jan 2007 05:57:41 +0000 (GMT) From: Allen Allen To: simple@ietf.org MIME-Version: 1.0 Message-ID: <438959.98068.qm@web7805.mail.in.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Simple] Hi iam allen X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0892587767==" Errors-To: simple-bounces@ietf.org --===============0892587767== Content-Type: multipart/alternative; boundary="0-1866274881-1168581461=:98068" Content-Transfer-Encoding: 8bit --0-1866274881-1168581461=:98068 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi everybody, iam new to this list. WORKING in SIMPLE. This is my first query: i can find call flow like invite, 200 ok... in many doc. it contains complete flow. can u guys tell me any document or website is there to say complete presence signalling flow. i seen some 3gpp document, in that they are not showing authorization policy changes, list changes, etc. or can any one give me complete signalling flow for add contact(when ue1 tries to add ue2) with xcap interface too. for that i think ue1 sends subscribe to presence server, presence server sends notify(winfo) to ue2. ue2 comes to know ue1 is pending. then ue2 needs to change authpolicy(i dont know how it will do(i gues through xcap)). then presence server sends notify to ue1 as per change in auth policy. one more query: if the flow is like this , how presence server knows ue2 changed his auth policy or not. is it is must for client(UE) to have xcap client ? Thanks in advance Regards Allen --------------------------------- Here’s a new way to find what you're looking for - Yahoo! Answers --0-1866274881-1168581461=:98068 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi everybody,
iam new to this list. WORKING in SIMPLE.
This is my first query:
i can find call flow like invite, 200 ok... in many doc. it contains complete flow. can u guys tell me any document or website is there to say complete presence signalling flow. i seen some 3gpp document, in that they are not showing authorization policy changes, list changes, etc.
or can any one give me complete signalling flow for add contact(when ue1 tries to add ue2) with xcap interface too. for that i think ue1 sends subscribe to presence server, presence server sends notify(winfo) to ue2. ue2 comes to know ue1 is pending. then ue2 needs to change authpolicy(i dont know how it will do(i gues through xcap)). then presence server sends notify to ue1 as per change in auth policy.
one more query: if the flow is like this , how presence server knows ue2 changed his auth policy or not.
is it is must for client(UE) to have xcap client ?
 
 
Thanks in advance
Regards
Allen
 

Here’s a new way to find what you're looking for - Yahoo! Answers --0-1866274881-1168581461=:98068-- --===============0892587767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0892587767==-- From simple-bounces@ietf.org Fri Jan 12 11:38:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5PPe-00041m-N8; Fri, 12 Jan 2007 11:37:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5PPd-00041h-5Z for simple@ietf.org; Fri, 12 Jan 2007 11:37:53 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5PPa-00054p-K0 for simple@ietf.org; Fri, 12 Jan 2007 11:37:53 -0500 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l0CGbeTs004447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Jan 2007 10:37:41 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <3FD3DB4C-725D-4F10-B291-197E6D3C3CB8@nostrum.com> From: Robert Sparks Subject: Re: [Simple] Errors on older notifications Date: Fri, 12 Jan 2007 10:37:39 -0600 To: Avshalom Houri X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.3 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: "Drage, Keith \(Keith\)" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1083481806==" Errors-To: simple-bounces@ietf.org --===============1083481806== Content-Type: multipart/alternative; boundary=Apple-Mail-1--813385355 --Apple-Mail-1--813385355 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed So I believe dialog-usage says what we want and that this points to another clarification to 3265 and possibly to the event packages. The effect of overlapping transactions were ill-defined when we did 3265 (remember the arguments we had in SIMPLE about disallowing them for Event: presence, and a little further back the arguments in SIP about disallowing them in a dialog period) - there are things we learned since then that we need to capture. RjS On Jan 10, 2007, at 7:44 AM, Avshalom Houri wrote: > > On the other hand the following text from RFC 3265 may say the > opposite > (found it after I have sent the email): > > RFC 3265 Section 3.2.2: > If the NOTIFY request fails (as defined above) due to an error > response, and the subscription was installed using a soft-state > mechanism, the notifier MUST remove the corresponding subscription. > > This seems to contradict RFC 3261 and the dialousage draft. > > Regards > --Avshalom > > > > > > "Drage, Keith \(Keith\)" > 10/01/2007 15:33 > > To > Avshalom Houri/Haifa/IBM@IBMIL, > cc > Subject > RE: [Simple] Errors on older notifications > > > > > > Surely RFC 3261 applies (12.2.2): > > If the remote sequence number was not empty, but the sequence number > of the request is lower than the remote sequence number, the request > is out of order and MUST be rejected with a 500 (Server Internal > Error) response. > > RFC 3265 does not appear to change this behaviour. > > 500 (Server Internal Error) responses do not kill the dialog, only the > transaction - see > http://www.ietf.org/internet-drafts/draft-ietf-sipping- > dialogusage-05.tx > t. > > Regards > > Keith > > > ________________________________ > > From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] > Sent: 10 January 2007 11:16 > To: simple@ietf.org > Subject: [Simple] Errors on older notifications > > > > When a subscriber gets a NOTIFY with a lower CSEQ, > can it return > an error > and still keep the subscription? > > Should it return 200 OK? > > Could not find the answer in 3265 or 3856. > > Thanks > --Avshalom > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple --Apple-Mail-1--813385355 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 So I believe dialog-usage says = what we want and that this points to another clarification to 3265 and = possibly to the event packages.

The effect of overlapping = transactions were ill-defined when we did 3265 (remember the arguments = we had in SIMPLE about disallowing
them for Event: presence, = and a little further back the arguments in SIP about disallowing them in = a dialog period) - there are things we=A0
learned since then = that we need to capture.

RjS

On Jan 10, 2007, at = 7:44 AM, Avshalom Houri wrote:


On the other hand the following text = from RFC 3265 may say the opposite
(found it after I have sent the email):
=
RFC 3265 Section 3.2.2: =
=A0If the NOTIFY request fails = (as defined above) due to an error
=A0 =A0response, and the subscription was installed = using a soft-state
=A0 = =A0mechanism, the notifier MUST remove the corresponding = subscription.

This = seems to contradict RFC 3261 and the dialousage draft.
=
Regards
--Avshalom


"Drage, Keith \(Keith\)" <drage@alcatel-lucent.com><= /B>

10/01/2007 = 15:33

=
To
Avshalom Houri/Haifa/IBM@IBMIL, <simple@ietf.org> =
cc
Subject
RE: [Simple] Errors on older = notifications

=



Surely = RFC 3261 applies (12.2.2):

=A0 If the remote sequence number = was not empty, but the sequence number
=A0 of the request is lower = than the remote sequence number, the request
=A0 is out of order and = MUST be rejected with a 500 (Server Internal
=A0 Error) = response.

RFC 3265 does not appear to change this = behaviour.

500 (Server Internal Error) responses do not kill = the dialog, only the
transaction - see
http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage= -05.tx
t.

Regards

Keith


= ________________________________

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sent: 10 January 2007 11:16
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 To: simple@ietf.org
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Subject: [Simple] Errors on older notifications
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 When a subscriber gets a NOTIFY = with a lower CSEQ, can it return
an error
=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 and still keep the subscription?
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Should it return 200 OK?
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = Could not find the answer in 3265 or 3856.
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 --Avshalom
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0

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

= --Apple-Mail-1--813385355-- --===============1083481806== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1083481806==-- From simple-bounces@ietf.org Sat Jan 13 14:49:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5os0-00058W-Ha; Sat, 13 Jan 2007 14:48:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5ory-00056O-IR for simple@ietf.org; Sat, 13 Jan 2007 14:48:50 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5orx-0004uU-8m for simple@ietf.org; Sat, 13 Jan 2007 14:48:50 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 13 Jan 2007 11:48:48 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0DJmmjo019279 for ; Sat, 13 Jan 2007 11:48:48 -0800 Received: from [192.168.1.5] (sjc-vpn2-444.cisco.com [10.21.113.188]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0DJl9hr018475 for ; Sat, 13 Jan 2007 11:48:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: simple@ietf.org From: Cullen Jennings Date: Sat, 13 Jan 2007 11:48:44 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=444; t=1168717728; x=1169581728; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20New=20RAI=20mailing=20list=20formed=20=20 |Sender:=20; bh=5f8EvdfGiOmFIoCw5HV0P0Q9jbcKK05G7vueJlh3cUA=; b=WiSt4cEsoHOnz7lE6Z62htNPhuSdH35VsB4K6ryUVNV8iiIw5MCuGeWkGEiJ9O9mEtKBr3EZ d1uq+KDnfz1g+6FkbzHi26DMgIQYbrWsydPZiYKiJDi8kSx0wrhnL1VZ; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Simple] New RAI mailing list formed X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Sorry for the many duplicate posts. A new mailing list for announcement and discussion of general topics of interest to RAI Area has been created. The list is rai@ietf.org You can subscribe at: https://www1.ietf.org/mailman/listinfo/rai Or by sending email with a body containing "subscribe" to rai- request@ietf.org Please do subscribe to it so you can find announcements for things like RAI BOFs. Thanks, Cullen & Jon _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 14 07:42:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H64fa-0003Bb-0X; Sun, 14 Jan 2007 07:41:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H64fY-0003Ax-I7 for simple@ietf.org; Sun, 14 Jan 2007 07:41:04 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H64fV-000377-OO for simple@ietf.org; Sun, 14 Jan 2007 07:41:04 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0ECexec050430 for ; Sun, 14 Jan 2007 12:40:59 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0ECex3r2232436 for ; Sun, 14 Jan 2007 13:40:59 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0ECexiS021059 for ; Sun, 14 Jan 2007 13:40:59 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0ECexw4021056; Sun, 14 Jan 2007 13:40:59 +0100 In-Reply-To: <3FD3DB4C-725D-4F10-B291-197E6D3C3CB8@nostrum.com> To: Robert Sparks Subject: Re: [Simple] Errors on older notifications MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Sun, 14 Jan 2007 14:40:57 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF882 | September 26, 2006) at 14/01/2007 14:40:58, Serialize complete at 14/01/2007 14:40:58 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: "Drage, Keith \(Keith\)" , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0176167142==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0176167142== Content-Type: multipart/alternative; boundary="=_alternative 0045C530C2257263_=" This is a multipart message in MIME format. --=_alternative 0045C530C2257263_= Content-Type: text/plain; charset="US-ASCII" Time for 3265-bis? In addition to that overlapping transactions etc. it can include also some optimizations as etags. --Avshalom Robert Sparks 12/01/2007 18:37 To Avshalom Houri/Haifa/IBM@IBMIL cc "Drage, Keith \(Keith\)" , simple@ietf.org Subject Re: [Simple] Errors on older notifications So I believe dialog-usage says what we want and that this points to another clarification to 3265 and possibly to the event packages. The effect of overlapping transactions were ill-defined when we did 3265 (remember the arguments we had in SIMPLE about disallowing them for Event: presence, and a little further back the arguments in SIP about disallowing them in a dialog period) - there are things we learned since then that we need to capture. RjS On Jan 10, 2007, at 7:44 AM, Avshalom Houri wrote: On the other hand the following text from RFC 3265 may say the opposite (found it after I have sent the email): RFC 3265 Section 3.2.2: If the NOTIFY request fails (as defined above) due to an error response, and the subscription was installed using a soft-state mechanism, the notifier MUST remove the corresponding subscription. This seems to contradict RFC 3261 and the dialousage draft. Regards --Avshalom "Drage, Keith \(Keith\)" 10/01/2007 15:33 To Avshalom Houri/Haifa/IBM@IBMIL, cc Subject RE: [Simple] Errors on older notifications Surely RFC 3261 applies (12.2.2): If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a 500 (Server Internal Error) response. RFC 3265 does not appear to change this behaviour. 500 (Server Internal Error) responses do not kill the dialog, only the transaction - see http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-05.tx t. Regards Keith ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] Sent: 10 January 2007 11:16 To: simple@ietf.org Subject: [Simple] Errors on older notifications When a subscriber gets a NOTIFY with a lower CSEQ, can it return an error and still keep the subscription? Should it return 200 OK? Could not find the answer in 3265 or 3856. Thanks --Avshalom _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=_alternative 0045C530C2257263_= Content-Type: text/html; charset="US-ASCII"
Time for 3265-bis?
In addition to that overlapping transactions etc. it can include also some optimizations as etags.

--Avshalom


Robert Sparks <rjsparks@nostrum.com>

12/01/2007 18:37

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
"Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>, simple@ietf.org
Subject
Re: [Simple] Errors on older notifications





So I believe dialog-usage says what we want and that this points to another clarification to 3265 and possibly to the event packages.

The effect of overlapping transactions were ill-defined when we did 3265 (remember the arguments we had in SIMPLE about disallowing
them for Event: presence, and a little further back the arguments in SIP about disallowing them in a dialog period) - there are things we 
learned since then that we need to capture.

RjS

On Jan 10, 2007, at 7:44 AM, Avshalom Houri wrote:


On the other hand the following text from RFC 3265 may say the opposite
(found it after I have sent the email):

RFC 3265 Section 3.2.2:
 If the NOTIFY request fails (as defined above) due to an error
   response, and the subscription was installed using a soft-state
   mechanism, the notifier MUST remove the corresponding subscription.

This seems to contradict RFC 3261 and the dialousage draft.

Regards
--Avshalom
"Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>

10/01/2007 15:33


To
Avshalom Houri/Haifa/IBM@IBMIL, <simple@ietf.org>
cc
Subject
RE: [Simple] Errors on older notifications







Surely RFC 3261 applies (12.2.2):

  If the remote sequence number was not empty, but the sequence number
  of the request is lower than the remote sequence number, the request
  is out of order and MUST be rejected with a 500 (Server Internal
  Error) response.

RFC 3265 does not appear to change this behaviour.

500 (Server Internal Error) responses do not kill the dialog, only the
transaction - see
http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-05.tx
t.

Regards

Keith


________________________________

                From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
                Sent: 10 January 2007 11:16
                To: simple@ietf.org
                Subject: [Simple] Errors on older notifications
               
               

                When a subscriber gets a NOTIFY with a lower CSEQ, can it return
an error
                and still keep the subscription?
               
                Should it return 200 OK?
               
                Could not find the answer in 3265 or 3856.
               
                Thanks
                --Avshalom
               


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--=_alternative 0045C530C2257263_=-- --===============0176167142== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0176167142==-- From simple-bounces@ietf.org Fri Jan 19 11:46:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7wsA-0005Nt-CE; Fri, 19 Jan 2007 11:45:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ws8-0005Nf-EV for simple@ietf.org; Fri, 19 Jan 2007 11:45:48 -0500 Received: from extmail13.cingular.com ([170.35.225.28] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ws6-0001YI-Tk for simple@ietf.org; Fri, 19 Jan 2007 11:45:48 -0500 Received: from ([10.148.14.27]) by extmail13.cingular.com with ESMTP id KP-TRRF8.98083063; Fri, 19 Jan 2007 11:45:19 -0500 Received: from TBDCEXCH10.US.Cingular.Net ([10.148.14.47]) by TD02XSMTP005.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 10:45:19 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Simple] New Draft: Deferred Messaging Disposition Notification Date: Fri, 19 Jan 2007 10:45:17 -0600 Message-ID: <451C9AB8BFB6B64EA11547A3D966DB3609808940@TBDCEXCH10.US.Cingular.Net> In-Reply-To: <66cd252f0612180807w368ca5f6n257fa2020dfa3908@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] New Draft: Deferred Messaging Disposition Notification Thread-Index: AccivrzyD0uDK4agSi2n0Jz4+p42YQZI/3SQ To: X-OriginalArrivalTime: 19 Jan 2007 16:45:19.0401 (UTC) FILETIME=[3449A990:01C73BE9] From: "Stafford, Matthew" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: "Wuthnow, Mark" , "Shih, Jerry" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org We had some discussion about a month ago re: pulling MSRP out of the IMDN draft. Thanks to Ben, Miguel and Hisham for their responses. I'd say the upshot of that discussion was twofold: the "slimmed-down" IMDN draft needs to go ahead, and any push to expand IMDN's applicability needs to start with clear documentation of requirements. Jointly with two colleagues at Cingular/AT&T, I have submitted an I-D to address the latter point. It is now posted at=20 http://www.ietf.org/internet-drafts/draft-stafford-simple-dmdn-00.txt This draft is intended to start the ball rolling by presenting use cases. It makes a straw proposal that IMDN usage be extended to MSRP. (I do understand that there may be other, better ways to meet the requirements- but this draft still seems to be a reasonable starting point.) Best, Matt -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]=20 Sent: Monday, December 18, 2006 10:08 AM To: Stafford, Matthew Cc: Ben Campbell; simple@ietf.org Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt Matthew, I appreciate the requirements you are putting forward for IMDNs for session mode messaging. It was agreed in the last IETF meeting that this will be for further study and will be kep out of the current IMDN draft, limiting its scope to page mode IMs. You have valid use cases for large messages to use MSRP (although the user doesnt know it is in fact a session) plus the store and forward IM session (which doesnt make much sense). In any case, you will need to bring forward those requirements in an internet draft form and we can discuss those requirements on the mailing list. You are also free to present them in the next IETF meeting. Once the requirements are clear, we can start working on the solution. One solution I can think of for your large message read report problem is that you can send a page mode IMDN referring to the message ID of the session, or embedding the session id and message id into the Message-ID header. This probably also works fine for store and forward.. The point I'm trying to make is that it is not as easy as just saying "this also applies to session mode". Requirements and solutions need to be studied. Thanks, Hisham On 18/12/06, Stafford, Matthew wrote: > Thanks for your response. Inline. > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Thursday, December 14, 2006 11:34 PM > To: Stafford, Matthew > Cc: Robert Sparks; simple@ietf.org > Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt > > > On Dec 14, 2006, at 9:40 PM, Stafford, Matthew wrote: > > > I'd like to raise an issue regarding the statement that "IMDN is not > > generally applicable to MSRP". IMHO IMDN's usefulness in the > > context of > > SIP MESSAGE will be compromised if it cannot also be applied to MSRP. > > > > Perhaps a better wording in the draft is "We have not fully explored > the use cases for MSRP, so they are out of scope for this document. > They may be addressed in a separate work." > > I think the real point of removing MSRP from the document was not to > say that we know categorically that there are no valid uses with > MSRP. Rather, it was that such uses were not entirely clear, and if > they are needed they require further exploration. We did not want to > block progression of the spec on how to do IMDN with page mode until > we completely understood how to do it with MSRP. > > > > I take the point that, when two subscribers are participating in an > > ongoing session, it's odd to talk about IMDN concepts such as read > > receipt. > > > > However, "one-and-done" messages can easily exceed the 1300-byte limit > > for SIP MESSAGE over UDP, especially when request-contained > > distribution > > lists and/or multimedia attachments come into play. CPIM headers will > > further reduce "headroom". > > > > To address this limitation, OMA's SIMPLE IM working group has > > identified > > "large message mode" (in addition to page mode and session mode). In > > large message mode, an MSRP session is set up to transfer a one-time > > message that is bigger than 1300 bytes. But the subscriber is > > blissfully > > unaware of the difference between page mode and large message mode- > > nothing at the UI layer reflects that there is an underlying > > session in > > the latter case. The UI just presents a "unified composer" to the > > subscriber. If the UI allows the subscriber to request read > > receipts for > > small messages but not for big ones, I think the subscriber will be > > baffled. Consider, for example, a case in which the subscriber > > composes > > a text message and checks the "request read receipt" box. Then, on the > > fly, he/she decides to add an attachment before sending the message. > > It's really awkward to step in at that point and say no, sorry- you > > can > > have one or the other but not both. > > > > In such a case, the user request for a receipt would be satisfied by > the MSRP report mechanism, wouldn't it? That is, if the client is > smart enough to switch to using MSRP rather than page mode, it would > also be smart enough to request a delivery confirmation using the > mechanism already in MSRP? > > <<< OK in this use case for _delivery_ notification (but see below), but > what about _read_ notification? >>> > > Now, if the use case you describe is one where the IMDN needs to be > delivered after the MSRP session is completed (for example, the large > message gets sent to a store and forward server), then we have a > _very_ good example of something that needs more exploration before > we try to specify how to do it. > > <<< I think we do have such an example: OMA defines a deferred messaging > function in which the IM server stores messages for later delivery in > the case that an intended recipient is unavailable. So I think you've > put your finger squarely on an OMA use case. >>> > > > In summary, I think OMA's taxonomy of messaging modes is very natural- > > from the POV of supporting use cases that will make sense to the > > average > > subscriber. IMDN consistency across page and large message modes seems > > equally natural to me. > > > > Best, > > Matt Stafford > > Cingular Wireless > > > > -----Original Message----- > > From: Robert Sparks [mailto:rjsparks@nostrum.com] > > Sent: Monday, December 11, 2006 10:22 AM > > To: simple@ietf.org > > Cc: simple-ads@tools.ietf.org > > Subject: [Simple] WGLC: draft-ietf-simple-imdn-02.txt > > > > This is a SIMPLE WGLC for > > http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-02.txt > > > > Please have your comments to the list by December 25 (more on this > > timing below) > > > > Please send your comments to the list and copy Hisham and Eric. > > Given the timing, it is especially important for you to respond if > > you think the draft is ready to go with no changes. > > > > IF YOU HAVE A COMMENT TO MAKE BUT DON"T FEEL THIS IS ENOUGH TIME, > > send email to the chairs right away. We'll extend this if there's any > > felt need. > > > > Why the timing? : > > First off, I was slow in issuing the last call - that should have > > happened at the beginning of the month. > > Hisham (who has the pen right now) has some travel across the new > > year where he will be less responsive > > than usual. Our take is that this draft has little to no > > controversy left and has undergone a lot of scrutiny. > > If the LC feedback from the group shows it is ready to go, Hisham > > can make any needed minor edits before > > he drops offline and we can start into the request for > > publication process. If the feedback shows more time in > > LC is needed, we'll adjust, moving closure into the new year. In > > order to gauge this, it is very important that you > > respond even if you have no changes to suggest. > > > > If you are not planning to review/comment on this draft, please let > > me know. > > > > RjS > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 22 12:04:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92aU-0000bl-72; Mon, 22 Jan 2007 12:04:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92aS-0000bX-UX for simple@ietf.org; Mon, 22 Jan 2007 12:04:04 -0500 Received: from hu-out-0506.google.com ([72.14.214.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H92aR-0003aD-IH for simple@ietf.org; Mon, 22 Jan 2007 12:04:04 -0500 Received: by hu-out-0506.google.com with SMTP id 38so24612huc for ; Mon, 22 Jan 2007 09:04:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=D1jKy00T6P32g9UK1JNP5LrBQOJknL3aVu9sGHtVxjsswmBvZGjmPGdlvRpV8fjmwR3/3fKUBP3cwsSCoagnoh+WixEC2KClF/WLpreiA4sR+8BeehgpJ7axM47Hbl60FdFBrlxuaBweT9cYpCOLy4krNotKrAOM9Hl+wFKiGDc= Received: by 10.82.182.8 with SMTP id e8mr5345158buf.1169485380740; Mon, 22 Jan 2007 09:03:00 -0800 (PST) Received: by 10.82.168.18 with HTTP; Mon, 22 Jan 2007 09:03:00 -0800 (PST) Message-ID: Date: Mon, 22 Jan 2007 17:03:00 +0000 From: "Eduardo Martins" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Simple] Is there any Document (and Naming Conventions) to specify AUIDs in XCAP Server? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0695009980==" Errors-To: simple-bounces@ietf.org --===============0695009980== Content-Type: multipart/alternative; boundary="----=_Part_212637_26093280.1169485380618" ------=_Part_212637_26093280.1169485380618 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, is there any document definition for each of xcap-caps AUIDs (and a path relative xcap root?), where all its properties are defined, or should this kind of info, like the AUID's mimetype for example, be unavailable externally? Regards Eduardo ------=_Part_212637_26093280.1169485380618 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, is there any document definition for each of xcap-caps AUIDs (and a path relative xcap root?), where all its properties are defined, or should this kind of info, like the AUID's mimetype for example, be unavailable externally?

Regards

Eduardo
------=_Part_212637_26093280.1169485380618-- --===============0695009980== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0695009980==-- From simple-bounces@ietf.org Mon Jan 22 16:32:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H96mB-0006DG-Fz; Mon, 22 Jan 2007 16:32:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H96mA-0006Cr-EO for simple@ietf.org; Mon, 22 Jan 2007 16:32:26 -0500 Received: from hu-out-0506.google.com ([72.14.214.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H96m9-0004hm-5B for simple@ietf.org; Mon, 22 Jan 2007 16:32:26 -0500 Received: by hu-out-0506.google.com with SMTP id 38so82113huc for ; Mon, 22 Jan 2007 13:32:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=D1jKy00T6P32g9UK1JNP5LrBQOJknL3aVu9sGHtVxjsswmBvZGjmPGdlvRpV8fjmwR3/3fKUBP3cwsSCoagnoh+WixEC2KClF/WLpreiA4sR+8BeehgpJ7axM47Hbl60FdFBrlxuaBweT9cYpCOLy4krNotKrAOM9Hl+wFKiGDc= Received: by 10.82.182.8 with SMTP id e8mr5345158buf.1169485380740; Mon, 22 Jan 2007 09:03:00 -0800 (PST) Received: by 10.82.168.18 with HTTP; Mon, 22 Jan 2007 09:03:00 -0800 (PST) Message-ID: Date: Mon, 22 Jan 2007 17:03:00 +0000 From: "Eduardo Martins" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Simple] Is there any Document (and Naming Conventions) to specify AUIDs in XCAP Server? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1763486077==" Errors-To: simple-bounces@ietf.org --===============1763486077== Content-Type: multipart/alternative; boundary="----=_Part_212637_26093280.1169485380618" ------=_Part_212637_26093280.1169485380618 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, is there any document definition for each of xcap-caps AUIDs (and a path relative xcap root?), where all its properties are defined, or should this kind of info, like the AUID's mimetype for example, be unavailable externally? Regards Eduardo ------=_Part_212637_26093280.1169485380618 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, is there any document definition for each of xcap-caps AUIDs (and a path relative xcap root?), where all its properties are defined, or should this kind of info, like the AUID's mimetype for example, be unavailable externally?

Regards

Eduardo
------=_Part_212637_26093280.1169485380618-- --===============1763486077== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1763486077==-- From simple-bounces@ietf.org Tue Jan 23 09:31:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9MgJ-0001Tc-Vq; Tue, 23 Jan 2007 09:31:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9MgJ-0001TX-EZ for simple@ietf.org; Tue, 23 Jan 2007 09:31:27 -0500 Received: from gate01.nexlink.ch ([80.86.198.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9MgI-0000AR-2e for simple@ietf.org; Tue, 23 Jan 2007 09:31:27 -0500 Received: from mail02.nexlink.ch ([10.51.9.2]) by gate01.nexlink.ch (8.13.1/8.13.1) with ESMTP id l0NEVJdK023155 for ; Tue, 23 Jan 2007 15:31:19 +0100 Received: from localhost ([127.0.0.1] helo=mail01.nexlink.ch) by mail02.nexlink.ch with esmtp (Exim 4.63) (envelope-from ) id 1H9MgB-0001i4-6R for simple@ietf.org; Tue, 23 Jan 2007 15:31:19 +0100 MIME-Version: 1.0 From: =?UTF-8?B?Sm/Dq2wgUmVwaXF1ZXQ=?= To: simple@ietf.org Date: Tue, 23 Jan 2007 15:31:19 +0100 Message-Id: <47109.1169562679@tech-invite.com> X-Mailer: AtMail 4.61 - 10.52.0.2 - joel.repiquet@tech-invite.com X-Spam-Score: 1.5 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Simple] Presence document composition X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joel.repiquet@tech-invite.com List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1297104362==" Errors-To: simple-bounces@ietf.org --===============1297104362== Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" There are two individual drafts related to presence document composition: - draft-schulzrinne-simple-composition-02
- rosenberg-simple-presence-processing-model-02

Both drafts have just expired.

Just for knowing:
1) is presence document composition still an ongoing work item in the frame= of the SIMPLE WG?
2) how is the "composition" chapter in the presence-processing-model draft = related to the composition draft? in other words: is there a common work on= this topic?

Thanks

--===============1297104362== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1297104362==-- From simple-bounces@ietf.org Tue Jan 23 13:23:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9QHs-0002Bt-2w; Tue, 23 Jan 2007 13:22:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9QHq-0002BT-U0 for simple@ietf.org; Tue, 23 Jan 2007 13:22:26 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9QEd-0004q8-Sa for simple@ietf.org; Tue, 23 Jan 2007 13:19:10 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1146056ugd for ; Tue, 23 Jan 2007 10:19:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tl7+9twIy+BrPxPZAgIMAistgmcb+1y0wvSEmmXojgqWyuyDVwUOHJkOmWvl02T3nXZkFmzr5BEZJ9XwsN37u1g4oTtC0NI9mwhDjrMeFbOMpEPVyKjqsfZf2/Os02aR5amB/NdTR35GN9V84IyLcOB7qcg+2tB2r9gi/4JOHqI= Received: by 10.82.120.14 with SMTP id s14mr196762buc.1169576346518; Tue, 23 Jan 2007 10:19:06 -0800 (PST) Received: by 10.82.168.18 with HTTP; Tue, 23 Jan 2007 10:19:06 -0800 (PST) Message-ID: Date: Tue, 23 Jan 2007 18:19:06 +0000 From: "Eduardo Martins" To: "madan kumar" Subject: Re: [Simple] Is there any Document (and Naming Conventions) to specify AUIDs in XCAP Server? In-Reply-To: <2706a4bb0701222017r91ae720r34cfd26c8628720c@mail.gmail.com> MIME-Version: 1.0 References: <2706a4bb0701222017r91ae720r34cfd26c8628720c@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1754448278==" Errors-To: simple-bounces@ietf.org --===============1754448278== Content-Type: multipart/alternative; boundary="----=_Part_237346_33061141.1169576346487" ------=_Part_237346_33061141.1169576346487 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Madan, tks for replying, I think you did not understand my mail :) What I'm looking for, is to know if there is any kind of xml doc to specify a AUID (default namespace,mimetype,etc...), and if there is, if it is (or not) stored somewhere in the public xcap root. Thanks, Eduardo On 1/23/07, madan kumar wrote: > > hi Martin , > > Check out these > > > OMA-TS-IM_XDM-V1_0-20060623-D > OMA-TS-XDM_Shared_List-V2_0-20060627-D > > Please refer to the internal references of these documents > regards, > Madan > > On 1/22/07, Eduardo Martins wrote: > > > Hi, is there any document definition for each of xcap-caps AUIDs (and a > > path relative xcap root?), where all its properties are defined, or should > > this kind of info, like the AUID's mimetype for example, be unavailable > > externally? > > > > Regards > > > > Eduardo > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > ------=_Part_237346_33061141.1169576346487 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Madan, tks for replying, I think you did not understand my mail :)

What I'm looking for, is to know if there is any kind of xml doc to specify a AUID (default namespace,mimetype,etc...), and if there is, if it is (or not) stored somewhere in the public xcap root.

Thanks,

Eduardo

On 1/23/07, madan kumar <mada2k@gmail.com> wrote:
hi Martin ,
 
            Check out these
 

       OMA-TS-IM_XDM-V1_0-20060623-D
OMA-TS-XDM_Shared_List-V2_0-20060627-D
 
Please refer to the internal references of these documents
regards,
Madan
 
On 1/22/07, Eduardo Martins < emmartins@gmail.com> wrote:
Hi, is there any document definition for each of xcap-caps AUIDs (and a path relative xcap root?), where all its properties are defined, or should this kind of info, like the AUID's mimetype for example, be unavailable externally?

Regards

Eduardo

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




------=_Part_237346_33061141.1169576346487-- --===============1754448278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1754448278==-- From simple-bounces@ietf.org Tue Jan 23 18:49:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9VNR-0008HP-8E; Tue, 23 Jan 2007 18:48:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9VNQ-0008HJ-9a for simple@ietf.org; Tue, 23 Jan 2007 18:48:32 -0500 Received: from extmail13.cingular.com ([170.35.225.28] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9VNN-0004Pq-UT for simple@ietf.org; Tue, 23 Jan 2007 18:48:32 -0500 Received: from ([10.148.14.27]) by extmail13.cingular.com with ESMTP id KP-TRRF8.98455715; Tue, 23 Jan 2007 18:48:06 -0500 Received: from TBDCEXCH10.US.Cingular.Net ([10.148.14.47]) by TD02XSMTP005.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 17:48:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] New Draft: Deferred Messaging Disposition Notification Date: Tue, 23 Jan 2007 17:48:05 -0600 Message-ID: <451C9AB8BFB6B64EA11547A3D966DB3609A6E355@TBDCEXCH10.US.Cingular.Net> In-Reply-To: <451C9AB8BFB6B64EA11547A3D966DB3609808940@TBDCEXCH10.US.Cingular.Net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] New Draft: Deferred Messaging Disposition Notification Thread-Index: AccivrzyD0uDK4agSi2n0Jz4+p42YQZI/3SQANlhM6A= To: X-OriginalArrivalTime: 23 Jan 2007 23:48:06.0377 (UTC) FILETIME=[EDD60590:01C73F48] From: "Stafford, Matthew" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "Shih, Jerry" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Prague agenda item request: we would like to have a timeslot (20 minutes if possible) to present & discuss this draft. One of my co-authors, Jerry Shih, will be attending the session. Thanks, Matt -----Original Message----- From: Stafford, Matthew=20 Sent: Friday, January 19, 2007 10:45 AM To: simple@ietf.org Cc: Wuthnow, Mark; Shih, Jerry Subject: [Simple] New Draft: Deferred Messaging Disposition Notification We had some discussion about a month ago re: pulling MSRP out of the IMDN draft. Thanks to Ben, Miguel and Hisham for their responses. I'd say the upshot of that discussion was twofold: the "slimmed-down" IMDN draft needs to go ahead, and any push to expand IMDN's applicability needs to start with clear documentation of requirements. Jointly with two colleagues at Cingular/AT&T, I have submitted an I-D to address the latter point. It is now posted at=20 http://www.ietf.org/internet-drafts/draft-stafford-simple-dmdn-00.txt This draft is intended to start the ball rolling by presenting use cases. It makes a straw proposal that IMDN usage be extended to MSRP. (I do understand that there may be other, better ways to meet the requirements- but this draft still seems to be a reasonable starting point.) Best, Matt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jan 25 06:39:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA2wP-0001Im-Sf; Thu, 25 Jan 2007 06:38:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA2wO-0001Ig-9T for simple@ietf.org; Thu, 25 Jan 2007 06:38:52 -0500 Received: from datnt07.tieto.com ([194.110.47.24] helo=mail2.tieto.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA2wJ-0005YI-Qf for simple@ietf.org; Thu, 25 Jan 2007 06:38:52 -0500 X-AuditID: c26e2f18-0000103c00001498-f8-45b896b82755 Received: from viper.eu.tieto.com ([194.110.47.167]) by mail2.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 13:38:32 +0200 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by viper.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 13:38:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jan 2007 13:38:35 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Conflict in draft-ietf-simple-xcap-12 Thread-Index: AcdAdVjWzAX0WuGDTXWHuIntSrGNKg== From: To: , X-OriginalArrivalTime: 25 Jan 2007 11:38:37.0091 (UTC) FILETIME=[5A227F30:01C74075] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: David.Pilar@tietoenator.com, Ivo.Hajducek@tietoenator.com Subject: [Simple] Conflict in draft-ietf-simple-xcap-12 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello,=20 I have a problem with draft-ietf-simple-xcap-12. In my opinion following parts of the draft are in conflict: 7.11 Conditional operations ... In another example, a client may wish to insert a new element into a document, but wants to be sure that the insertion will only take place if that element does not exist. In other words, the client wants the PUT operation to be a creation, not a replacement. To accomplish that, the client can insert the If-None-Match header field into the PUT request, with a value of *. This tells the server to reject the request with a 412 if resource exists. ... 8.2.6. Conditional Processing A PUT request for an XCAP resource, like any other HTTP resource, can be made conditional through usage of the If-Match and If-None-Match header fields. For a replacement, these are processed as defined in [6]. For an insertion of an element or attribute, conditional operations are permitted. The entity tag that is used for the procedures in [6] is the one for all of the resources within the same document as the parent of the element or attribute being inserted. One way to think of this is that, logically speaking, on receipt of the PUT request, the XCAP server instantiates the etag for the resource referenced by the request, and then applies the processing of the request. Because of this behavior, it is not possible to perform a conditional insert on an attribute or element conditioned on the operation being an insertion and not a replacement. In other words, a conditional PUT of an element or attribute with an If-None- Match: * will always fail. The former part says that I can use "If-None-Match: *" in PUT request to ensure creation. The latter says that PUT request with "If-None-Match: *" always fails. Could you please comment on this? Thank you,=20 Silvestr Peknik Software Specialist TietoEnator Czech s.r.o. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From usiqcuu@alicedsl.de Fri Jan 26 05:56:10 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAOkc-0008Qc-A9 for simple-archive@lists.ietf.org; Fri, 26 Jan 2007 05:56:10 -0500 Received: from e178167242.adsl.alicedsl.de ([85.178.167.242] helo=e178158070.adsl.alicedsl.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HAOka-0006FP-PN for simple-archive@lists.ietf.org; Fri, 26 Jan 2007 05:56:10 -0500 From: "factors present" To: simple-archive@lists.ietf.org Subject: Next Big market Winner! Date: Fri, 26 Jan 2007 11:54:59 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C74140.CE3B3E90" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdBQM47WlUpuuNcRNWc1EVcrS7ubA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.4 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ------=_NextPart_000_0001_01C74140.CE3B3E90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
<> ATTENTION DAY TRADERS AND INVESTORS. GET ON PSUD! <>

INVESTOR ALERT! DON'T MISS THIS RUN ON PSUD!!!

Watch PSUD Like a Hawk on January 26, 2007

Company: PetroSun
Sym: PSUD
Currently: $0.43 (+0.01 Close)
Friday Target: $1.50

PHOENIX, AZ--(MRKET WIRE)--Jan 11, 2007 -- PetroSun, Incorporated (Other 0TC:PSUD,PK - News) announced today that an agreement has been executed with New Standard Exploration NL of West Perth, Australia covering Exploration Permit 417 located within the Canning Basin of Western Australia. PetroSun and New Standard will form a joint venture to explore, develop and produce oil and/or gas from EP417. PetroSun is the designated Manager/Operator and will be assigned a 75% working interest in the permit for the initial consideration of A$5,000,000 through PetroSun's sole funding of exploration, permit development and drilling.

Keep a look out for additional GREAT weekly news and be sure to watch them trade like crazy on Friday January 26, 2007

------=_NextPart_000_0001_01C74140.CE3B3E90-- From simple-bounces@ietf.org Sun Jan 28 04:47:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB6bA-00083G-Cl; Sun, 28 Jan 2007 04:45:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB6b9-000836-92 for simple@ietf.org; Sun, 28 Jan 2007 04:45:19 -0500 Received: from mailreg.nctu.edu.tw ([211.76.241.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HB6b7-00079c-TG for simple@ietf.org; Sun, 28 Jan 2007 04:45:19 -0500 Received: from [127.0.0.1] (rhliou.Dorm3.NCTU.edu.tw [140.113.55.54]) by mailreg.nctu.edu.tw (Postfix) with ESMTP id CB00B7E82B for ; Sun, 28 Jan 2007 17:45:14 +0800 (CST) Message-ID: <45BC70A9.5050005@gmail.com> Date: Sun, 28 Jan 2007 17:45:13 +0800 From: Ren-Huang Liou User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: zh-tw, en-us, en MIME-Version: 1.0 To: simple@ietf.org Subject: [Simple] Question about sending SUBSCRIBE before sending REGISTER Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Dear all, If the user agent sends SUBSCRIBE request to the server before the registration, what response will the server send? Namely, the location database don't have the contact information of this AOR. Thanks in advance, Ren-Huang Liou _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jan 28 08:02:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB9eE-0006Ce-6S; Sun, 28 Jan 2007 08:00:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB9eC-0006C3-If for simple@ietf.org; Sun, 28 Jan 2007 08:00:40 -0500 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HB9eB-00049E-Cx for simple@ietf.org; Sun, 28 Jan 2007 08:00:40 -0500 Received: by wx-out-0506.google.com with SMTP id h31so1359189wxd for ; Sun, 28 Jan 2007 05:00:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=eLBkaZ7tHeiaE6bKTRBdppKOd8tx7rjs0r+bepu8ubdXdZdBh7Djee47rByqckXRpk+KCJ0kjJo/eTS0ngggYIgUSxvaIYWgw7Q+QeUvfS9Pz+TjkW4kMNR4wCqsgguuEFPrAfk3m9Pbew07iAgVuEZDyhZdlNTST4nRPl5VPNY= Received: by 10.90.101.19 with SMTP id y19mr5485196agb.1169989238969; Sun, 28 Jan 2007 05:00:38 -0800 (PST) Received: by 10.90.115.10 with HTTP; Sun, 28 Jan 2007 05:00:38 -0800 (PST) Message-ID: Date: Sun, 28 Jan 2007 13:00:38 +0000 From: Tiago To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Simple] XCAP URI Parsing: Extension Selector??? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1255467463==" Errors-To: simple-bounces@ietf.org --===============1255467463== Content-Type: multipart/alternative; boundary="----=_Part_54979_26256982.1169989238946" ------=_Part_54979_26256982.1169989238946 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, how can identify a terminal extension selector from an element selector, in the XCAP URI, if it can be anything except '/' ? Regards, /snip ------=_Part_54979_26256982.1169989238946 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, how can identify a terminal extension selector from an element selector, in the XCAP URI, if it can be anything except '/' ?

Regards,

/snip
------=_Part_54979_26256982.1169989238946-- --===============1255467463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1255467463==-- From simple-bounces@ietf.org Sun Jan 28 08:10:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB9nB-0002hs-3a; Sun, 28 Jan 2007 08:09:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB9n9-0002hn-6G for simple@ietf.org; Sun, 28 Jan 2007 08:09:55 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HB9n7-0005pl-So for simple@ietf.org; Sun, 28 Jan 2007 08:09:55 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCK00J5PXWFW4@usaga01-in.huawei.com> for simple@ietf.org; Sun, 28 Jan 2007 05:09:51 -0800 (PST) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCK00IKFXWEQQ@usaga01-in.huawei.com> for simple@ietf.org; Sun, 28 Jan 2007 05:09:51 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [59.40.123.61]) by szxmc04-in.huawei.com (mshttpd); Sun, 28 Jan 2007 21:09:52 +0800 Date: Sun, 28 Jan 2007 21:09:52 +0800 From: xupeili 18916 Subject: Re: [Simple] Question about sending SUBSCRIBE before sending REGISTER To: Ren-Huang Liou Message-id: <152b376152b3cf.152b3cf152b376@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Liou, I am not very clear about your deployment senario, but according to RFC3261, it's not necessary to do registration before the user agent sending SUBSCRIBE. Since the SUBSCRIBE request will setup a dialog, the server can deliver the notification based on the route set of this dialog. There may have some specific system requires the user agent to do registration before any further action. In this case, that system can require sending some specific error response. Cheers. Peili ----- Original Message ----- From: Ren-Huang Liou Date: Sunday, January 28, 2007 5:45 pm Subject: [Simple] Question about sending SUBSCRIBE before sending REGISTER > Dear all, > > If the user agent sends SUBSCRIBE request to the server before the > registration, what response will the server send? > > Namely, the location database don't have the contact information of > thisAOR. > > Thanks in advance, > Ren-Huang Liou > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jan 29 05:24:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBTfK-0008PO-Pc; Mon, 29 Jan 2007 05:23:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBTfJ-0008MH-53 for simple@ietf.org; Mon, 29 Jan 2007 05:23:09 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBTfH-0007b9-Oa for simple@ietf.org; Mon, 29 Jan 2007 05:23:09 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1059683ugd for ; Mon, 29 Jan 2007 02:23:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=kr99cxsAtBE8kf6fzeMJ3ywB7i6vpMeVeqE1OUg4R+pQZXUWUsMWAyFgilMpbtBeSwyneuZckTplpYANMoXC4tYnDx2zb2L0kHYFnY3iNiQUhQMSblxT8Y7cpehAfeaf3fiXc43b9VaxLoCKbqUPGJHCOTLc/MIAmhhm1r9Bp8c= Received: by 10.82.172.15 with SMTP id u15mr3229763bue.1170066186656; Mon, 29 Jan 2007 02:23:06 -0800 (PST) Received: by 10.82.152.11 with HTTP; Mon, 29 Jan 2007 02:23:06 -0800 (PST) Message-ID: <2706a4bb0701290223g2dfc1612vd99548c6039c624c@mail.gmail.com> Date: Mon, 29 Jan 2007 15:53:06 +0530 From: "madan kumar" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Simple] 415 media not supported X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1855768495==" Errors-To: simple-bounces@ietf.org --===============1855768495== Content-Type: multipart/alternative; boundary="----=_Part_76455_30840785.1170066186291" ------=_Part_76455_30840785.1170066186291 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, Iam testing IM application with a server called jain SIP server which supports IM application . when i try to send a message iam getting 415 media not supported , y is this happening and what shd be done to resolve this .. regards, Madan ------=_Part_76455_30840785.1170066186291 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi all,
 
          Iam testing IM application with a server called jain SIP server which supports IM application . when i try to send a message iam getting 415 media not supported , y is this happening and what shd be done to resolve this ..
 
regards,
Madan
------=_Part_76455_30840785.1170066186291-- --===============1855768495== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1855768495==-- From simple-bounces@ietf.org Mon Jan 29 07:35:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBViF-0003Gm-KN; Mon, 29 Jan 2007 07:34:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBViE-0003Gg-93 for simple@ietf.org; Mon, 29 Jan 2007 07:34:18 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBViC-00023J-W4 for simple@ietf.org; Mon, 29 Jan 2007 07:34:18 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Jan 2007 07:34:14 -0500 X-IronPort-AV: i="4.13,251,1167627600"; d="scan'208,217"; a="112663032:sNHT76205784" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0TCYErl026608; Mon, 29 Jan 2007 07:34:14 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0TCYEVT006650; Mon, 29 Jan 2007 07:34:14 -0500 (EST) Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 07:34:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] 415 media not supported Date: Mon, 29 Jan 2007 07:34:12 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E02A896C3@xmb-rtp-215.amer.cisco.com> In-Reply-To: <2706a4bb0701290223g2dfc1612vd99548c6039c624c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] 415 media not supported Thread-Index: AcdDkBTJDCxUwxk5Q3WWYg53nDohvQAEaAVg From: "Sanjay Sinha \(sanjsinh\)" To: "madan kumar" , X-OriginalArrivalTime: 29 Jan 2007 12:34:14.0222 (UTC) FILETIME=[C8DF46E0:01C743A1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2262; t=1170074054; x=1170938054; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20\(sanjsinh\)=22=20 |Subject:=20RE=3A=20[Simple]=20415=20media=20not=20supported |Sender:=20 |To:=20=22madan=20kumar=22=20,=20; bh=39ISoCtXZAc0kL7gHTMQ6WTCc43D5JUpX0xupvLEmks=; b=LdwGZXNkIQrZC2r5bZYSkEsf+VXenghdFNv+iz6XQ15q4PAAX7mJPlXPjkESxUQKk9YF7T0o Zy5d2eGwv26X8xRIT0/jv9HZO6dGU8CaSayACjwHhtJ1mTFhUMH6qf3X; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1636029349==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1636029349== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C743A1.C8C3E629" This is a multi-part message in MIME format. ------_=_NextPart_001_01C743A1.C8C3E629 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It may not understand/support the Content-Type mentioned in MESSAGE ________________________________ From: madan kumar [mailto:mada2k@gmail.com]=20 Sent: Monday, January 29, 2007 5:23 AM To: simple@ietf.org Subject: [Simple] 415 media not supported =09 =09 Hi all, =20 Iam testing IM application with a server called jain SIP server which supports IM application . when i try to send a message iam getting 415 media not supported , y is this happening and what shd be done to resolve this ..=20 =20 regards, Madan ------_=_NextPart_001_01C743A1.C8C3E629 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It may not understand/support the Content-Type = mentioned in=20 MESSAGE

From: madan kumar = [mailto:mada2k@gmail.com]=20
Sent: Monday, January 29, 2007 5:23 AM
To:=20 simple@ietf.org
Subject: [Simple] 415 media not=20 supported

Hi all,
 
          Iam = testing IM=20 application with a server called jain SIP server which supports = IM=20 application . when i try to send a message iam getting 415 media not = supported=20 , y is this happening and what shd be done to resolve this ..
 
regards,
Madan
------_=_NextPart_001_01C743A1.C8C3E629-- --===============1636029349== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1636029349==-- From simple-bounces@ietf.org Tue Jan 30 01:09:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBm9r-0003yr-QV; Tue, 30 Jan 2007 01:07:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBm9p-0003yj-Fh for simple@ietf.org; Tue, 30 Jan 2007 01:07:53 -0500 Received: from gurgaon.orgltd.com ([61.247.231.160] helo=mail.orgltd.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBm9j-0004Vn-IO for simple@ietf.org; Tue, 30 Jan 2007 01:07:53 -0500 Received: from osibisa (unknown [203.187.242.78]) by mail.orgltd.com (Postfix) with ESMTP id 19480DEC52; Tue, 30 Jan 2007 11:08:02 +0530 (IST) From: "Vikas Tandon" To: "'xupeili 18916'" , "'Ren-Huang Liou'" Subject: RE: [Simple] Question about sending SUBSCRIBE before sending REGISTER Date: Tue, 30 Jan 2007 11:37:31 +0530 Organization: ORG Telecom Ltd MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdC2c+A4mi/6RjOTUqiJc2xD0ueeABWpEVw In-Reply-To: <152b376152b3cf.152b3cf152b376@huawei.com> Message-Id: <20070130053802.19480DEC52@mail.orgltd.com> X-Spam-Score: 1.8 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vikas.tandon@orgltd.com List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Peili, Liou, How do you ensure that the requesting UE is a valid user for subscribing to that event in case you don't make it mandatory to have a subscription. Regards, Vikas -----Original Message----- From: xupeili 18916 [mailto:xupeili@huawei.com] Sent: Sunday, January 28, 2007 6:40 PM To: Ren-Huang Liou Cc: simple@ietf.org Subject: Re: [Simple] Question about sending SUBSCRIBE before sending REGISTER Hi Liou, I am not very clear about your deployment senario, but according to RFC3261, it's not necessary to do registration before the user agent sending SUBSCRIBE. Since the SUBSCRIBE request will setup a dialog, the server can deliver the notification based on the route set of this dialog. There may have some specific system requires the user agent to do registration before any further action. In this case, that system can require sending some specific error response. Cheers. Peili ----- Original Message ----- From: Ren-Huang Liou Date: Sunday, January 28, 2007 5:45 pm Subject: [Simple] Question about sending SUBSCRIBE before sending REGISTER > Dear all, > > If the user agent sends SUBSCRIBE request to the server before the > registration, what response will the server send? > > Namely, the location database don't have the contact information of > thisAOR. > > Thanks in advance, > Ren-Huang Liou > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 30 16:35:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC0c0-00040G-36; Tue, 30 Jan 2007 16:33:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC0by-0003zt-2D; Tue, 30 Jan 2007 16:33:54 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC0bx-0006gp-Nd; Tue, 30 Jan 2007 16:33:54 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id 92DBF26E72; Tue, 30 Jan 2007 21:33:53 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1HC0bx-0006P1-FG; Tue, 30 Jan 2007 16:33:53 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: iesg@ietf.org, iab@iab.org, simple@ietf.org, Robert Sparks , Hisham Khartabil From: IESG Secretary Message-Id: Date: Tue, 30 Jan 2007 16:33:53 -0500 X-Spam-Score: -2.3 (--) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Subject: [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A new charter for the SIP for Instant Messaging and Presence Leveraging Extensions (simple) working group in the Real-time Applications and Infrastructure Area of the IETF is being considered. The draft charter is provided below for your review and comment. Review time is one week. The IETF Secretariat +++ SIP for Instant Messaging and Presence Leveraging Extensions (simple) ====================================================================== Last Modified: 2007-1-24 Current Status: Active Working Group Chair(s): Robert Sparks Hisham Khartabil Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson Technical Advisor(s): Jon Peterson Mailing Lists: General Discussion: simple@ietf.org To Subscribe: simple-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/simple/index.html Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. This group has completed the majority of its primary goals and will focus on the remaining tasks documented here and concluding. Any proposed new work should be socialized with the chairs and AD early to determine if this WG is an appropriate venue. The primary remaining work of this group will be to complete: 1. The MSRP proposed standard mechanism for transporting sessions of messages initiated using the SIP, compliant to the requirments of RFC 2779, CPIM and BCP 41. 2. The XCAP framework for representing and carrying configuration and policy information in SIMPLE systems. 3. A mechanism for representing partial changes (patches) to XML documents and extensions to the SIMPLE publication and notification mechanisms to convey these partial changes. 4. A mechanism for initiating and managing Instant Message group chat. 5. An annotated overview of the SIMPLE protocol definition documents. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions. Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will be defined in XCON. They will be limited in scope to address only simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing protocols XCON is working towards. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here. Goals and Milestones: Done Submission of event package for presence to IESG for publication as Proposed Standard Done Submission of watcher information drafts to IESG for publication as Proposed Standards Done Submission of proposed event list mechanism to the SIP working group Done Submission of requirements for event publishing to the IESG for publication as Proposed Standard Done Submission of proposed mechanism for event publishing to the SIP working group Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard Done Submission of base XCAP draft to IESG for publication as Proposed Standard Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard Done Submission of XCAP usage for manipulation of presence document content Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard Done Submission of Filtering mechanisms to IESG for publication as a Proposed Standard Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard Done Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard Feb 2007 Submission of an Instant Message Disposition Notification mechanism to the IESG for publication as a Proposed Standard Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG for publication as Informational Aug 2007 Submission of proposed mechanisms for initiating and managing Instant Message group chat to the IESG for publication as Proposed Standard Aug 2007 Conclusion of SIMPLE _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 30 17:15:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC1Fw-0007CL-Fj; Tue, 30 Jan 2007 17:15:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC1Fv-0007CG-3Q for simple@ietf.org; Tue, 30 Jan 2007 17:15:11 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC1Ft-0004uI-LA for simple@ietf.org; Tue, 30 Jan 2007 17:15:11 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Jan 2007 14:15:09 -0800 X-IronPort-AV: i="4.13,259,1167638400"; d="scan'208"; a="51911129:sNHT55813456" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0UMF9Ga011296 for ; Tue, 30 Jan 2007 17:15:09 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0UMF9OA015494 for ; Tue, 30 Jan 2007 17:15:09 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 17:15:09 -0500 Received: from [161.44.183.228] ([161.44.183.228]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 17:15:09 -0500 Message-ID: <45BFC36C.4060304@cisco.com> Date: Tue, 30 Jan 2007 17:15:08 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: simple@ietf.org Subject: Re: [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2007 22:15:09.0096 (UTC) FILETIME=[1A68BA80:01C744BC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7117; t=1170195309; x=1171059309; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20Internal=20WG=20Review=3A=20Recharter=20of =20SIP=20for=20Instant=20Messaging=0A=20and=20Presence=20Leveraging=20Exte nsions=20(simple) |Sender:=20 |To:=20simple@ietf.org; bh=+EkWSgiWdeJY0nrSE7fiFj6ewa+vHZ/SJoe7cYmi110=; b=ceQfsLa3RO37VEe4OS48IL41Fs29lXq5Ax01vWWzeOI+RdOLID3kdMKhU2Ew+M5KIkyzElLx fOYFam01E1nrS7WqynLqDOAf1Zwl2v31sjISDhE1bB0mODX+4+TIGzEL; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Wasn't there some talk of a need to specify how to choose between MESSAGE and MSRP, and/or to transition between them in support of a single conversation? E.g. send a MESSAGE because there may never be a conversation, but then INVITE with an MSRP session to continue the conversation. The need here would be for a way to tie these things together so it is clear that they are part of the same conversation. There are obviously issues with involving the same pair of UAs in both. I seem to recall this was discussed at some point, but I'm not sure and if so I don't remember the outcome. Paul IESG Secretary wrote: > A new charter for the SIP for Instant Messaging and Presence Leveraging > Extensions (simple) working group in the Real-time Applications and > Infrastructure Area of the IETF is being considered. The draft charter > is provided below for your review and comment. > > Review time is one week. > > The IETF Secretariat > > +++ > > SIP for Instant Messaging and Presence Leveraging Extensions (simple) > ====================================================================== > > Last Modified: 2007-1-24 > > Current Status: Active Working Group > > Chair(s): > Robert Sparks > Hisham Khartabil > > > Real-time Applications and Infrastructure Area Director(s): > Jon Peterson > Cullen Jennings > > Real-time Applications and Infrastructure Area Advisor: > Jon Peterson > > Technical Advisor(s): > Jon Peterson > > Mailing Lists: > General Discussion: simple@ietf.org > To Subscribe: simple-request@ietf.org > In Body: subscribe > Archive: http://www.ietf.org/mail-archive/web/simple/index.html > > Description of Working Group: > > This working group focuses on the application of the Session Initiation > Protocol (SIP, RFC 3261) to the suite of services collectively known as > instant messaging and presence (IMP). The IETF has committed to > producing an interoperable standard for these services compliant to > the requirements for IM outlined in RFC 2779 (including the security > and privacy requirements there) and in the Common Presence and Instant > Messaging (CPIM) specification, developed within the IMPP working > group. As the most common services for which SIP is used share quite a > bit in common with IMP, the adaptation of SIP to IMP seems a natural > choice given the widespread support for (and relative maturity of) the > SIP standard. > > This group has completed the majority of its primary goals and will > focus on the remaining tasks documented here and concluding. Any > proposed new work should be socialized with the chairs and AD early to > determine if this WG is an appropriate venue. > > The primary remaining work of this group will be to complete: > > 1. The MSRP proposed standard mechanism for transporting sessions of > messages initiated using the SIP, compliant to the requirments of RFC > 2779, CPIM and BCP 41. > > 2. The XCAP framework for representing and carrying configuration and > policy information in SIMPLE systems. > > 3. A mechanism for representing partial changes (patches) to XML > documents and extensions to the SIMPLE publication and notification > mechanisms to convey these partial changes. > > 4. A mechanism for initiating and managing Instant Message group chat. > > 5. An annotated overview of the SIMPLE protocol definition documents. > > Any SIP extensions proposed in the course of this development will, > after a last call process, be transferred to the SIP WG for > consideration as formal SIP extensions. > > Any mechanisms created for managing Instant Message group chat are > intended to provide a bridge to the conferencing protocols that will > be defined in XCON. They will be limited in scope to address only > simple Instant Message chat with nicknames and will not attempt > to address complex conferencing concepts such as sidebars. Their > design must anticipate operating in conjunction with the conferencing > protocols XCON is working towards. > > The working group will work within the framework for presence and IM > described in RFC 2778. The extensions it defines must also be > compliant with the SIP processes for extensions. The group cannot > modify baseline SIP behavior or define a new version of SIP for IM and > presence. If the group determines that any capabilities requiring an > extension to SIP are needed, the group will seek to define such > extensions within the SIP working group, and then use them here. > > Goals and Milestones: > Done Submission of event package for presence to IESG for publication as Proposed Standard > Done Submission of watcher information drafts to IESG for publication as Proposed Standards > Done Submission of proposed event list mechanism to the SIP working group > Done Submission of requirements for event publishing to the IESG for > publication as Proposed Standard > Done Submission of proposed mechanism for event publishing to the SIP > working group > Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard > Done Submission of base XCAP draft to IESG for publication as Proposed > Standard > Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard > Done Submission of XCAP usage for manipulation of presence document > content > Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard > Done Submission of Filtering mechanisms to IESG for publication as a > Proposed Standard > Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard > Done Submission of instant messaging session relay drafts to IESG for > publication as Proposed Standards > Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard > Feb 2007 Submission of an Instant Message Disposition Notification > mechanism to the IESG for publication as a Proposed Standard > Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard > Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group > Mar 2007 Submission of a performance and scalability analysis of the > SIMPLE presence mechanisms to the IESG for publication as Informational > Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG > for publication as Informational > Aug 2007 Submission of proposed mechanisms for initiating and managing > Instant Message group chat to the IESG for publication as Proposed > Standard > Aug 2007 Conclusion of SIMPLE > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 30 17:52:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC1oQ-0007Pn-81; Tue, 30 Jan 2007 17:50:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC1oO-0007NZ-LQ for simple@ietf.org; Tue, 30 Jan 2007 17:50:48 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC1oM-00035f-4q for simple@ietf.org; Tue, 30 Jan 2007 17:50:48 -0500 Received: from [10.131.2.60] (astaro-in.netrake.com [65.122.242.2]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l0UMogp8002306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Jan 2007 16:50:42 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: <45BFC36C.4060304@cisco.com> References: <45BFC36C.4060304@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) Date: Tue, 30 Jan 2007 16:50:37 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 65.122.242.2 is authenticated by a trusted mechanism) X-Spam-Score: 0.5 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I also remember that being brought up, and also don't remember the outcome ;-) On Jan 30, 2007, at 4:15 PM, Paul Kyzivat wrote: > Wasn't there some talk of a need to specify how to choose between > MESSAGE and MSRP, and/or to transition between them in support of a > single conversation? > > E.g. send a MESSAGE because there may never be a conversation, but > then INVITE with an MSRP session to continue the conversation. The > need here would be for a way to tie these things together so it is > clear that they are part of the same conversation. There are > obviously issues with involving the same pair of UAs in both. > > I seem to recall this was discussed at some point, but I'm not sure > and if so I don't remember the outcome. > > Paul > > IESG Secretary wrote: >> A new charter for the SIP for Instant Messaging and Presence >> Leveraging >> Extensions (simple) working group in the Real-time Applications and >> Infrastructure Area of the IETF is being considered. The draft >> charter is provided below for your review and comment. >> Review time is one week. >> The IETF Secretariat >> +++ >> SIP for Instant Messaging and Presence Leveraging Extensions (simple) >> ===================================================================== >> = >> Last Modified: 2007-1-24 >> Current Status: Active Working Group >> Chair(s): >> Robert Sparks >> Hisham Khartabil >> Real-time Applications and Infrastructure Area Director(s): >> Jon Peterson >> Cullen Jennings >> Real-time Applications and Infrastructure Area Advisor: >> Jon Peterson >> Technical Advisor(s): >> Jon Peterson >> Mailing Lists: >> General Discussion: simple@ietf.org >> To Subscribe: simple-request@ietf.org >> In Body: subscribe >> Archive: http://www.ietf.org/mail-archive/web/simple/index.html >> Description of Working Group: >> This working group focuses on the application of the Session >> Initiation >> Protocol (SIP, RFC 3261) to the suite of services collectively >> known as >> instant messaging and presence (IMP). The IETF has committed to >> producing an interoperable standard for these services compliant >> to the requirements for IM outlined in RFC 2779 (including the >> security and privacy requirements there) and in the Common >> Presence and Instant Messaging (CPIM) specification, developed >> within the IMPP working group. As the most common services for >> which SIP is used share quite a bit in common with IMP, the >> adaptation of SIP to IMP seems a natural choice given the >> widespread support for (and relative maturity of) the >> SIP standard. >> This group has completed the majority of its primary goals and >> will focus on the remaining tasks documented here and concluding. >> Any proposed new work should be socialized with the chairs and AD >> early to determine if this WG is an appropriate venue. >> The primary remaining work of this group will be to complete: >> 1. The MSRP proposed standard mechanism for transporting sessions of >> messages initiated using the SIP, compliant to the requirments of >> RFC 2779, CPIM and BCP 41. >> 2. The XCAP framework for representing and carrying configuration and >> policy information in SIMPLE systems. >> 3. A mechanism for representing partial changes (patches) to XML >> documents and extensions to the SIMPLE publication and >> notification mechanisms to convey these partial changes. >> 4. A mechanism for initiating and managing Instant Message group >> chat. >> 5. An annotated overview of the SIMPLE protocol definition documents. >> Any SIP extensions proposed in the course of this development >> will, after a last call process, be transferred to the SIP WG for >> consideration as formal SIP extensions. >> Any mechanisms created for managing Instant Message group chat are >> intended to provide a bridge to the conferencing protocols that >> will be defined in XCON. They will be limited in scope to address >> only simple Instant Message chat with nicknames and will not attempt >> to address complex conferencing concepts such as sidebars. Their >> design must anticipate operating in conjunction with the >> conferencing protocols XCON is working towards. >> The working group will work within the framework for presence and IM >> described in RFC 2778. The extensions it defines must also be >> compliant with the SIP processes for extensions. The group cannot >> modify baseline SIP behavior or define a new version of SIP for IM >> and presence. If the group determines that any capabilities >> requiring an extension to SIP are needed, the group will seek to >> define such >> extensions within the SIP working group, and then use them here. >> Goals and Milestones: >> Done Submission of event package for presence to IESG for >> publication as Proposed Standard >> Done Submission of watcher information drafts to IESG for >> publication as Proposed Standards >> Done Submission of proposed event list mechanism to the SIP >> working group Done Submission of requirements for event publishing >> to the IESG for >> publication as Proposed Standard >> Done Submission of proposed mechanism for event publishing to the SIP >> working group >> Done Submission of SIMPLE PIDF profile to IESG for publication as >> Proposed Standard >> Done Submission of base XCAP draft to IESG for publication as >> Proposed >> Standard >> Done Submission of indication of instant message preparation using >> SIP to IESG for publication as a Proposed Standard >> Done Submission of XCAP usage for manipulation of presence document >> content >> Done Submission of XCAP usage for setting presence authorization >> to IESG for publication as Proposed Standard >> Done Submission of Filtering mechanisms to IESG for publication as a >> Proposed Standard >> Done Submission of instant messaging session draft to IESG for >> publication as a Proposed Standard >> Done Submission of instant messaging session relay drafts to IESG for >> publication as Proposed Standards >> Done Submission of Partial Notification mechanism to IESG for >> publication as a Proposed Standard >> Feb 2007 Submission of an Instant Message Disposition Notification >> mechanism to the IESG for publication as a Proposed Standard >> Feb 2007 Submission of XCAP event package to IESG or appropriate >> working group targeting publication as Proposed Standard >> Feb 2007 Submission of proposed mechanisms meeting the advanced >> messaging requirements to the IESG or appropriate working group >> Mar 2007 Submission of a performance and scalability analysis of the >> SIMPLE presence mechanisms to the IESG for publication as >> Informational >> Jun 2007 Submission of SIMPLE protocol annotated overview draft to >> IESG >> for publication as Informational >> Aug 2007 Submission of proposed mechanisms for initiating and >> managing >> Instant Message group chat to the IESG for publication as Proposed >> Standard >> Aug 2007 Conclusion of SIMPLE >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 30 20:44:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC4VR-0000Cq-NL; Tue, 30 Jan 2007 20:43:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC4VQ-0000Ck-FS for simple@ietf.org; Tue, 30 Jan 2007 20:43:24 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC4VP-0004Hx-T8 for simple@ietf.org; Tue, 30 Jan 2007 20:43:24 -0500 Received: by ug-out-1314.google.com with SMTP id 72so42553ugd for ; Tue, 30 Jan 2007 17:43:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=op03hU/rvNWUs4EldgjYWV2Jygn5qMlwIZIes6LX88QFSsiY1aKpEFl2S4jeueW5InaUdXrFXfjcbxiYwjWvNOynfjYcQZWTekyEwxwgHmyH6j2o/Yx5OWl9WGQvWWP+y55XTIAQokC4LQOjXywxvX+bWZqazvVdwbjTajTReD8= Received: by 10.82.111.8 with SMTP id j8mr41633buc.1170207802892; Tue, 30 Jan 2007 17:43:22 -0800 (PST) Received: by 10.82.112.7 with HTTP; Tue, 30 Jan 2007 17:43:20 -0800 (PST) Message-ID: <66cd252f0701301743ycc944cfhbee8817f21aa506b@mail.gmail.com> Date: Wed, 31 Jan 2007 12:43:20 +1100 From: "Hisham Khartabil" To: "Ben Campbell" Subject: Re: [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45BFC36C.4060304@cisco.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: Paul Kyzivat , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I believe this was to be put into the June milestone. But I guess Ben and Paul want to see it as one of the primary milestones listed. Regards, Hisham On 31/01/07, Ben Campbell wrote: > I also remember that being brought up, and also don't remember the > outcome ;-) > > On Jan 30, 2007, at 4:15 PM, Paul Kyzivat wrote: > > > Wasn't there some talk of a need to specify how to choose between > > MESSAGE and MSRP, and/or to transition between them in support of a > > single conversation? > > > > E.g. send a MESSAGE because there may never be a conversation, but > > then INVITE with an MSRP session to continue the conversation. The > > need here would be for a way to tie these things together so it is > > clear that they are part of the same conversation. There are > > obviously issues with involving the same pair of UAs in both. > > > > I seem to recall this was discussed at some point, but I'm not sure > > and if so I don't remember the outcome. > > > > Paul > > > > IESG Secretary wrote: > >> A new charter for the SIP for Instant Messaging and Presence > >> Leveraging > >> Extensions (simple) working group in the Real-time Applications and > >> Infrastructure Area of the IETF is being considered. The draft > >> charter is provided below for your review and comment. > >> Review time is one week. > >> The IETF Secretariat > >> +++ > >> SIP for Instant Messaging and Presence Leveraging Extensions (simple) > >> ===================================================================== > >> = > >> Last Modified: 2007-1-24 > >> Current Status: Active Working Group > >> Chair(s): > >> Robert Sparks > >> Hisham Khartabil > >> Real-time Applications and Infrastructure Area Director(s): > >> Jon Peterson > >> Cullen Jennings > >> Real-time Applications and Infrastructure Area Advisor: > >> Jon Peterson > >> Technical Advisor(s): > >> Jon Peterson > >> Mailing Lists: > >> General Discussion: simple@ietf.org > >> To Subscribe: simple-request@ietf.org > >> In Body: subscribe > >> Archive: http://www.ietf.org/mail-archive/web/simple/index.html > >> Description of Working Group: > >> This working group focuses on the application of the Session > >> Initiation > >> Protocol (SIP, RFC 3261) to the suite of services collectively > >> known as > >> instant messaging and presence (IMP). The IETF has committed to > >> producing an interoperable standard for these services compliant > >> to the requirements for IM outlined in RFC 2779 (including the > >> security and privacy requirements there) and in the Common > >> Presence and Instant Messaging (CPIM) specification, developed > >> within the IMPP working group. As the most common services for > >> which SIP is used share quite a bit in common with IMP, the > >> adaptation of SIP to IMP seems a natural choice given the > >> widespread support for (and relative maturity of) the > >> SIP standard. > >> This group has completed the majority of its primary goals and > >> will focus on the remaining tasks documented here and concluding. > >> Any proposed new work should be socialized with the chairs and AD > >> early to determine if this WG is an appropriate venue. > >> The primary remaining work of this group will be to complete: > >> 1. The MSRP proposed standard mechanism for transporting sessions of > >> messages initiated using the SIP, compliant to the requirments of > >> RFC 2779, CPIM and BCP 41. > >> 2. The XCAP framework for representing and carrying configuration and > >> policy information in SIMPLE systems. > >> 3. A mechanism for representing partial changes (patches) to XML > >> documents and extensions to the SIMPLE publication and > >> notification mechanisms to convey these partial changes. > >> 4. A mechanism for initiating and managing Instant Message group > >> chat. > >> 5. An annotated overview of the SIMPLE protocol definition documents. > >> Any SIP extensions proposed in the course of this development > >> will, after a last call process, be transferred to the SIP WG for > >> consideration as formal SIP extensions. > >> Any mechanisms created for managing Instant Message group chat are > >> intended to provide a bridge to the conferencing protocols that > >> will be defined in XCON. They will be limited in scope to address > >> only simple Instant Message chat with nicknames and will not attempt > >> to address complex conferencing concepts such as sidebars. Their > >> design must anticipate operating in conjunction with the > >> conferencing protocols XCON is working towards. > >> The working group will work within the framework for presence and IM > >> described in RFC 2778. The extensions it defines must also be > >> compliant with the SIP processes for extensions. The group cannot > >> modify baseline SIP behavior or define a new version of SIP for IM > >> and presence. If the group determines that any capabilities > >> requiring an extension to SIP are needed, the group will seek to > >> define such > >> extensions within the SIP working group, and then use them here. > >> Goals and Milestones: > >> Done Submission of event package for presence to IESG for > >> publication as Proposed Standard > >> Done Submission of watcher information drafts to IESG for > >> publication as Proposed Standards > >> Done Submission of proposed event list mechanism to the SIP > >> working group Done Submission of requirements for event publishing > >> to the IESG for > >> publication as Proposed Standard > >> Done Submission of proposed mechanism for event publishing to the SIP > >> working group > >> Done Submission of SIMPLE PIDF profile to IESG for publication as > >> Proposed Standard > >> Done Submission of base XCAP draft to IESG for publication as > >> Proposed > >> Standard > >> Done Submission of indication of instant message preparation using > >> SIP to IESG for publication as a Proposed Standard > >> Done Submission of XCAP usage for manipulation of presence document > >> content > >> Done Submission of XCAP usage for setting presence authorization > >> to IESG for publication as Proposed Standard > >> Done Submission of Filtering mechanisms to IESG for publication as a > >> Proposed Standard > >> Done Submission of instant messaging session draft to IESG for > >> publication as a Proposed Standard > >> Done Submission of instant messaging session relay drafts to IESG for > >> publication as Proposed Standards > >> Done Submission of Partial Notification mechanism to IESG for > >> publication as a Proposed Standard > >> Feb 2007 Submission of an Instant Message Disposition Notification > >> mechanism to the IESG for publication as a Proposed Standard > >> Feb 2007 Submission of XCAP event package to IESG or appropriate > >> working group targeting publication as Proposed Standard > >> Feb 2007 Submission of proposed mechanisms meeting the advanced > >> messaging requirements to the IESG or appropriate working group > >> Mar 2007 Submission of a performance and scalability analysis of the > >> SIMPLE presence mechanisms to the IESG for publication as > >> Informational > >> Jun 2007 Submission of SIMPLE protocol annotated overview draft to > >> IESG > >> for publication as Informational > >> Aug 2007 Submission of proposed mechanisms for initiating and > >> managing > >> Instant Message group chat to the IESG for publication as Proposed > >> Standard > >> Aug 2007 Conclusion of SIMPLE > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 30 22:43:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC6MR-000856-Oq; Tue, 30 Jan 2007 22:42:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC6MQ-00084q-Cw for simple@ietf.org; Tue, 30 Jan 2007 22:42:14 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC6MO-000783-Qn for simple@ietf.org; Tue, 30 Jan 2007 22:42:14 -0500 Received: from [10.0.1.3] (adsl-68-94-3-195.dsl.rcsntx.swbell.net [68.94.3.195]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l0V3g9ne014356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Jan 2007 21:42:10 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: <66cd252f0701301743ycc944cfhbee8817f21aa506b@mail.gmail.com> References: <45BFC36C.4060304@cisco.com> <66cd252f0701301743ycc944cfhbee8817f21aa506b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1E3C1F6F-1497-4C1E-9336-934665BD9F87@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) Date: Tue, 30 Jan 2007 21:42:10 -0600 To: "Hisham Khartabil" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 68.94.3.195 is authenticated by a trusted mechanism) X-Spam-Score: 0.5 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: Paul Kyzivat , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org No, the June milestone is fine with me. I just wanted to make sure we didn't forget it. I did not originally make the connection, but it makes sense on a re-read. On Jan 30, 2007, at 7:43 PM, Hisham Khartabil wrote: > I believe this was to be put into the June milestone. But I guess Ben > and Paul want to see it as one of the primary milestones listed. > > Regards, > Hisham > > On 31/01/07, Ben Campbell wrote: >> I also remember that being brought up, and also don't remember the >> outcome ;-) >> >> On Jan 30, 2007, at 4:15 PM, Paul Kyzivat wrote: >> >> > Wasn't there some talk of a need to specify how to choose between >> > MESSAGE and MSRP, and/or to transition between them in support of a >> > single conversation? >> > >> > E.g. send a MESSAGE because there may never be a conversation, but >> > then INVITE with an MSRP session to continue the conversation. The >> > need here would be for a way to tie these things together so it is >> > clear that they are part of the same conversation. There are >> > obviously issues with involving the same pair of UAs in both. >> > >> > I seem to recall this was discussed at some point, but I'm not sure >> > and if so I don't remember the outcome. >> > >> > Paul >> > >> > IESG Secretary wrote: >> >> A new charter for the SIP for Instant Messaging and Presence >> >> Leveraging >> >> Extensions (simple) working group in the Real-time Applications >> and >> >> Infrastructure Area of the IETF is being considered. The draft >> >> charter is provided below for your review and comment. >> >> Review time is one week. >> >> The IETF Secretariat >> >> +++ >> >> SIP for Instant Messaging and Presence Leveraging Extensions >> (simple) >> >> >> ===================================================================== >> >> = >> >> Last Modified: 2007-1-24 >> >> Current Status: Active Working Group >> >> Chair(s): >> >> Robert Sparks >> >> Hisham Khartabil >> >> Real-time Applications and Infrastructure Area Director(s): >> >> Jon Peterson >> >> Cullen Jennings >> >> Real-time Applications and Infrastructure Area Advisor: >> >> Jon Peterson >> >> Technical Advisor(s): >> >> Jon Peterson >> >> Mailing Lists: >> >> General Discussion: simple@ietf.org >> >> To Subscribe: simple-request@ietf.org >> >> In Body: subscribe >> >> Archive: http://www.ietf.org/mail-archive/web/simple/index.html >> >> Description of Working Group: >> >> This working group focuses on the application of the Session >> >> Initiation >> >> Protocol (SIP, RFC 3261) to the suite of services collectively >> >> known as >> >> instant messaging and presence (IMP). The IETF has committed to >> >> producing an interoperable standard for these services compliant >> >> to the requirements for IM outlined in RFC 2779 (including the >> >> security and privacy requirements there) and in the Common >> >> Presence and Instant Messaging (CPIM) specification, developed >> >> within the IMPP working group. As the most common services for >> >> which SIP is used share quite a bit in common with IMP, the >> >> adaptation of SIP to IMP seems a natural choice given the >> >> widespread support for (and relative maturity of) the >> >> SIP standard. >> >> This group has completed the majority of its primary goals and >> >> will focus on the remaining tasks documented here and concluding. >> >> Any proposed new work should be socialized with the chairs and AD >> >> early to determine if this WG is an appropriate venue. >> >> The primary remaining work of this group will be to complete: >> >> 1. The MSRP proposed standard mechanism for transporting >> sessions of >> >> messages initiated using the SIP, compliant to the requirments of >> >> RFC 2779, CPIM and BCP 41. >> >> 2. The XCAP framework for representing and carrying >> configuration and >> >> policy information in SIMPLE systems. >> >> 3. A mechanism for representing partial changes (patches) to XML >> >> documents and extensions to the SIMPLE publication and >> >> notification mechanisms to convey these partial changes. >> >> 4. A mechanism for initiating and managing Instant Message group >> >> chat. >> >> 5. An annotated overview of the SIMPLE protocol definition >> documents. >> >> Any SIP extensions proposed in the course of this development >> >> will, after a last call process, be transferred to the SIP WG for >> >> consideration as formal SIP extensions. >> >> Any mechanisms created for managing Instant Message group chat are >> >> intended to provide a bridge to the conferencing protocols that >> >> will be defined in XCON. They will be limited in scope to address >> >> only simple Instant Message chat with nicknames and will not >> attempt >> >> to address complex conferencing concepts such as sidebars. Their >> >> design must anticipate operating in conjunction with the >> >> conferencing protocols XCON is working towards. >> >> The working group will work within the framework for presence >> and IM >> >> described in RFC 2778. The extensions it defines must also be >> >> compliant with the SIP processes for extensions. The group cannot >> >> modify baseline SIP behavior or define a new version of SIP for IM >> >> and presence. If the group determines that any capabilities >> >> requiring an extension to SIP are needed, the group will seek to >> >> define such >> >> extensions within the SIP working group, and then use them here. >> >> Goals and Milestones: >> >> Done Submission of event package for presence to IESG for >> >> publication as Proposed Standard >> >> Done Submission of watcher information drafts to IESG for >> >> publication as Proposed Standards >> >> Done Submission of proposed event list mechanism to the SIP >> >> working group Done Submission of requirements for event publishing >> >> to the IESG for >> >> publication as Proposed Standard >> >> Done Submission of proposed mechanism for event publishing to >> the SIP >> >> working group >> >> Done Submission of SIMPLE PIDF profile to IESG for publication as >> >> Proposed Standard >> >> Done Submission of base XCAP draft to IESG for publication as >> >> Proposed >> >> Standard >> >> Done Submission of indication of instant message preparation using >> >> SIP to IESG for publication as a Proposed Standard >> >> Done Submission of XCAP usage for manipulation of presence >> document >> >> content >> >> Done Submission of XCAP usage for setting presence authorization >> >> to IESG for publication as Proposed Standard >> >> Done Submission of Filtering mechanisms to IESG for publication >> as a >> >> Proposed Standard >> >> Done Submission of instant messaging session draft to IESG for >> >> publication as a Proposed Standard >> >> Done Submission of instant messaging session relay drafts to >> IESG for >> >> publication as Proposed Standards >> >> Done Submission of Partial Notification mechanism to IESG for >> >> publication as a Proposed Standard >> >> Feb 2007 Submission of an Instant Message Disposition Notification >> >> mechanism to the IESG for publication as a Proposed Standard >> >> Feb 2007 Submission of XCAP event package to IESG or appropriate >> >> working group targeting publication as Proposed Standard >> >> Feb 2007 Submission of proposed mechanisms meeting the advanced >> >> messaging requirements to the IESG or appropriate working group >> >> Mar 2007 Submission of a performance and scalability analysis >> of the >> >> SIMPLE presence mechanisms to the IESG for publication as >> >> Informational >> >> Jun 2007 Submission of SIMPLE protocol annotated overview draft to >> >> IESG >> >> for publication as Informational >> >> Aug 2007 Submission of proposed mechanisms for initiating and >> >> managing >> >> Instant Message group chat to the IESG for publication as Proposed >> >> Standard >> >> Aug 2007 Conclusion of SIMPLE >> >> _______________________________________________ >> >> Simple mailing list >> >> Simple@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/simple >> > >> > _______________________________________________ >> > Simple mailing list >> > Simple@ietf.org >> > https://www1.ietf.org/mailman/listinfo/simple >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jan 30 23:16:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC6sT-0008RX-AW; Tue, 30 Jan 2007 23:15:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC6sS-0008RS-4a for simple@ietf.org; Tue, 30 Jan 2007 23:15:20 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC6sQ-0005Q5-LC for simple@ietf.org; Tue, 30 Jan 2007 23:15:20 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Jan 2007 23:15:19 -0500 X-IronPort-AV: i="4.13,259,1167627600"; d="scan'208"; a="112804151:sNHT60988652" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0V4FIKO004635; Tue, 30 Jan 2007 23:15:18 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0V4FIOA015886; Tue, 30 Jan 2007 23:15:18 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 23:15:18 -0500 Received: from [10.86.243.83] ([10.86.243.83]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 23:15:17 -0500 Message-ID: <45C017D4.2030709@cisco.com> Date: Tue, 30 Jan 2007 23:15:16 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) References: <45BFC36C.4060304@cisco.com> <66cd252f0701301743ycc944cfhbee8817f21aa506b@mail.gmail.com> <1E3C1F6F-1497-4C1E-9336-934665BD9F87@nostrum.com> In-Reply-To: <1E3C1F6F-1497-4C1E-9336-934665BD9F87@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2007 04:15:17.0489 (UTC) FILETIME=[6A03D610:01C744EE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8907; t=1170216918; x=1171080918; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20Internal=20WG=20Review=3A=20Recharter=20of =20SIP=20for=20Instant=20Messaging=0A=20and=20Presence=20Leveraging=20Exte nsions=20(simple) |Sender:=20 |To:=20Ben=20Campbell=20; bh=9eN+OcxdyxBdOuJnktxN7DPlDmjPR+jrGIpiM6jFqXs=; b=XnhdRi4tBNsKvenpGd0ZuzfnCTVzaZXl/v9aUTRaPiQQCdUVeYAntKvL0T62Ts8hVV17vHVM Yqejspmmyrd8cm7Hbou6PGCnOp6SRUqMDs65QjSKl248sOceI6ufuX8R; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Ben Campbell wrote: > No, the June milestone is fine with me. I just wanted to make sure we > didn't forget it. I did not originally make the connection, but it makes > sense on a re-read. I also don't care much whether there is an explicit milestone. I was just trying to understand if that is still on the table. Thanks, Paul > On Jan 30, 2007, at 7:43 PM, Hisham Khartabil wrote: > >> I believe this was to be put into the June milestone. But I guess Ben >> and Paul want to see it as one of the primary milestones listed. >> >> Regards, >> Hisham >> >> On 31/01/07, Ben Campbell wrote: >>> I also remember that being brought up, and also don't remember the >>> outcome ;-) >>> >>> On Jan 30, 2007, at 4:15 PM, Paul Kyzivat wrote: >>> >>> > Wasn't there some talk of a need to specify how to choose between >>> > MESSAGE and MSRP, and/or to transition between them in support of a >>> > single conversation? >>> > >>> > E.g. send a MESSAGE because there may never be a conversation, but >>> > then INVITE with an MSRP session to continue the conversation. The >>> > need here would be for a way to tie these things together so it is >>> > clear that they are part of the same conversation. There are >>> > obviously issues with involving the same pair of UAs in both. >>> > >>> > I seem to recall this was discussed at some point, but I'm not sure >>> > and if so I don't remember the outcome. >>> > >>> > Paul >>> > >>> > IESG Secretary wrote: >>> >> A new charter for the SIP for Instant Messaging and Presence >>> >> Leveraging >>> >> Extensions (simple) working group in the Real-time Applications and >>> >> Infrastructure Area of the IETF is being considered. The draft >>> >> charter is provided below for your review and comment. >>> >> Review time is one week. >>> >> The IETF Secretariat >>> >> +++ >>> >> SIP for Instant Messaging and Presence Leveraging Extensions (simple) >>> >> ===================================================================== >>> >> = >>> >> Last Modified: 2007-1-24 >>> >> Current Status: Active Working Group >>> >> Chair(s): >>> >> Robert Sparks >>> >> Hisham Khartabil >>> >> Real-time Applications and Infrastructure Area Director(s): >>> >> Jon Peterson >>> >> Cullen Jennings >>> >> Real-time Applications and Infrastructure Area Advisor: >>> >> Jon Peterson >>> >> Technical Advisor(s): >>> >> Jon Peterson >>> >> Mailing Lists: >>> >> General Discussion: simple@ietf.org >>> >> To Subscribe: simple-request@ietf.org >>> >> In Body: subscribe >>> >> Archive: http://www.ietf.org/mail-archive/web/simple/index.html >>> >> Description of Working Group: >>> >> This working group focuses on the application of the Session >>> >> Initiation >>> >> Protocol (SIP, RFC 3261) to the suite of services collectively >>> >> known as >>> >> instant messaging and presence (IMP). The IETF has committed to >>> >> producing an interoperable standard for these services compliant >>> >> to the requirements for IM outlined in RFC 2779 (including the >>> >> security and privacy requirements there) and in the Common >>> >> Presence and Instant Messaging (CPIM) specification, developed >>> >> within the IMPP working group. As the most common services for >>> >> which SIP is used share quite a bit in common with IMP, the >>> >> adaptation of SIP to IMP seems a natural choice given the >>> >> widespread support for (and relative maturity of) the >>> >> SIP standard. >>> >> This group has completed the majority of its primary goals and >>> >> will focus on the remaining tasks documented here and concluding. >>> >> Any proposed new work should be socialized with the chairs and AD >>> >> early to determine if this WG is an appropriate venue. >>> >> The primary remaining work of this group will be to complete: >>> >> 1. The MSRP proposed standard mechanism for transporting sessions of >>> >> messages initiated using the SIP, compliant to the requirments of >>> >> RFC 2779, CPIM and BCP 41. >>> >> 2. The XCAP framework for representing and carrying configuration and >>> >> policy information in SIMPLE systems. >>> >> 3. A mechanism for representing partial changes (patches) to XML >>> >> documents and extensions to the SIMPLE publication and >>> >> notification mechanisms to convey these partial changes. >>> >> 4. A mechanism for initiating and managing Instant Message group >>> >> chat. >>> >> 5. An annotated overview of the SIMPLE protocol definition documents. >>> >> Any SIP extensions proposed in the course of this development >>> >> will, after a last call process, be transferred to the SIP WG for >>> >> consideration as formal SIP extensions. >>> >> Any mechanisms created for managing Instant Message group chat are >>> >> intended to provide a bridge to the conferencing protocols that >>> >> will be defined in XCON. They will be limited in scope to address >>> >> only simple Instant Message chat with nicknames and will not attempt >>> >> to address complex conferencing concepts such as sidebars. Their >>> >> design must anticipate operating in conjunction with the >>> >> conferencing protocols XCON is working towards. >>> >> The working group will work within the framework for presence and IM >>> >> described in RFC 2778. The extensions it defines must also be >>> >> compliant with the SIP processes for extensions. The group cannot >>> >> modify baseline SIP behavior or define a new version of SIP for IM >>> >> and presence. If the group determines that any capabilities >>> >> requiring an extension to SIP are needed, the group will seek to >>> >> define such >>> >> extensions within the SIP working group, and then use them here. >>> >> Goals and Milestones: >>> >> Done Submission of event package for presence to IESG for >>> >> publication as Proposed Standard >>> >> Done Submission of watcher information drafts to IESG for >>> >> publication as Proposed Standards >>> >> Done Submission of proposed event list mechanism to the SIP >>> >> working group Done Submission of requirements for event publishing >>> >> to the IESG for >>> >> publication as Proposed Standard >>> >> Done Submission of proposed mechanism for event publishing to the SIP >>> >> working group >>> >> Done Submission of SIMPLE PIDF profile to IESG for publication as >>> >> Proposed Standard >>> >> Done Submission of base XCAP draft to IESG for publication as >>> >> Proposed >>> >> Standard >>> >> Done Submission of indication of instant message preparation using >>> >> SIP to IESG for publication as a Proposed Standard >>> >> Done Submission of XCAP usage for manipulation of presence document >>> >> content >>> >> Done Submission of XCAP usage for setting presence authorization >>> >> to IESG for publication as Proposed Standard >>> >> Done Submission of Filtering mechanisms to IESG for publication as a >>> >> Proposed Standard >>> >> Done Submission of instant messaging session draft to IESG for >>> >> publication as a Proposed Standard >>> >> Done Submission of instant messaging session relay drafts to IESG for >>> >> publication as Proposed Standards >>> >> Done Submission of Partial Notification mechanism to IESG for >>> >> publication as a Proposed Standard >>> >> Feb 2007 Submission of an Instant Message Disposition Notification >>> >> mechanism to the IESG for publication as a Proposed Standard >>> >> Feb 2007 Submission of XCAP event package to IESG or appropriate >>> >> working group targeting publication as Proposed Standard >>> >> Feb 2007 Submission of proposed mechanisms meeting the advanced >>> >> messaging requirements to the IESG or appropriate working group >>> >> Mar 2007 Submission of a performance and scalability analysis of the >>> >> SIMPLE presence mechanisms to the IESG for publication as >>> >> Informational >>> >> Jun 2007 Submission of SIMPLE protocol annotated overview draft to >>> >> IESG >>> >> for publication as Informational >>> >> Aug 2007 Submission of proposed mechanisms for initiating and >>> >> managing >>> >> Instant Message group chat to the IESG for publication as Proposed >>> >> Standard >>> >> Aug 2007 Conclusion of SIMPLE >>> >> _______________________________________________ >>> >> Simple mailing list >>> >> Simple@ietf.org >>> >> https://www1.ietf.org/mailman/listinfo/simple >>> > >>> > _______________________________________________ >>> > Simple mailing list >>> > Simple@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 31 04:44:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBzK-0000ge-Hq; Wed, 31 Jan 2007 04:42:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBzJ-0000fH-5S for simple@ietf.org; Wed, 31 Jan 2007 04:42:45 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCBuB-0007mr-A0 for simple@ietf.org; Wed, 31 Jan 2007 04:37:30 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0V9YL5c025629; Wed, 31 Jan 2007 11:34:37 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 11:37:05 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 11:37:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Internal WG Review: Recharter of SIP for InstantMessaging and Presence Leveraging Extensions (simple) Date: Wed, 31 Jan 2007 11:37:05 +0200 Message-ID: In-Reply-To: <45BFC36C.4060304@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Internal WG Review: Recharter of SIP for InstantMessaging and Presence Leveraging Extensions (simple) Thread-Index: AcdEvKJkg/fhcoQdTvOuJtUsSh2CtAAXM44w References: <45BFC36C.4060304@cisco.com> From: To: , X-OriginalArrivalTime: 31 Jan 2007 09:37:05.0221 (UTC) FILETIME=[5E51EF50:01C7451B] X-Nokia-AV: Clean X-Spam-Score: 0.7 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, Yes, I think this is a feature that would be needed in practice. Having two messaging mechanisms without clear guidance on how they relate to each other is going to cause interoperability issues - if not on the protocol level then at least on the UI-to-UI or user-to-user level. Another thing is that there should be some kind of specification/guideline on how to actually deliver one-shot messages that are larger than 1300 bytes. One way is to use MSRP, another to do content indirection with MESSAGE. In MSRP the key is the ability for the sender to indicate (at least as a preference/hint) that the session is established for just sending a single message, not to open a conversation. This is wanted by providers who would like to be able to offer something similar to MMS service on top of a SIP infra.=20 SIMPLE WG has not been very enthusiastic about this in the past, so I think OMA has already defined a particular mechanism for MSRP. If everyone who is interested in this is anyway involved in OMA, as it seems, there would be not much value for IETF to do anything about it. However, if there is real interest outside OMA, it would be useful to have some work in SIMPLE WG. Markus =20 >-----Original Message----- >From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 >Sent: 31 January, 2007 00:15 >To: simple@ietf.org >Subject: Re: [Simple] Internal WG Review: Recharter of SIP for=20 >InstantMessaging and Presence Leveraging Extensions (simple) > >Wasn't there some talk of a need to specify how to choose=20 >between MESSAGE and MSRP, and/or to transition between them in=20 >support of a single conversation? > >E.g. send a MESSAGE because there may never be a conversation,=20 >but then INVITE with an MSRP session to continue the=20 >conversation. The need here would be for a way to tie these=20 >things together so it is clear that they are part of the same=20 >conversation. There are obviously issues with involving the=20 >same pair of UAs in both. > >I seem to recall this was discussed at some point, but I'm not=20 >sure and if so I don't remember the outcome. > > Paul > >IESG Secretary wrote: >> A new charter for the SIP for Instant Messaging and Presence=20 >> Leveraging Extensions (simple) working group in the Real-time=20 >> Applications and Infrastructure Area of the IETF is being=20 >considered.=20 >> The draft charter is provided below for your review and comment. >>=20 >> Review time is one week. >>=20 >> The IETF Secretariat >>=20 >> +++ >>=20 >> SIP for Instant Messaging and Presence Leveraging Extensions=20 >(simple)=20 >>=20 >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Last Modified: 2007-1-24 >>=20 >> Current Status: Active Working Group >>=20 >> Chair(s): >> Robert Sparks >> Hisham Khartabil >>=20 >>=20 >> Real-time Applications and Infrastructure Area Director(s): >> Jon Peterson Cullen Jennings=20 >> >>=20 >> Real-time Applications and Infrastructure Area Advisor: >> Jon Peterson >>=20 >> Technical Advisor(s): >> Jon Peterson >>=20 >> Mailing Lists: >> General Discussion: simple@ietf.org >> To Subscribe: simple-request@ietf.org >> In Body: subscribe >> Archive: http://www.ietf.org/mail-archive/web/simple/index.html >>=20 >> Description of Working Group: >>=20 >> This working group focuses on the application of the Session=20 >> Initiation Protocol (SIP, RFC 3261) to the suite of services=20 >> collectively known as instant messaging and presence (IMP). The IETF=20 >> has committed to producing an interoperable standard for these=20 >> services compliant to the requirements for IM outlined in RFC 2779=20 >> (including the security and privacy requirements there) and in the=20 >> Common Presence and Instant Messaging (CPIM) specification,=20 >developed=20 >> within the IMPP working group. As the most common services for which=20 >> SIP is used share quite a bit in common with IMP, the adaptation of=20 >> SIP to IMP seems a natural choice given the widespread support for=20 >> (and relative maturity of) the SIP standard. >>=20 >> This group has completed the majority of its primary goals and will=20 >> focus on the remaining tasks documented here and concluding. Any=20 >> proposed new work should be socialized with the chairs and=20 >AD early to=20 >> determine if this WG is an appropriate venue. >>=20 >> The primary remaining work of this group will be to complete: >>=20 >> 1. The MSRP proposed standard mechanism for transporting sessions of=20 >> messages initiated using the SIP, compliant to the=20 >requirments of RFC=20 >> 2779, CPIM and BCP 41. >>=20 >> 2. The XCAP framework for representing and carrying=20 >configuration and=20 >> policy information in SIMPLE systems. >>=20 >> 3. A mechanism for representing partial changes (patches) to XML=20 >> documents and extensions to the SIMPLE publication and notification=20 >> mechanisms to convey these partial changes. >>=20 >> 4. A mechanism for initiating and managing Instant Message=20 >group chat. >>=20 >> 5. An annotated overview of the SIMPLE protocol definition documents. >>=20 >> Any SIP extensions proposed in the course of this development will,=20 >> after a last call process, be transferred to the SIP WG for=20 >> consideration as formal SIP extensions. >>=20 >> Any mechanisms created for managing Instant Message group chat are=20 >> intended to provide a bridge to the conferencing protocols that will=20 >> be defined in XCON. They will be limited in scope to address only=20 >> simple Instant Message chat with nicknames and will not attempt to=20 >> address complex conferencing concepts such as sidebars. Their design=20 >> must anticipate operating in conjunction with the conferencing=20 >> protocols XCON is working towards. >>=20 >> The working group will work within the framework for presence and IM=20 >> described in RFC 2778. The extensions it defines must also be=20 >> compliant with the SIP processes for extensions. The group cannot=20 >> modify baseline SIP behavior or define a new version of SIP=20 >for IM and=20 >> presence. If the group determines that any capabilities requiring an=20 >> extension to SIP are needed, the group will seek to define such=20 >> extensions within the SIP working group, and then use them here. >>=20 >> Goals and Milestones: >> Done Submission of event package for presence to IESG for=20 >publication=20 >> as Proposed Standard Done Submission of watcher information=20 >drafts to=20 >> IESG for publication as Proposed Standards Done Submission=20 >of proposed=20 >> event list mechanism to the SIP working group Done Submission of=20 >> requirements for event publishing to the IESG for publication as=20 >> Proposed Standard Done Submission of proposed mechanism for event=20 >> publishing to the SIP working group Done Submission of SIMPLE PIDF=20 >> profile to IESG for publication as Proposed Standard Done Submission=20 >> of base XCAP draft to IESG for publication as Proposed Standard Done=20 >> Submission of indication of instant message preparation using SIP to=20 >> IESG for publication as a Proposed Standard Done Submission of XCAP=20 >> usage for manipulation of presence document content Done=20 >Submission of=20 >> XCAP usage for setting presence authorization to IESG for=20 >publication=20 >> as Proposed Standard Done Submission of Filtering mechanisms to IESG=20 >> for publication as a Proposed Standard Done Submission of instant=20 >> messaging session draft to IESG for publication as a=20 >Proposed Standard=20 >> Done Submission of instant messaging session relay drafts to=20 >IESG for=20 >> publication as Proposed Standards Done Submission of Partial=20 >> Notification mechanism to IESG for publication as a Proposed=20 >Standard=20 >> Feb 2007 Submission of an Instant Message Disposition Notification=20 >> mechanism to the IESG for publication as a Proposed Standard=20 >Feb 2007=20 >> Submission of XCAP event package to IESG or appropriate=20 >working group=20 >> targeting publication as Proposed Standard Feb 2007 Submission of=20 >> proposed mechanisms meeting the advanced messaging=20 >requirements to the=20 >> IESG or appropriate working group Mar 2007 Submission of a=20 >performance=20 >> and scalability analysis of the SIMPLE presence mechanisms=20 >to the IESG=20 >> for publication as Informational Jun 2007 Submission of SIMPLE=20 >> protocol annotated overview draft to IESG for publication as=20 >> Informational Aug 2007 Submission of proposed mechanisms for=20 >> initiating and managing Instant Message group chat to the IESG for=20 >> publication as Proposed Standard Aug 2007 Conclusion of SIMPLE >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >>=20 > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jan 31 09:25:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGON-0003MG-8i; Wed, 31 Jan 2007 09:24:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGOL-0003M3-BW for simple@ietf.org; Wed, 31 Jan 2007 09:24:53 -0500 Received: from mtagate8.de.ibm.com ([195.212.29.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGOJ-0006z5-7o for simple@ietf.org; Wed, 31 Jan 2007 09:24:53 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate8.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0VEOoCk131206 for ; Wed, 31 Jan 2007 14:24:50 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0VEOofg1294420 for ; Wed, 31 Jan 2007 15:24:50 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0VEOotY029396 for ; Wed, 31 Jan 2007 15:24:50 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0VEOmfe029291 for ; Wed, 31 Jan 2007 15:24:50 +0100 In-Reply-To: To: simple@ietf.org Subject: Re: [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Wed, 31 Jan 2007 15:10:16 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF882 | September 26, 2006) at 31/01/2007 16:24:49, Serialize complete at 31/01/2007 16:24:49 X-Spam-Score: 0.8 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1004551699==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1004551699== Content-Type: multipart/alternative; boundary="=_alternative 0048768CC2257274_=" This is a multipart message in MIME format. --=_alternative 0048768CC2257274_= Content-Type: text/plain; charset="US-ASCII" Regarding: Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational Assuming that we will find things that need to be improved in e.g. 3265 what will be the mechanism for the improvements? Via SIP WG? --Avshalom IESG Secretary 30/01/2007 23:33 To iesg@ietf.org, iab@iab.org, simple@ietf.org, Robert Sparks , Hisham Khartabil cc Subject [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) A new charter for the SIP for Instant Messaging and Presence Leveraging Extensions (simple) working group in the Real-time Applications and Infrastructure Area of the IETF is being considered. The draft charter is provided below for your review and comment. Review time is one week. The IETF Secretariat +++ SIP for Instant Messaging and Presence Leveraging Extensions (simple) ====================================================================== Last Modified: 2007-1-24 Current Status: Active Working Group Chair(s): Robert Sparks Hisham Khartabil Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson Technical Advisor(s): Jon Peterson Mailing Lists: General Discussion: simple@ietf.org To Subscribe: simple-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/simple/index.html Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. This group has completed the majority of its primary goals and will focus on the remaining tasks documented here and concluding. Any proposed new work should be socialized with the chairs and AD early to determine if this WG is an appropriate venue. The primary remaining work of this group will be to complete: 1. The MSRP proposed standard mechanism for transporting sessions of messages initiated using the SIP, compliant to the requirments of RFC 2779, CPIM and BCP 41. 2. The XCAP framework for representing and carrying configuration and policy information in SIMPLE systems. 3. A mechanism for representing partial changes (patches) to XML documents and extensions to the SIMPLE publication and notification mechanisms to convey these partial changes. 4. A mechanism for initiating and managing Instant Message group chat. 5. An annotated overview of the SIMPLE protocol definition documents. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions. Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will be defined in XCON. They will be limited in scope to address only simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing protocols XCON is working towards. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here. Goals and Milestones: Done Submission of event package for presence to IESG for publication as Proposed Standard Done Submission of watcher information drafts to IESG for publication as Proposed Standards Done Submission of proposed event list mechanism to the SIP working group Done Submission of requirements for event publishing to the IESG for publication as Proposed Standard Done Submission of proposed mechanism for event publishing to the SIP working group Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard Done Submission of base XCAP draft to IESG for publication as Proposed Standard Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard Done Submission of XCAP usage for manipulation of presence document content Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard Done Submission of Filtering mechanisms to IESG for publication as a Proposed Standard Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard Done Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard Feb 2007 Submission of an Instant Message Disposition Notification mechanism to the IESG for publication as a Proposed Standard Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG for publication as Informational Aug 2007 Submission of proposed mechanisms for initiating and managing Instant Message group chat to the IESG for publication as Proposed Standard Aug 2007 Conclusion of SIMPLE _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=_alternative 0048768CC2257274_= Content-Type: text/html; charset="US-ASCII"
Regarding:

Mar 2007 Submission of a performance and scalability analysis of the
SIMPLE presence mechanisms to the IESG for publication as Informational

Assuming that we will find things that need to be improved in e.g. 3265
what will be the mechanism for the improvements? Via SIP WG?

--Avshalom


IESG Secretary <iesg-secretary@ietf.org>

30/01/2007 23:33

To
iesg@ietf.org, iab@iab.org, simple@ietf.org, Robert Sparks <RjS@estacado.net>, Hisham Khartabil <hisham.khartabil@gmail.com>
cc
Subject
[Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple)





A new charter for the SIP for Instant Messaging and Presence Leveraging
Extensions (simple) working group in the Real-time Applications and
Infrastructure Area of the IETF is being considered. The draft charter
is provided below for your review and comment.

Review time is one week.

The IETF Secretariat

+++

SIP for Instant Messaging and Presence Leveraging Extensions (simple)
======================================================================

Last Modified: 2007-1-24

Current Status: Active Working Group

Chair(s):
Robert Sparks <RjS@estacado.net>
Hisham Khartabil <hisham.khartabil@gmail.com>


Real-time Applications and Infrastructure Area Director(s):
Jon Peterson <jon.peterson@neustar.biz>
Cullen Jennings <fluffy@cisco.com>

Real-time Applications and Infrastructure Area Advisor:
Jon Peterson <jon.peterson@neustar.biz&From simple-bounces@ietf.org Wed Jan 31 09:25:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGON-0003MG-8i; Wed, 31 Jan 2007 09:24:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGOL-0003M3-BW for simple@ietf.org; Wed, 31 Jan 2007 09:24:53 -0500 Received: from mtagate8.de.ibm.com ([195.212.29.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGOJ-0006z5-7o for simple@ietf.org; Wed, 31 Jan 2007 09:24:53 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate8.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0VEOoCk131206 for ; Wed, 31 Jan 2007 14:24:50 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0VEOofg1294420 for ; Wed, 31 Jan 2007 15:24:50 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0VEOotY029396 for ; Wed, 31 Jan 2007 15:24:50 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0VEOmfe029291 for ; Wed, 31 Jan 2007 15:24:50 +0100 In-Reply-To: To: simple@ietf.org Subject: Re: [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Wed, 31 Jan 2007 15:10:16 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF882 | September 26, 2006) at 31/01/2007 16:24:49, Serialize complete at 31/01/2007 16:24:49 X-Spam-Score: 0.8 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1004551699==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1004551699== Content-Type: multipart/alternative; boundary="=_alternative 0048768CC2257274_=" This is a multipart message in MIME format. --=_alternative 0048768CC2257274_= Content-Type: text/plain; charset="US-ASCII" Regarding: Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational Assuming that we will find things that need to be improved in e.g. 3265 what will be the mechanism for the improvements? Via SIP WG? --Avshalom IESG Secretary 30/01/2007 23:33 To iesg@ietf.org, iab@iab.org, simple@ietf.org, Robert Sparks , Hisham Khartabil cc Subject [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) A new charter for the SIP for Instant Messaging and Presence Leveraging Extensions (simple) working group in the Real-time Applications and Infrastructure Area of the IETF is being considered. The draft charter is provided below for your review and comment. Review time is one week. The IETF Secretariat +++ SIP for Instant Messaging and Presence Leveraging Extensions (simple) =========gt;

Technical Advisor(s):
Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:
General Discussion: simple@ietf.org
To Subscribe: simple-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/simple/index.html

Description of Working Group:

This working group focuses on the application of the Session Initiation
Protocol (SIP, RFC 3261) to the suite of services collectively known as
instant messaging and presence (IMP). The IETF has committed to
producing an interoperable standard for these services compliant to
the requirements for IM outlined in RFC 2779 (including the security
and privacy requirements there) and in the Common Presence and Instant
Messaging (CPIM) specification, developed within the IMPP working
group. As the most common services for which SIP is used share quite a
bit in common with IMP, the adaptation of SIP to IMP seems a natural
choice given the widespread support for (and relative maturity of) the
SIP standard.

This group has completed the majority of its primary goals and will
focus on the remaining tasks documented here and concluding. Any
proposed new work should be socialized with the chairs and AD early to
determine if this WG is an appropriate venue.

The primary remaining work of this group will be to complete:

1. The MSRP proposed standard mechanism for transporting sessions of
messages initiated using the SIP, compliant to the requirments of RFC
2779, CPIM and BCP 41.

2. The XCAP framework for representing and carrying configuration and
policy information in SIMPLE systems.

3. A mechanism for representing partial changes (patches) to XML
documents and extensions to the SIMPLE publication and notification
mechanisms to convey these partial changes.

4. A mechanism for initiating and managing Instant Message group chat.

5. An annotated overview of the SIMPLE protocol definition documents.

Any SIP extensions proposed in the course of this development will,
after a last call process, be transferred to the SIP WG for
consideration as formal SIP extensions.

Any mechanisms created for managing Instant Message group chat are
intended to provide a bridge to the conferencing protocols that will
be defined in XCON. They will be limited in scope to address only
simple Instant Message chat with nicknames and will not attempt
to address complex conferencing concepts such as sidebars. Their
design must anticipate operating in conjunction with the conferencing
protocols XCON is working towards.

The working group will work within the framework for presence and IM
described in RFC 2778. The extensions it defines must also be
compliant with the SIP processes for extensions. The group cannot
modify baseline SIP behavior or define a new version of SIP for IM and
presence. If the group determines that any capabilities requiring an
extension to SIP are needed, the group will seek to define such
extensions within the SIP working group, and then use them here.

Goals and Milestones:
Done Submission of event package for presence to IESG for publication as Proposed Standard
Done Submission of watcher information drafts to IESG for publication as Proposed Standards
Done Submission of proposed event list mechanism to the SIP working group
Done Submission of requirements for event publishing to the IESG for
publication as Proposed Standard
Done Submission of proposed mechanism for event publishing to the SIP
working group
Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard
Done Submission of base XCAP draft to IESG for publication as Proposed
Standard
Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard
Done Submission of XCAP usage for manipulati============================================================= Last Modified: 2007-1-24 Current Status: Active Working Group Chair(s): Robert Sparks Hisham Khartabil Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson Technical Advisor(s): Jon Peterson Mailing Lists: General Discussion: simple@ietf.org To Subscribe: simple-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/simple/index.html Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. This group has completed the majority of its primary goals and will focus on the remaining tasks documented here and concluding. Any proposed new work should be socialized with the chairs and AD early to determine if this WG is an appropriate venue. The primary remaining work of this group will be to complete: 1. The MSRP proposed standard mechanism for transporting sessions of messages initiated using the SIP, compliant to the requirments of RFC 2779, CPIM and BCP 41. 2. The XCAP framework for representing and carrying configuration and policy information in SIMPLE systems. 3. A mechanism for representing partial changes (patches) to XML documents and extensions to the SIMPLE publication and notification mechanisms to convey these partial changes. 4. A mechanism for initiating and managing Instant Message group chat. 5. An annotated overview of the SIMPLE protocol definition documents. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions. Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will be defined in XCON. They will be limited in scope to address only simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing protocols XCON is working towards. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here. Goals and Milestones: Done Submission of event package for presence to IESG for publication as Proposed Standard Done Submission of watcher information drafts to IESG for publication as Proposed Standards Done Submission of proposed event list mechanism to the SIP working group Done Submission of requirements for event publishing to the IESG for publication as Proposed Standard Done Submission of proposed mechanism for event publishing to the SIP working group Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard Done Submission of base XCAP draft to IESG for publication as Proposed Standard Done Submission of indication of inon of presence document
content
Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard
Done Submission of Filtering mechanisms to IESG for publication as a
Proposed Standard
Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard
Done Submission of instant messaging session relay drafts to IESG for
publication as Proposed Standards
Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard
Feb 2007 Submission of an Instant Message Disposition Notification
mechanism to the IESG for publication as a Proposed Standard
Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard
Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group
Mar 2007 Submission of a performance and scalability analysis of the
SIMPLE presence mechanisms to the IESG for publication as Informational
Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG
for publication as Informational
Aug 2007 Submission of proposed mechanisms for initiating and managing
Instant Message group chat to the IESG for publication as Proposed
Standard
Aug 2007 Conclusion of SIMPLE

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--=_alternative 0048768CC2257274_=-- --===============1004551699== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1004551699==-- From simple-bounces@ietf.org Wed Jan 31 09:25:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGOR-0003Mo-S3; Wed, 31 Jan 2007 09:24:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGOP-0003MS-Og for simple@ietf.org; Wed, 31 Jan 2007 09:24:57 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGON-00070S-Ne for simple@ietf.org; Wed, 31 Jan 2007 09:24:57 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0VEOsBa179644 for ; Wed, 31 Jan 2007 14:24:54 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0VEOsgm1634372 for ; Wed, 31 Jan 2007 15:24:54 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0VEOsb3016988 for ; Wed, 31 Jan 2007 15:24:54 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0VEOseL016963 for ; Wed, 31 Jan 2007 15:24:54 +0100 To: simple@ietf.org Subject: Re: [Simple] (Performance) Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Wed, 31 Jan 2007 16:05:25 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF882 | September 26, 2006) at 31/01/2007 16:24:53, Serialize complete at 31/01/2007 16:24:53 X-Spam-Score: 0.8 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 X-BeenThere: simple@ietf.org X-Mailmstant message preparation using SIP to IESG for publication as a Proposed Standard Done Submission of XCAP usage for manipulation of presence document content Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard Done Submission of Filtering mechanisms to IESG for publication as a Proposed Standard Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard Done Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard Feb 2007 Submission of an Instant Message Disposition Notification mechanism to the IESG for publication as a Proposed Standard Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG for publication as Informational Aug 2007 Submission of proposed mechanisms for initiating and managing Instant Message group chat to the IESG for publication as Proposed Standard Aug 2007 Conclusion of SIMPLE _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=_alternative 0048768CC2257274_= Content-Type: text/html; charset="US-ASCII"
Regarding:

Mar 2007 Submission of a performance and scalability analysis of the
SIMPLE presence mechanisms to the IESG for publication as Informational

Assuming that we will find things that need to be improved in e.g. 3265
what will be the mechanism for the improvements? Via SIP WG?

--Avshalom


IESG Secretary <iesg-secretary@ietf.org>

30/01/2007 23:33

To
iesg@ietf.org, iab@iab.org, simple@ietf.org, Robert Sparks <RjS@estacado.net>, Hisham Khartabil <hisham.khartabil@gmail.com>
cc
Subject
[Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple)





A new charter for the SIP for Instant Messaging and Presence Leveraging
Extensions (simple) working group in the Real-time Applications and
Infrastructure Area of the IETF is being considered. The draft charter
is provided below for your review and comment.

Review time is one week.

The IETF Secretariat

+++

SIP for Instant Messaging and Presence Leveraging Extensions (simple)
======================================================================

Last Modified: 2007-1-24

Current Status: Active Working Group

Chair(s):
Robert Sparks <RjS@estacado.net>
Hisham Khartabil <hisham.khartabil@gmail.com>


Real-time Applications and Infrastructure Area Director(s):
Jon Peterson <jon.peterson@neustar.biz>
Cullen Jennings <fluffy@cisco.com>

Real-time Applications and Infrastructure Area Advisor:
Jon Peterson <jon.peterson@neustar.biz&an-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0618136998==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0618136998== Content-Type: multipart/alternative; boundary="=_alternative 004D8144C2257274_=" This is a multipart message in MIME format. --=_alternative 004D8144C2257274_= Content-Type: text/plain; charset="US-ASCII" Regarding: Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational Assuming that we will find things that need to be improved in e.g. 3265 what will be the mechanism for the improvements? Via SIP WG? --Avshalom IESG Secretary 30/01/2007 23:33 To iesg@ietf.org, iab@iab.org, simple@ietf.org, Robert Sparks , Hisham Khartabil cc Subject [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) A new charter for the SIP for Instant Messaging and Presence Leveraging Extensions (simple) working group in the Real-time Applications and Infrastructure Area of the IETF is being considered. The draft charter is provided below for your review and comment. Review time is one week. The IETF Secretariat +++ SIP for Instant Messaging and Presence Leveraging Extensions (simple) ====================================================================== Last Modified: 2007-1-24 Current Status: Active Working Group Chair(s): Robert Sparks Hisham Khartabil Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson Technical Advisor(s): Jon Peterson Mailing Lists: General Discussion: simple@ietf.org To Subscribe: simple-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/simple/index.html Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. This group has completed the majority of its primary goals and will focus on the remaining tasks documented here and concluding. Any proposed new work should be socialized with the chairs and AD early to determine if this WG is an appropriate venue. The primary remaining work of this group will be to complete: 1. The MSRP proposed standard mechanism for transporting sessions of messages initiated using the SIP, compliant to the requirments of RFC 2779, CPIM and BCP 41. 2. The XCAP framework for representing and carrying configuration and policy information in SIMPLE systems. 3. A mechanism for representing partial changes (patches) to XML documents and extensions to the SIMPLE publication and notification mechanisms to convey these gt;

Technical Advisor(s):
Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:
General Discussion: simple@ietf.org
To Subscribe: simple-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/simple/index.html

Description of Working Group:

This working group focuses on the application of the Session Initiation
Protocol (SIP, RFC 3261) to the suite of services collectively known as
instant messaging and presence (IMP). The IETF has committed to
producing an interoperable standard for these services compliant to
the requirements for IM outlined in RFC 2779 (including the security
and privacy requirements there) and in the Common Presence and Instant
Messaging (CPIM) specification, developed within the IMPP working
group. As the most common services for which SIP is used share quite a
bit in common with IMP, the adaptation of SIP to IMP seems a natural
choice given the widespread support for (and relative maturity of) the
SIP standard.

This group has completed the majority of its primary goals and will
focus on the remaining tasks documented here and concluding. Any
proposed new work should be socialized with the chairs and AD early to
determine if this WG is an appropriate venue.

The primary remaining work of this group will be to complete:

1. The MSRP proposed standard mechanism for transporting sessions of
messages initiated using the SIP, compliant to the requirments of RFC
2779, CPIM and BCP 41.

2. The XCAP framework for representing and carrying configuration and
policy information in SIMPLE systems.

3. A mechanism for representing partial changes (patches) to XML
documents and extensions to the SIMPLE publication and notification
mechanisms to convey these partial changes.

4. A mechanism for initiating and managing Instant Message group chat.

5. An annotated overview of the SIMPLE protocol definition documents.

Any SIP extensions proposed in the course of this development will,
after a last call process, be transferred to the SIP WG for
consideration as formal SIP extensions.

Any mechanisms created for managing Instant Message group chat are
intended to provide a bridge to the conferencing protocols that will
be defined in XCON. They will be limited in scope to address only
simple Instant Message chat with nicknames and will not attempt
to address complex conferencing concepts such as sidebars. Their
design must anticipate operating in conjunction with the conferencing
protocols XCON is working towards.

The working group will work within the framework for presence and IM
described in RFC 2778. The extensions it defines must also be
compliant with the SIP processes for extensions. The group cannot
modify baseline SIP behavior or define a new version of SIP for IM and
presence. If the group determines that any capabilities requiring an
extension to SIP are needed, the group will seek to define such
extensions within the SIP working group, and then use them here.

Goals and Milestones:
Done Submission of event package for presence to IESG for publication as Proposed Standard
Done Submission of watcher information drafts to IESG for publication as Proposed Standards
Done Submission of proposed event list mechanism to the SIP working group
Done Submission of requirements for event publishing to the IESG for
publication as Proposed Standard
Done Submission of proposed mechanism for event publishing to the SIP
working group
Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard
Done Submission of base XCAP draft to IESG for publication as Proposed
Standard
Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard
Done Submission of XCAP usage for manipulatipartial changes. 4. A mechanism for initiating and managing Instant Message group chat. 5. An annotated overview of the SIMPLE protocol definition documents. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions. Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will be defined in XCON. They will be limited in scope to address only simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing protocols XCON is working towards. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here. Goals and Milestones: Done Submission of event package for presence to IESG for publication as Proposed Standard Done Submission of watcher information drafts to IESG for publication as Proposed Standards Done Submission of proposed event list mechanism to the SIP working group Done Submission of requirements for event publishing to the IESG for publication as Proposed Standard Done Submission of proposed mechanism for event publishing to the SIP working group Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard Done Submission of base XCAP draft to IESG for publication as Proposed Standard Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard Done Submission of XCAP usage for manipulation of presence document content Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard Done Submission of Filtering mechanisms to IESG for publication as a Proposed Standard Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard Done Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard Feb 2007 Submission of an Instant Message Disposition Notification mechanism to the IESG for publication as a Proposed Standard Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG for publication as Informational Aug 2007 Submission of proposed mechanisms for initiating and managing Instant Message group chat to the IESG for publication as Proposed Standard Aug 2007 Conclusion of SIMPLE _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=_alternative 004D8144C2257274_= Content-Type: text/html; charset="US-ASCII"
Regarding:

Mar 2007 Submission of a performance and scalability analysis of the
SIMPLE presence mechanisms to the IESG for publication as Informational

Assuming that we will find things that need to be improved in e.g. 3265
what will be the mechanism for the improvements? Via SIP WG?

--Avshalom


on of presence document
content
Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard
Done Submission of Filtering mechanisms to IESG for publication as a
Proposed Standard
Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard
Done Submission of instant messaging session relay drafts to IESG for
publication as Proposed Standards
Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard
Feb 2007 Submission of an Instant Message Disposition Notification
mechanism to the IESG for publication as a Proposed Standard
Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard
Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group
Mar 2007 Submission of a performance and scalability analysis of the
SIMPLE presence mechanisms to the IESG for publication as Informational
Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG
for publication as Informational
Aug 2007 Submission of proposed mechanisms for initiating and managing
Instant Message group chat to the IESG for publication as Proposed
Standard
Aug 2007 Conclusion of SIMPLE

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--=_alternative 0048768CC2257274_=-- --===============1004551699== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1004551699==-- From simple-bounces@ietf.org Wed Jan 31 09:25:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGOR-0003Mo-S3; Wed, 31 Jan 2007 09:24:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGOP-0003MS-Og for simple@ietf.org; Wed, 31 Jan 2007 09:24:57 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGON-00070S-Ne for simple@ietf.org; Wed, 31 Jan 2007 09:24:57 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0VEOsBa179644 for ; Wed, 31 Jan 2007 14:24:54 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0VEOsgm1634372 for ; Wed, 31 Jan 2007 15:24:54 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0VEOsb3016988 for ; Wed, 31 Jan 2007 15:24:54 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0VEOseL016963 for ; Wed, 31 Jan 2007 15:24:54 +0100 To: simple@ietf.org Subject: Re: [Simple] (Performance) Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Wed, 31 Jan 2007 16:05:25 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF882 | September 26, 2006) at 31/01/2007 16:24:53, Serialize complete at 31/01/2007 16:24:53 X-Spam-Score: 0.8 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 X-BeenThere: simple@ietf.org X-Mailm
IESG Secretary <iesg-secretary@ietf.org>

30/01/2007 23:33

To
iesg@ietf.org, iab@iab.org, simple@ietf.org, Robert Sparks <RjS@estacado.net>, Hisham Khartabil <hisham.khartabil@gmail.com>
cc
Subject
[Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple)





A new charter for the SIP for Instant Messaging and Presence Leveraging
Extensions (simple) working group in the Real-time Applications and
Infrastructure Area of the IETF is being considered. The draft charter
is provided below for your review and comment.

Review time is one week.

The IETF Secretariat

+++

SIP for Instant Messaging and Presence Leveraging Extensions (simple)
======================================================================

Last Modified: 2007-1-24

Current Status: Active Working Group

Chair(s):
Robert Sparks <RjS@estacado.net>
Hisham Khartabil <hisham.khartabil@gmail.com>


Real-time Applications and Infrastructure Area Director(s):
Jon Peterson <jon.peterson@neustar.biz>
Cullen Jennings <fluffy@cisco.com>

Real-time Applications and Infrastructure Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>

Technical Advisor(s):
Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:
General Discussion: simple@ietf.org
To Subscribe: simple-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/simple/index.html

Description of Working Group:

This working group focuses on the application of the Session Initiation
Protocol (SIP, RFC 3261) to the suite of services collectively known as
instant messaging and presence (IMP). The IETF has committed to
producing an interoperable standard for these services compliant to
the requirements for IM outlined in RFC 2779 (including the security
and privacy requirements there) and in the Common Presence and Instant
Messaging (CPIM) specification, developed within the IMPP working
group. As the most common services for which SIP is used share quite a
bit in common with IMP, the adaptation of SIP to IMP seems a natural
choice given the widespread support for (and relative maturity of) the
SIP standard.

This group has completed the majority of its primary goals and will
focus on the remaining tasks documented here and concluding. Any
proposed new work should be socialized with the chairs and AD early to
determine if this WG is an appropriate venue.

The primary remaining work of this group will be to complete:

1. The MSRP proposed standard mechanism for transporting sessions of
messages initiated using the SIP, compliant to the requirments of RFC
2779, CPIM and BCP 41.

2. The XCAP framework for representing and carrying configuration and
policy information in SIMPLE systems.

3. A mechanism for representing partial changes (patches) to XML
documents and extensions to the SIMPLE publication and notification
mechanisms to convey these partial changes.

4. A mechanism for initiating and managing Instant Message group chat.

5. An annotated overview of the SIMPLE protocol definition documents.

Any SIP extensions proposed in the course of this development will,
after a last call an-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0618136998==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0618136998== Content-Type: multipart/alternative; boundary="=_alternative 004D8144C2257274_=" This is a multipart message in MIME format. --=_alternative 004D8144C2257274_= Content-Type: text/plain; charset="US-ASCII" Regarding: Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational Assuming that we will find things that need to be improved in e.g. 3265 what will be the mechanism for the improvements? Via SIP WG? --Avshalom IESG Secretary 30/01/2007 23:33 To iesg@ietf.org, iab@iab.org, simple@ietf.org, Robert Sparks , Hisham Khartabil cc Subject [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) A new charter for the SIP for Instant Messaging and Presence Leveraging Extensions (simple) working group in the Real-time Applications and Infrastructure Area of the IETF is being considered. The draft charter is provided below for your review and comment. Review time is one week. The IETF Secretariat +++ SIP for Instant Messaging and Presence Leveraging Extensions (simple) ====================================================================== Last Modified: 2007-1-24 Current Status: Active Working Group Chair(s): Robert Sparks Hisham Khartabil Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson Technical Advisor(s): Jon Peterson Mailing Lists: General Discussion: simple@ietf.org To Subscribe: simple-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/simple/index.html Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. This group has completed the majority of its primary goals and will focus on the remaining tasks documented here and concluding. Any proposed new work should be socialized with the chairs and AD early to determine if this WG is an appropriate venue. The primary remaining work of this group will be to complete: 1. The MSRP proposed standard mechanism for transporting sessions of messages initiated using the SIP, compliant to the requirments of RFC 2779, CPIM and BCP 41. 2. The XCAP framework for representing and carrying configuration and policy information in SIMPLE systems. 3. A mechanism for representing partial changes (patches) to XML documents and extensions to the SIMPLE publication and notification mechanisms to convey these process, be transferred to the SIP WG for
consideration as formal SIP extensions.

Any mechanisms created for managing Instant Message group chat are
intended to provide a bridge to the conferencing protocols that will
be defined in XCON. They will be limited in scope to address only
simple Instant Message chat with nicknames and will not attempt
to address complex conferencing concepts such as sidebars. Their
design must anticipate operating in conjunction with the conferencing
protocols XCON is working towards.

The working group will work within the framework for presence and IM
described in RFC 2778. The extensions it defines must also be
compliant with the SIP processes for extensions. The group cannot
modify baseline SIP behavior or define a new version of SIP for IM and
presence. If the group determines that any capabilities requiring an
extension to SIP are needed, the group will seek to define such
extensions within the SIP working group, and then use them here.

Goals and Milestones:
Done Submission of event package for presence to IESG for publication as Proposed Standard
Done Submission of watcher information drafts to IESG for publication as Proposed Standards
Done Submission of proposed event list mechanism to the SIP working group
Done Submission of requirements for event publishing to the IESG for
publication as Proposed Standard
Done Submission of proposed mechanism for event publishing to the SIP
working group
Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard
Done Submission of base XCAP draft to IESG for publication as Proposed
Standard
Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard
Done Submission of XCAP usage for manipulation of presence document
content
Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard
Done Submission of Filtering mechanisms to IESG for publication as a
Proposed Standard
Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard
Done Submission of instant messaging session relay drafts to IESG for
publication as Proposed Standards
Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard
Feb 2007 Submission of an Instant Message Disposition Notification
mechanism to the IESG for publication as a Proposed Standard
Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard
Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group
Mar 2007 Submission of a performance and scalability analysis of the
SIMPLE presence mechanisms to the IESG for publication as Informational
Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG
for publication as Informational
Aug 2007 Submission of proposed mechanisms for initiating and managing
Instant Message group chat to the IESG for publication as Proposed
Standard
Aug 2007 Conclusion of SIMPLE

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--=_alternative 004D8144C2257274_=-- --===============0618136998== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0618136998==-- partial changes. 4. A mechanism for initiating and managing Instant Message group chat. 5. An annotated overview of the SIMPLE protocol definition documents. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions. Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will be defined in XCON. They will be limited in scope to address only simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing protocols XCON is working towards. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here. Goals and Milestones: Done Submission of event package for presence to IESG for publication as Proposed Standard Done Submission of watcher information drafts to IESG for publication as Proposed Standards Done Submission of proposed event list mechanism to the SIP working group Done Submission of requirements for event publishing to the IESG for publication as Proposed Standard Done Submission of proposed mechanism for event publishing to the SIP working group Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard Done Submission of base XCAP draft to IESG for publication as Proposed Standard Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard Done Submission of XCAP usage for manipulation of presence document content Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard Done Submission of Filtering mechanisms to IESG for publication as a Proposed Standard Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard Done Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard Feb 2007 Submission of an Instant Message Disposition Notification mechanism to the IESG for publication as a Proposed Standard Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG for publication as Informational Aug 2007 Submission of proposed mechanisms for initiating and managing Instant Message group chat to the IESG for publication as Proposed Standard Aug 2007 Conclusion of SIMPLE _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --=_alternative 004D8144C2257274_= Content-Type: text/html; charset="US-ASCII"
Regarding:

Mar 2007 Submission of a performance and scalability analysis of the
SIMPLE presence mechanisms to the IESG for publication as Informational

Assuming that we will find things that need to be improved in e.g. 3265
what will be the mechanism for the improvements? Via SIP WG?

--Avshalom


IESG Secretary <iesg-secretary@ietf.org>

30/01/2007 23:33

To
iesg@ietf.org, iab@iab.org, simple@ietf.org, Robert Sparks <RjS@estacado.net>, Hisham Khartabil <hisham.khartabil@gmail.com>
cc
Subject
[Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple)





A new charter for the SIP for Instant Messaging and Presence Leveraging
Extensions (simple) working group in the Real-time Applications and
Infrastructure Area of the IETF is being considered. The draft charter
is provided below for your review and comment.

Review time is one week.

The IETF Secretariat

+++

SIP for Instant Messaging and Presence Leveraging Extensions (simple)
======================================================================

Last Modified: 2007-1-24

Current Status: Active Working Group

Chair(s):
Robert Sparks <RjS@estacado.net>
Hisham Khartabil <hisham.khartabil@gmail.com>


Real-time Applications and Infrastructure Area Director(s):
Jon Peterson <jon.peterson@neustar.biz>
Cullen Jennings <fluffy@cisco.com>

Real-time Applications and Infrastructure Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>

Technical Advisor(s):
Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:
General Discussion: simple@ietf.org
To Subscribe: simple-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/simple/index.html

Description of Working Group:

This working group focuses on the application of the Session Initiation
Protocol (SIP, RFC 3261) to the suite of services collectively known as
instant messaging and presence (IMP). The IETF has committed to
producing an interoperable standard for these services compliant to
the requirements for IM outlined in RFC 2779 (including the security
and privacy requirements there) and in the Common Presence and Instant
Messaging (CPIM) specification, developed within the IMPP working
group. As the most common services for which SIP is used share quite a
bit in common with IMP, the adaptation of SIP to IMP seems a natural
choice given the widespread support for (and relative maturity of) the
SIP standard.

This group has completed the majority of its primary goals and will
focus on the remaining tasks documented here and concluding. Any
proposed new work should be socialized with the chairs and AD early to
determine if this WG is an appropriate venue.

The primary remaining work of this group will be to complete:

1. The MSRP proposed standard mechanism for transporting sessions of
messages initiated using the SIP, compliant to the requirments of RFC
2779, CPIM and BCP 41.

2. The XCAP framework for representing and carrying configuration and
policy information in SIMPLE systems.

3. A mechanism for representing partial changes (patches) to XML
documents and extensions to the SIMPLE publication and notification
mechanisms to convey these partial changes.

4. A mechanism for initiating and managing Instant Message group chat.

5. An annotated overview of the SIMPLE protocol definition documents.

Any SIP extensions proposed in the course of this development will,
after a last call process, be transferred to the SIP WG for
consideration as formal SIP extensions.

Any mechanisms created for managing Instant Message group chat are
intended to provide a bridge to the conferencing protocols that will
be defined in XCON. They will be limited in scope to address only
simple Instant Message chat with nicknames and will not attempt
to address complex conferencing concepts such as sidebars. Their
design must anticipate operating in conjunction with the conferencing
protocols XCON is working towards.

The working group will work within the framework for presence and IM
described in RFC 2778. The extensions it defines must also be
compliant with the SIP processes for extensions. The group cannot
modify baseline SIP behavior or define a new version of SIP for IM and
presence. If the group determines that any capabilities requiring an
extension to SIP are needed, the group will seek to define such
extensions within the SIP working group, and then use them here.

Goals and Milestones:
Done Submission of event package for presence to IESG for publication as Proposed Standard
Done Submission of watcher information drafts to IESG for publication as Proposed Standards
Done Submission of proposed event list mechanism to the SIP working group
Done Submission of requirements for event publishing to the IESG for
publication as Proposed Standard
Done Submission of proposed mechanism for event publishing to the SIP
working group
Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard
Done Submission of base XCAP draft to IESG for publication as Proposed
Standard
Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard
Done Submission of XCAP usage for manipulation of presence document
content
Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard
Done Submission of Filtering mechanisms to IESG for publication as a
Proposed Standard
Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard
Done Submission of instant messaging session relay drafts to IESG for
publication as Proposed Standards
Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard
Feb 2007 Submission of an Instant Message Disposition Notification
mechanism to the IESG for publication as a Proposed Standard
Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard
Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group
Mar 2007 Submission of a performance and scalability analysis of the
SIMPLE presence mechanisms to the IESG for publication as Informational
Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG
for publication as Informational
Aug 2007 Submission of proposed mechanisms for initiating and managing
Instant Message group chat to the IESG for publication as Proposed
Standard
Aug 2007 Conclusion of SIMPLE

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--=_alternative 004D8144C2257274_=-- --===============0618136998== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0618136998==-- From simple-bounces@ietf.org Wed Jan 31 09:36:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGZD-0000IK-VH; Wed, 31 Jan 2007 09:36:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGZD-0000IE-DP for simple@ietf.org; Wed, 31 Jan 2007 09:36:07 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGZA-0002JG-Hl for simple@ietf.org; Wed, 31 Jan 2007 09:36:07 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0VEZqHt015486; Wed, 31 Jan 2007 08:35:59 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 08:35:50 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 15:35:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] (Performance) Internal WG Review: Recharter of SIP forInstant Messaging and Presence Leveraging Extensions (simple) Date: Wed, 31 Jan 2007 15:35:48 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180BD3CA0@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] (Performance) Internal WG Review: Recharter of SIP forInstant Messaging and Presence Leveraging Extensions (simple) Thread-Index: AcdFQ8WDajjkp0QFS9qZ2WW3g+LxtgAAEjWQ References: From: "Drage, Keith \(Keith\)" To: "Avshalom Houri" , X-OriginalArrivalTime: 31 Jan 2007 14:35:47.0504 (UTC) FILETIME=[18D54B00:01C74545] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.8 (/) X-Scan-Signature: 0d6b5666eba887052ef5e87a9de0d3b8 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1659745722==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1659745722== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74545.18B1975A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74545.18B1975A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If it updates RFC 3265 then the SIP WG needs to do it. There is a well understood mechanism of providing requirements to the SIP WG to do this. =20 If it is an extension (i.e. extending RFC 3265 rather than updating it with corrections), then RFC 3427 applies. In general this also means that the SIP WG will do it, but if for example it is just a uri-parameter or some such, then other groups could well do it. Again there is a well understood mechanism of providing requirements to the SIP WG to do this. =20 =20 =20 Keith ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: 31 January 2007 14:05 To: simple@ietf.org Subject: Re: [Simple] (Performance) Internal WG Review: Recharter of SIP forInstant Messaging and Presence Leveraging Extensions (simple) =09 =09 Regarding:=20 =09 Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational=20 =09 Assuming that we will find things that need to be improved in e.g. 3265=20 what will be the mechanism for the improvements? Via SIP WG?=20 =09 --Avshalom =09 =09 =09 =09 IESG Secretary =20 30/01/2007 23:33=20 To iesg@ietf.org, iab@iab.org, simple@ietf.org, Robert Sparks , Hisham Khartabil =20 cc Subject [Simple] Internal WG Review: Recharter of SIP for Instant Messaging and Presence Leveraging Extensions (simple) =09 A new charter for the SIP for Instant Messaging and Presence Leveraging Extensions (simple) working group in the Real-time Applications and Infrastructure Area of the IETF is being considered. The draft charter=20 is provided below for your review and comment. =09 Review time is one week. =09 The IETF Secretariat =09 +++ =09 SIP for Instant Messaging and Presence Leveraging Extensions (simple) =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =09 Last Modified: 2007-1-24 =09 Current Status: Active Working Group =09 Chair(s): Robert Sparks Hisham Khartabil =09 =09 Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings =09 Real-time Applications and Infrastructure Area Advisor: Jon Peterson =09 Technical Advisor(s): Jon Peterson =09 Mailing Lists: General Discussion: simple@ietf.org To Subscribe: simple-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/simple/index.html =09 Description of Working Group: =09 This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to=20 producing an interoperable standard for these services compliant to=20 the requirements for IM outlined in RFC 2779 (including the security=20 and privacy requirements there) and in the Common Presence and Instant=20 Messaging (CPIM) specification, developed within the IMPP working=20 group. As the most common services for which SIP is used share quite a=20 bit in common with IMP, the adaptation of SIP to IMP seems a natural=20 choice given the widespread support for (and relative maturity of) the SIP standard. =09 This group has completed the majority of its primary goals and will=20 focus on the remaining tasks documented here and concluding. Any proposed new work should be socialized with the chairs and AD early to=20 determine if this WG is an appropriate venue. =09 The primary remaining work of this group will be to complete: =09 1. The MSRP proposed standard mechanism for transporting sessions of messages initiated using the SIP, compliant to the requirments of RFC=20 2779, CPIM and BCP 41. =09 2. The XCAP framework for representing and carrying configuration and policy information in SIMPLE systems. =09 3. A mechanism for representing partial changes (patches) to XML documents and extensions to the SIMPLE publication and notification=20 mechanisms to convey these partial changes. =09 4. A mechanism for initiating and managing Instant Message group chat. =09 5. An annotated overview of the SIMPLE protocol definition documents. =09 Any SIP extensions proposed in the course of this development will,=20 after a last call process, be transferred to the SIP WG for=20 consideration as formal SIP extensions. =09 Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will=20 be defined in XCON. They will be limited in scope to address only=20 simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing=20 protocols XCON is working towards. =09 The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be=20 compliant with the SIP processes for extensions. The group cannot=20 modify baseline SIP behavior or define a new version of SIP for IM and=20 presence. If the group determines that any capabilities requiring an=20 extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here. =09 Goals and Milestones: Done Submission of event package for presence to IESG for publication as Proposed Standard Done Submission of watcher information drafts to IESG for publication as Proposed Standards Done Submission of proposed event list mechanism to the SIP working group=20 Done Submission of requirements for event publishing to the IESG for publication as Proposed Standard Done Submission of proposed mechanism for event publishing to the SIP working group Done Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard Done Submission of base XCAP draft to IESG for publication as Proposed Standard Done Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard Done Submission of XCAP usage for manipulation of presence document content Done Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard Done Submission of Filtering mechanisms to IESG for publication as a Proposed Standard Done Submission of instant messaging session draft to IESG for publication as a Proposed Standard Done Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards Done Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard Feb 2007 Submission of an Instant Message Disposition Notification mechanism to the IESG for publication as a Proposed Standard Feb 2007 Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard Feb 2007 Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group Mar 2007 Submission of a performance and scalability analysis of the SIMPLE presence mechanisms to the IESG for publication as Informational Jun 2007 Submission of SIMPLE protocol annotated overview draft to IESG for publication as Informational Aug 2007 Submission of proposed mechanisms for initiating and managing Instant Message group chat to the IESG for publication as Proposed Standard Aug 2007 Conclusion of SIMPLE =09 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple =09 =09 ------_=_NextPart_001_01C74545.18B1975A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If it updates RFC 3265 then the SIP WG needs to = do it.=20 There is a well understood mechanism of providing requirements to the = SIP WG to=20 do this.
 
If it is an extension (i.e. extending RFC 3265 = rather than=20 updating it with corrections), then RFC 3427 applies. In general this = also means=20 that the SIP WG will do it, but if for example it is just a = uri-parameter or=20 some such, then other groups could well do it. Again there is a well = understood=20 mechanism of providing requirements to the SIP WG to do=20 this.
 
 
 
Keith

From: Avshalom Houri=20 [mailto:AVSHALOM@il.ibm.com]
Sent: 31 January 2007=20 14:05
To: simple@ietf.org
Subject: Re: [Simple]=20 (Performance) Internal WG Review: Recharter of SIP forInstant = Messaging and=20 Presence Leveraging Extensions (simple)


Regarding: =

Mar 2007 Submission of a performance and scalability analysis = of=20 the
SIMPLE presence mechanisms to the IESG for publication as=20 Informational

Assuming that we = will find=20 things that need to be improved in e.g. 3265
what will be the mechanism for the improvements? Via SIP=20 WG?

--Avshalom



IESG = Secretary=20 <iesg-secretary@ietf.org>

30/01/2007 23:33

To
iesg@ietf.org, = iab@iab.org,=20 simple@ietf.org, Robert Sparks <RjS@estacado.net>, = Hisham=20 Khartabil <hisham.khartabil@gmail.com>=20
cc
Subject
[Simple] Internal WG = Review:=20 Recharter of SIP for Instant Messaging and Presence = Leveraging=20 Extensions (simple)

=




A new charter for the SIP for Instant Messaging and Presence=20 Leveraging
Extensions (simple) working group in the Real-time = Applications=20 and
Infrastructure Area of the IETF is being considered. The draft = charter=20
is provided below for your review and comment.

Review time = is one=20 week.

The IETF Secretariat

+++

SIP for Instant = Messaging=20 and Presence Leveraging Extensions=20 = (simple)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= BR>
Last=20 Modified: 2007-1-24

Current Status: Active Working=20 Group

Chair(s):
Robert Sparks = <RjS@estacado.net>
Hisham=20 Khartabil <hisham.khartabil@gmail.com>


Real-time = Applications=20 and Infrastructure Area Director(s):
Jon Peterson=20 <jon.peterson@neustar.biz>
Cullen Jennings=20 <fluffy@cisco.com>

Real-time Applications and = Infrastructure Area=20 Advisor:
Jon Peterson = <jon.peterson@neustar.biz>

Technical=20 Advisor(s):
Jon Peterson = <jon.peterson@neustar.biz>

Mailing=20 Lists:
General Discussion: simple@ietf.org
To Subscribe:=20 simple-request@ietf.org
In Body: subscribe
Archive:=20 = http://www.ietf.org/mail-archive/web/simple/index.html

Description= of=20 Working Group:

This working group focuses on the application of = the=20 Session Initiation
Protocol (SIP, RFC 3261) to the suite of = services=20 collectively known as
instant messaging and presence (IMP). The = IETF has=20 committed to
producing an interoperable standard for these = services=20 compliant to
the requirements for IM outlined in RFC 2779 = (including the=20 security
and privacy requirements there) and in the Common = Presence and=20 Instant
Messaging (CPIM) specification, developed within the IMPP = working=20
group. As the most common services for which SIP is used share = quite a=20
bit in common with IMP, the adaptation of SIP to IMP seems a = natural=20
choice given the widespread support for (and relative maturity of) = the
SIP standard.

This group has completed the majority of = its=20 primary goals and will
focus on the remaining tasks documented = here and=20 concluding. Any
proposed new work should be socialized with the = chairs and=20 AD early to
determine if this WG is an appropriate = venue.

The=20 primary remaining work of this group will be to complete:

1. = The MSRP=20 proposed standard mechanism for transporting sessions of
messages = initiated=20 using the SIP, compliant to the requirments of RFC
2779, CPIM and = BCP=20 41.

2. The XCAP framework for representing and carrying = configuration=20 and
policy information in SIMPLE systems.

3. A mechanism for = representing partial changes (patches) to XML
documents and = extensions to=20 the SIMPLE publication and notification
mechanisms to convey these = partial=20 changes.

4. A mechanism for initiating and managing Instant = Message=20 group chat.

5. An annotated overview of the SIMPLE protocol = definition=20 documents.

Any SIP extensions proposed in the course of this=20 development will,
after a last call process, be transferred to the = SIP WG=20 for
consideration as formal SIP extensions.

Any mechanisms = created=20 for managing Instant Message group chat are
intended to provide a = bridge to=20 the conferencing protocols that will
be defined in XCON. They will = be=20 limited in scope to address only
simple Instant Message chat with=20 nicknames and will not attempt
to address complex conferencing = concepts=20 such as sidebars. Their
design must anticipate operating in = conjunction=20 with the conferencing
protocols XCON is working = towards.

The=20 working group will work within the framework for presence and = IM
described=20 in RFC 2778. The extensions it defines must also be
compliant with = the SIP=20 processes for extensions. The group cannot
modify baseline SIP = behavior or=20 define a new version of SIP for IM and
presence. If the group = determines=20 that any capabilities requiring an
extension to SIP are needed, = the group=20 will seek to define such
extensions within the SIP working group, = and then=20 use them here.

Goals and Milestones:
Done Submission of = event=20 package for presence to IESG for publication as Proposed = Standard
Done=20 Submission of watcher information drafts to IESG for publication as = Proposed=20 Standards
Done Submission of proposed event list mechanism to the = SIP=20 working group
Done Submission of requirements for event publishing = to the=20 IESG for
publication as Proposed Standard
Done Submission of = proposed=20 mechanism for event publishing to the SIP
working group
Done = Submission=20 of SIMPLE PIDF profile to IESG for publication as Proposed = Standard
Done=20 Submission of base XCAP draft to IESG for publication as=20 Proposed
Standard
Done Submission of indication of instant = message=20 preparation using SIP to IESG for publication as a Proposed = Standard
Done=20 Submission of XCAP usage for manipulation of presence=20 document
content
Done Submission of XCAP usage for setting = presence=20 authorization to IESG for publication as Proposed Standard
Done = Submission=20 of Filtering mechanisms to IESG for publication as a
Proposed=20 Standard
Done Submission of instant messaging session draft to IESG = for=20 publication as a Proposed Standard
Done Submission of instant = messaging=20 session relay drafts to IESG for
publication as Proposed = Standards
Done=20 Submission of Partial Notification mechanism to IESG for publication = as a=20 Proposed Standard
Feb 2007 Submission of an Instant Message = Disposition=20 Notification
mechanism to the IESG for publication as a Proposed=20 Standard
Feb 2007 Submission of XCAP event package to IESG or = appropriate=20 working group targeting publication as Proposed Standard
Feb 2007=20 Submission of proposed mechanisms meeting the advanced messaging = requirements=20 to the IESG or appropriate working group
Mar 2007 Submission of a=20 performance and scalability analysis of the
SIMPLE presence = mechanisms to=20 the IESG for publication as Informational
Jun 2007 Submission of = SIMPLE=20 protocol annotated overview draft to IESG
for publication as=20 Informational
Aug 2007 Submission of proposed mechanisms for = initiating and=20 managing
Instant Message group chat to the IESG for publication as=20 Proposed
Standard
Aug 2007 Conclusion of=20 = SIMPLE

_______________________________________________
Simple=20 mailing=20 = list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple<= BR>
------_=_NextPart_001_01C74545.18B1975A-- --===============1659745722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1659745722==-- From simple-bounces@ietf.org Wed Jan 31 09:49:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGlx-0007WP-OS; Wed, 31 Jan 2007 09:49:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGlw-0007Tt-Nl for simple@ietf.org; Wed, 31 Jan 2007 09:49:16 -0500 Received: from extmail11.cingular.com ([170.35.225.26] helo=cingular.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGlt-0006DC-2L for simple@ietf.org; Wed, 31 Jan 2007 09:49:16 -0500 Received: from ([10.148.14.29]) by extmail11.cingular.com with ESMTP id KP-VYHG4.112365353; Wed, 31 Jan 2007 09:48:50 -0500 Received: from TBDCEXCH10.US.Cingular.Net ([10.148.14.47]) by TD02XSMTP007.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 08:48:51 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Internal WG Review: Recharter of SIP forInstantMessaging and Presence Leveraging Extensions (simple) Date: Wed, 31 Jan 2007 08:48:49 -0600 Message-ID: <451C9AB8BFB6B64EA11547A3D966DB3609D244F9@TBDCEXCH10.US.Cingular.Net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Internal WG Review: Recharter of SIP forInstantMessaging and Presence Leveraging Extensions (simple) Thread-Index: AcdEvKJkg/fhcoQdTvOuJtUsSh2CtAAXM44wAAoDIcA= To: , , X-OriginalArrivalTime: 31 Jan 2007 14:48:51.0090 (UTC) FILETIME=[EBE30720:01C74546] From: "Stafford, Matthew" X-Spam-Score: 0.5 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Re wireless service providers wanting something similar to MMS: I would say not only in its own right, but as an interworking vehicle with the MMS installed base. This is important, I think, from the POV of facilitating SIMPLE deployment- something I would very much like to see! In the context of this conversation, I am eager to hear comments on an internet draft posted a couple of weeks ago: http://www.ietf.org/internet-drafts/draft-stafford-simple-dmdn-00.txt The draft sets forth use cases involving MSRP- use cases in which imdn (or similar) functionality would be very useful. In many instances, use cases can be supported with existing building blocks. But here we do see a gap, and think that the best solution would be a new/extended building block devised by IETF. As I indicated in a Jan 19 message posted to this list, we understand the need to go ahead and progress the imdn draft (sans MSRP). I'm not necessarily inviting detailed discussion of this draft (in the midst of the current rechartering discussion, that might be premature). At this point, I'm wanting to know whether this sort of thing will be in scope (and "lobbying" for the answer to be yes...) Best, Matt Stafford=20 -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 Sent: Wednesday, January 31, 2007 3:37 AM To: pkyzivat@cisco.com; simple@ietf.org Subject: RE: [Simple] Internal WG Review: Recharter of SIP forInstantMessaging and Presence Leveraging Extensions (simple) Hi, Yes, I think this is a feature that would be needed in practice. Having two messaging mechanisms without clear guidance on how they relate to each other is going to cause interoperability issues - if not on the protocol level then at least on the UI-to-UI or user-to-user level. Another thing is that there should be some kind of specification/guideline on how to actually deliver one-shot messages that are larger than 1300 bytes. One way is to use MSRP, another to do content indirection with MESSAGE. In MSRP the key is the ability for the sender to indicate (at least as a preference/hint) that the session is established for just sending a single message, not to open a conversation. This is wanted by providers who would like to be able to offer something similar to MMS service on top of a SIP infra.=20 SIMPLE WG has not been very enthusiastic about this in the past, so I think OMA has already defined a particular mechanism for MSRP. If everyone who is interested in this is anyway involved in OMA, as it seems, there would be not much value for IETF to do anything about it. However, if there is real interest outside OMA, it would be useful to have some work in SIMPLE WG. Markus =20 >-----Original Message----- >From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 >Sent: 31 January, 2007 00:15 >To: simple@ietf.org >Subject: Re: [Simple] Internal WG Review: Recharter of SIP for=20 >InstantMessaging and Presence Leveraging Extensions (simple) > >Wasn't there some talk of a need to specify how to choose=20 >between MESSAGE and MSRP, and/or to transition between them in=20 >support of a single conversation? > >E.g. send a MESSAGE because there may never be a conversation,=20 >but then INVITE with an MSRP session to continue the=20 >conversation. The need here would be for a way to tie these=20 >things together so it is clear that they are part of the same=20 >conversation. There are obviously issues with involving the=20 >same pair of UAs in both. > >I seem to recall this was discussed at some point, but I'm not=20 >sure and if so I don't remember the outcome. > > Paul > >IESG Secretary wrote: >> A new charter for the SIP for Instant Messaging and Presence=20 >> Leveraging Extensions (simple) working group in the Real-time=20 >> Applications and Infrastructure Area of the IETF is being=20 >considered.=20 >> The draft charter is provided below for your review and comment. >>=20 >> Review time is one week. >>=20 >> The IETF Secretariat >>=20 >> +++ >>=20 >> SIP for Instant Messaging and Presence Leveraging Extensions=20 >(simple)=20 >>=20 >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Last Modified: 2007-1-24 >>=20 >> Current Status: Active Working Group >>=20 >> Chair(s): >> Robert Sparks >> Hisham Khartabil >>=20 >>=20 >> Real-time Applications and Infrastructure Area Director(s): >> Jon Peterson Cullen Jennings=20 >> >>=20 >> Real-time Applications and Infrastructure Area Advisor: >> Jon Peterson >>=20 >> Technical Advisor(s): >> Jon Peterson >>=20 >> Mailing Lists: >> General Discussion: simple@ietf.org >> To Subscribe: simple-request@ietf.org >> In Body: subscribe >> Archive: http://www.ietf.org/mail-archive/web/simple/index.html >>=20 >> Description of Working Group: >>=20 >> This working group focuses on the application of the Session=20 >> Initiation Protocol (SIP, RFC 3261) to the suite of services=20 >> collectively known as instant messaging and presence (IMP). The IETF=20 >> has committed to producing an interoperable standard for these=20 >> services compliant to the requirements for IM outlined in RFC 2779=20 >> (including the security and privacy requirements there) and in the=20 >> Common Presence and Instant Messaging (CPIM) specification,=20 >developed=20 >> within the IMPP working group. As the most common services for which=20 >> SIP is used share quite a bit in common with IMP, the adaptation of=20 >> SIP to IMP seems a natural choice given the widespread support for=20 >> (and relative maturity of) the SIP standard. >>=20 >> This group has completed the majority of its primary goals and will=20 >> focus on the remaining tasks documented here and concluding. Any=20 >> proposed new work should be socialized with the chairs and=20 >AD early to=20 >> determine if this WG is an appropriate venue. >>=20 >> The primary remaining work of this group will be to complete: >>=20 >> 1. The MSRP proposed standard mechanism for transporting sessions of=20 >> messages initiated using the SIP, compliant to the=20 >requirments of RFC=20 >> 2779, CPIM and BCP 41. >>=20 >> 2. The XCAP framework for representing and carrying=20 >configuration and=20 >> policy information in SIMPLE systems. >>=20 >> 3. A mechanism for representing partial changes (patches) to XML=20 >> documents and extensions to the SIMPLE publication and notification=20 >> mechanisms to convey these partial changes. >>=20 >> 4. A mechanism for initiating and managing Instant Message=20 >group chat. >>=20 >> 5. An annotated overview of the SIMPLE protocol definition documents. >>=20 >> Any SIP extensions proposed in the course of this development will,=20 >> after a last call process, be transferred to the SIP WG for=20 >> consideration as formal SIP extensions. >>=20 >> Any mechanisms created for managing Instant Message group chat are=20 >> intended to provide a bridge to the conferencing protocols that will=20 >> be defined in XCON. They will be limited in scope to address only=20 >> simple Instant Message chat with nicknames and will not attempt to=20 >> address complex conferencing concepts such as sidebars. Their design=20 >> must anticipate operating in conjunction with the conferencing=20 >> protocols XCON is working towards. >>=20 >> The working group will work within the framework for presence and IM=20 >> described in RFC 2778. The extensions it defines must also be=20 >> compliant with the SIP processes for extensions. The group cannot=20 >> modify baseline SIP behavior or define a new version of SIP=20 >for IM and=20 >> presence. If the group determines that any capabilities requiring an=20 >> extension to SIP are needed, the group will seek to define such=20 >> extensions within the SIP working group, and then use them here. >>=20 >> Goals and Milestones: >> Done Submission of event package for presence to IESG for=20 >publication=20 >> as Proposed Standard Done Submission of watcher information=20 >drafts to=20 >> IESG for publication as Proposed Standards Done Submission=20 >of proposed=20 >> event list mechanism to the SIP working group Done Submission of=20 >> requirements for event publishing to the IESG for publication as=20 >> Proposed Standard Done Submission of proposed mechanism for event=20 >> publishing to the SIP working group Done Submission of SIMPLE PIDF=20 >> profile to IESG for publication as Proposed Standard Done Submission=20 >> of base XCAP draft to IESG for publication as Proposed Standard Done=20 >> Submission of indication of instant message preparation using SIP to=20 >> IESG for publication as a Proposed Standard Done Submission of XCAP=20 >> usage for manipulation of presence document content Done=20 >Submission of=20 >> XCAP usage for setting presence authorization to IESG for=20 >publication=20 >> as Proposed Standard Done Submission of Filtering mechanisms to IESG=20 >> for publication as a Proposed Standard Done Submission of instant=20 >> messaging session draft to IESG for publication as a=20 >Proposed Standard=20 >> Done Submission of instant messaging session relay drafts to=20 >IESG for=20 >> publication as Proposed Standards Done Submission of Partial=20 >> Notification mechanism to IESG for publication as a Proposed=20 >Standard=20 >> Feb 2007 Submission of an Instant Message Disposition Notification=20 >> mechanism to the IESG for publication as a Proposed Standard=20 >Feb 2007=20 >> Submission of XCAP event package to IESG or appropriate=20 >working group=20 >> targeting publication as Proposed Standard Feb 2007 Submission of=20 >> proposed mechanisms meeting the advanced messaging=20 >requirements to the=20 >> IESG or appropriate working group Mar 2007 Submission of a=20 >performance=20 >> and scalability analysis of the SIMPLE presence mechanisms=20 >to the IESG=20 >> for publication as Informational Jun 2007 Submission of SIMPLE=20 >> protocol annotated overview draft to IESG for publication as=20 >> Informational Aug 2007 Submission of proposed mechanisms for=20 >> initiating and managing Instant Message group chat to the IESG for=20 >> publication as Proposed Standard Aug 2007 Conclusion of SIMPLE >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >>=20 > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple